Randomization of address chosen by mmap.

 include/linux/mm.h |  16 ++++--
 mm/mmap.c          | 164 +++++++++++++++++++++++++++++++++++++++++++++++++++++

include/linux/mm.h +0 -0

 	if (info->flags & VM_UNMAPPED_AREA_TOPDOWN)
 		return unmapped_area_topdown(info);
 	else

@@ -2529,11 +2540,6 @@ int drop_caches_sysctl_handler(struct ctl_table *, int,
 void drop_slab(void);
 void drop_slab_node(int nid);
 
 
...

mm/mmap.c +13 -0

+	struct mm_struct *mm = current->mm;
+	struct vm_area_struct *vma = NULL;
+	struct vm_area_struct *visited_vma = NULL;
+	unsigned long entropy[2];
+	unsigned long length, low_limit, high_limit, gap_start, gap_end;
+	unsigned long addr = 0;
+
+	/* get entropy with prng */
+	prandom_bytes(&entropy, sizeof(entropy));
+	/* small hack to prevent EPERM result */
+	info->low_limit = max(info->low_limit, mmap_min_addr);
+
 
...
 
+found:

mm/mmap.c +4 -0

+	addr = gap_end - (addr << PAGE_SHIFT);
+	addr += (info->align_offset - addr) & info->align_mask;
+	return addr;
+}
 
...

Quoted 2 lines · On Thu, 22 Mar 2018 19:36:37 +0300 Ilya Smith <[email protected]> wrote:

include/linux/mm.h | 16 ++++--
mm/mmap.c | 164 +++++++++++++++++++++++++++++++++++++++++++++++++++++

You'll be wanting to update the documentation.
Documentation/sysctl/kernel.txt and
Documentation/admin-guide/kernel-parameters.txt.

include/linux/mm.h extern unsigned long unmapped_area_topdown(struct vm_unmapped_area_info *info); · line 2281

Quoted 9 lines

...

(quoted diff) +0 -0

@@ -2268,6 +2276,9 @@ extern unsigned long unmapped_area_topdown(struct vm_unmapped_area_info *info);

static inline unsigned long vm_unmapped_area(struct vm_unmapped_area_info *info) {

include/linux/mm.h +3 -0

+	/* How about 32 bit process?? */
+	if ((current->flags & PF_RANDOMIZE) && randomize_va_space > 3)
+		return unmapped_area_random(info);

The handling of randomize_va_space is peculiar. Rather than being a bitfield which independently selects different modes, it is treated as a scalar: the larger the value, the more stuff we randomize.

I can see the sense in that (and I wonder what randomize_va_space=5 will do). But it is... odd.

Why did you select randomize_va_space=4 for this? Is there a mode 3 already and we forgot to document it? Or did you leave a gap for something? If the former, please feel free to fix the documentation (in a separate, preceding patch) while you're in there ;)

Quoted 14 lines

	if (info->flags & VM_UNMAPPED_AREA_TOPDOWN)
		return unmapped_area_topdown(info);
	else

include/linux/mm.h +0 -0

@@ -2529,11 +2540,6 @@ int drop_caches_sysctl_handler(struct ctl_table *, int,
 void drop_slab(void);
 void drop_slab_node(int nid);
 
 
...

@@ -1780,6 +1781,169 @@ unsigned long mmap_region(struct file *file, unsigned long addr,
 	return error;
 }
 

mm/mmap.c unsigned long mmap_region(struct file *file, unsigned long addr, · line 1785

Quoted 2 lines

mm/mmap.c +2 -0

+unsigned long unmapped_area_random(struct vm_unmapped_area_info *info)
+{

This function is just dead code if CONFIG_MMU=n, yes? Let's add the ifdefs to make it go away in that case.

Quoted 16 lines

mm/mmap.c +13 -0

+	struct mm_struct *mm = current->mm;
+	struct vm_area_struct *vma = NULL;
+	struct vm_area_struct *visited_vma = NULL;
+	unsigned long entropy[2];
+	unsigned long length, low_limit, high_limit, gap_start, gap_end;
+	unsigned long addr = 0;
+
+	/* get entropy with prng */
+	prandom_bytes(&entropy, sizeof(entropy));
+	/* small hack to prevent EPERM result */
+	info->low_limit = max(info->low_limit, mmap_min_addr);
+
 
...
 
+found:

mm/mmap.c unsigned long mmap_region(struct file *file, unsigned long addr,

Quoted 10 lines

mm/mmap.c +10 -0

+	/* We found a suitable gap. Clip it with the original high_limit. */
+	if (gap_end > info->high_limit)
+		gap_end = info->high_limit;
+	gap_end -= info->length;
+	gap_end -= (gap_end - info->align_offset) & info->align_mask;
+	/* only one suitable page */
+	if (gap_end ==  gap_start)
+		return gap_start;
+	addr = entropy[1] % (min((gap_end - gap_start) >> PAGE_SHIFT,
+							 0x10000UL));

What does the magic 10000 mean? Isn't a comment needed explaining this?

mm/mmap.c unsigned long mmap_region(struct file *file, unsigned long addr,

Quoted 7 lines

mm/mmap.c +4 -0

+	addr = gap_end - (addr << PAGE_SHIFT);
+	addr += (info->align_offset - addr) & info->align_mask;
+	return addr;
+}
 
...

Please add changelogs. An explanation of what a "limit on memory region random shift" is would be nice ;) Why does it exist, why are we doing this, etc. Surely there's something to be said - at present this is just a lump of random code?

Please add changelogs. An explanation of what a "limit on memory region random shift" is would be nice ;) Why does it exist, why are we doing this, etc. Surely there's something to be said - at present this is just a lump of random code?

Current implementation doesn't randomize address returned by mmap. All the entropy ends with choosing mmap_base_addr at the process creation. After that mmap build very predictable layout of address space. It allows to bypass ASLR in many cases.

Quoted 4 lines · On Thu, 22 Mar 2018 19:36:36 +0300 Ilya Smith <[email protected]> wrote:

Current implementation doesn't randomize address returned by mmap. All the entropy ends with choosing mmap_base_addr at the process creation. After that mmap build very predictable layout of address space. It allows to bypass ASLR in many cases.

Perhaps some more effort on the problem description would help. *Are* people predicting layouts at present? What problems does this cause? How are they doing this and are there other approaches to solving the problem?

Mainly: what value does this patchset have to our users? This reader is unable to determine that from the information which you have provided. Full details, please.

Current implementation doesn't randomize address returned by mmap. All the entropy ends with choosing mmap_base_addr at the process creation. After that mmap build very predictable layout of address space. It allows to bypass ASLR in many cases. This patch make randomization of address on any mmap call.

Quoted 5 lines · Ilya Smith

Current implementation doesn't randomize address returned by mmap. All the entropy ends with choosing mmap_base_addr at the process creation. After that mmap build very predictable layout of address space. It allows to bypass ASLR in many cases. This patch make randomization of address on any mmap call.

Why should this be done in the kernel rather than libc? libc is perfectly capable of specifying random numbers in the first argument of mmap.

Quoted 10 lines · Matthew Wilcox

Quoted 5 lines · Ilya Smith

Current implementation doesn't randomize address returned by mmap. All the entropy ends with choosing mmap_base_addr at the process creation. After that mmap build very predictable layout of address space. It allows to bypass ASLR in many cases. This patch make randomization of address on any mmap call.

Quoted 2 lines

Why should this be done in the kernel rather than libc? libc is perfectly capable of specifying random numbers in the first argument of mmap.

Well, there is following reasons:
1. It should be done in any libc implementation, what is not possible IMO;

2. User mode is not that layer which should be responsible for choosing random address or handling entropy;

3. Memory fragmentation is unpredictable in this case

Off course user mode could use random ‘hint’ address, but kernel may discard this address if it is occupied for example and allocate just before closest vma. So this solution doesn’t give that much security like randomization address inside kernel.

Quoted 10 lines · Ilya Smith

Quoted 10 lines · Matthew Wilcox

Quoted 5 lines · Ilya Smith

Current implementation doesn't randomize address returned by mmap. All the entropy ends with choosing mmap_base_addr at the process creation. After that mmap build very predictable layout of address space. It allows to bypass ASLR in many cases. This patch make randomization of address on any mmap call.

Quoted 4 lines

Quoted 2 lines

Why should this be done in the kernel rather than libc? libc is perfectly capable of specifying random numbers in the first argument of mmap.

Well, there is following reasons:
1. It should be done in any libc implementation, what is not possible IMO;

Is this really so helpful?

Quoted 3 lines

2. User mode is not that layer which should be responsible for choosing random address or handling entropy;

Why?

Quoted 7 lines

3. Memory fragmentation is unpredictable in this case

Off course user mode could use random ‘hint’ address, but kernel may discard this address if it is occupied for example and allocate just before closest vma. So this solution doesn’t give that much security like randomization address inside kernel.

The userspace can use the new MAP_FIXED_NOREPLACE to probe for the address range atomically and chose a different range on failure.

Quoted 14 lines · Michal Hocko

Quoted 10 lines · Ilya Smith

Quoted 10 lines · Matthew Wilcox

Quoted 5 lines · Ilya Smith

Current implementation doesn't randomize address returned by mmap. All the entropy ends with choosing mmap_base_addr at the process creation. After that mmap build very predictable layout of address space. It allows to bypass ASLR in many cases. This patch make randomization of address on any mmap call.

Quoted 6 lines

Quoted 4 lines

Quoted 2 lines

Why should this be done in the kernel rather than libc? libc is perfectly capable of specifying random numbers in the first argument of mmap.

Well, there is following reasons:
1. It should be done in any libc implementation, what is not possible IMO;

Is this really so helpful?

Yes, ASLR is one of very important mitigation techniques which are really used to protect applications. If there is no ASLR, it is very easy to exploit vulnerable application and compromise the system. We can’t just fix all the vulnerabilities right now, thats why we have mitigations - techniques which are makes exploitation more hard or impossible in some cases.

Thats why it is helpful.

Quoted 5 lines

Quoted 3 lines

2. User mode is not that layer which should be responsible for choosing random address or handling entropy;

Why?

Because of the following reasons:
1. To get random address you should have entropy. These entropy shouldn’t be exposed to attacker anyhow, the best case is to get it from kernel. So this is a syscall.

2. You should have memory map of your process to prevent remapping or big fragmentation. Kernel already has this map.

You will got another one in libc.
And any non-libc user of mmap (via syscall, etc) will make hole in your map. This one also decrease performance cause you any way call syscall_mmap which will try to find some address for you in worst case, but after you already did some computing on it.

3. The more memory you use in userland for these proposal, the easier for attacker to leak it or use in exploitation techniques.

4. It is so easy to fix Kernel function and so hard to support memory management from userspace.

Quoted 7 lines

Quoted 6 lines

3. Memory fragmentation is unpredictable in this case

Off course user mode could use random ‘hint’ address, but kernel may discard this address if it is occupied for example and allocate just before closest vma. So this solution doesn’t give that much security like randomization address inside kernel.

Quoted 3 lines

The userspace can use the new MAP_FIXED_NOREPLACE to probe for the address range atomically and chose a different range on failure.

This algorithm should track current memory. If he doesn’t he may cause infinite loop while trying to choose memory. And each iteration increase time needed on allocation new memory, what is not preferred by any libc library developer.

Quoted 27 lines · Ilya Smith

Quoted 14 lines · Michal Hocko

Quoted 10 lines · Ilya Smith

Quoted 10 lines · Matthew Wilcox

Quoted 5 lines · Ilya Smith

Current implementation doesn't randomize address returned by mmap. All the entropy ends with choosing mmap_base_addr at the process creation. After that mmap build very predictable layout of address space. It allows to bypass ASLR in many cases. This patch make randomization of address on any mmap call.

Quoted 6 lines

Quoted 4 lines

Quoted 2 lines

Why should this be done in the kernel rather than libc? libc is perfectly capable of specifying random numbers in the first argument of mmap.

Well, there is following reasons:
1. It should be done in any libc implementation, what is not possible IMO;

Is this really so helpful?

Yes, ASLR is one of very important mitigation techniques which are really used to protect applications. If there is no ASLR, it is very easy to exploit vulnerable application and compromise the system. We can’t just fix all the vulnerabilities right now, thats why we have mitigations - techniques which are makes exploitation more hard or impossible in some cases.

Quoted 1 line

Thats why it is helpful.

I am not questioning ASLR in general. I am asking whether we really need per mmap ASLR in general. I can imagine that some environments want to pay the additional price and other side effects, but considering this can be achieved by libc, why to add more code to the kernel?

Quoted 4 lines

Quoted 4 lines

Quoted 3 lines

2. User mode is not that layer which should be responsible for choosing random address or handling entropy;

Quoted 6 lines

Quoted 1 line

Why?

Because of the following reasons:
1. To get random address you should have entropy. These entropy shouldn’t be exposed to attacker anyhow, the best case is to get it from kernel. So this is a syscall.

/dev/[u]random is not sufficient?

Quoted 3 lines

2. You should have memory map of your process to prevent remapping or big fragmentation. Kernel already has this map.

/proc/self/maps?

Quoted 5 lines

You will got another one in libc.
And any non-libc user of mmap (via syscall, etc) will make hole in your map. This one also decrease performance cause you any way call syscall_mmap which will try to find some address for you in worst case, but after you already did some computing on it.

I do not understand. a) you should be prepared to pay an additional price for an additional security measures and b) how would anybody punch a hole into your mapping?

Quoted 2 lines

3. The more memory you use in userland for these proposal, the easier for attacker to leak it or use in exploitation techniques.

This is true in general, isn't it? I fail to see how kernel chosen and user chosen ranges would make any difference.

Quoted 3 lines

4. It is so easy to fix Kernel function and so hard to support memory management from userspace.

Well, on the other hand the new layout mode will add a maintenance burden on the kernel and will have to be maintained for ever because it is a user visible ABI.

Quoted 12 lines

Quoted 11 lines

Quoted 7 lines

3. Memory fragmentation is unpredictable in this case

Off course user mode could use random ‘hint’ address, but kernel may discard this address if it is occupied for example and allocate just before closest vma. So this solution doesn’t give that much security like randomization address inside kernel.

The userspace can use the new MAP_FIXED_NOREPLACE to probe for the address range atomically and chose a different range on failure.

Quoted 4 lines

This algorithm should track current memory. If he doesn’t he may cause infinite loop while trying to choose memory. And each iteration increase time needed on allocation new memory, what is not preferred by any libc library developer.

Well, I am pretty sure userspace can implement proper free ranges tracking…

Quoted 31 lines · Michal Hocko

Quoted 27 lines · Ilya Smith

Quoted 14 lines · Michal Hocko

Quoted 10 lines · Ilya Smith

Quoted 10 lines · Matthew Wilcox

Quoted 5 lines · Ilya Smith

Current implementation doesn't randomize address returned by mmap. All the entropy ends with choosing mmap_base_addr at the process creation. After that mmap build very predictable layout of address space. It allows to bypass ASLR in many cases. This patch make randomization of address on any mmap call.

Quoted 6 lines

Quoted 4 lines

Quoted 2 lines

Why should this be done in the kernel rather than libc? libc is perfectly capable of specifying random numbers in the first argument of mmap.

Well, there is following reasons:
1. It should be done in any libc implementation, what is not possible IMO;

Is this really so helpful?

Yes, ASLR is one of very important mitigation techniques which are really used to protect applications. If there is no ASLR, it is very easy to exploit vulnerable application and compromise the system. We can’t just fix all the vulnerabilities right now, thats why we have mitigations - techniques which are makes exploitation more hard or impossible in some cases.

Quoted 6 lines

Quoted 1 line

Thats why it is helpful.

I am not questioning ASLR in general. I am asking whether we really need per mmap ASLR in general. I can imagine that some environments want to pay the additional price and other side effects, but considering this can be achieved by libc, why to add more code to the kernel?

I believe this is the only one right place for it. Adding these 200+ lines of code we give this feature for any user - on desktop, on server, on IoT device, on SCADA, etc. But if only glibc will implement ‘user-mode-aslr’ IoT and SCADA devices will never get it.

Quoted 38 lines · Ilya Smith

Quoted 31 lines · Michal Hocko

Quoted 27 lines · Ilya Smith

Quoted 14 lines · Michal Hocko

Quoted 10 lines · Ilya Smith

Quoted 10 lines · Matthew Wilcox

Quoted 5 lines · Ilya Smith

Current implementation doesn't randomize address returned by mmap. All the entropy ends with choosing mmap_base_addr at the process creation. After that mmap build very predictable layout of address space. It allows to bypass ASLR in many cases. This patch make randomization of address on any mmap call.

Quoted 6 lines

Quoted 4 lines

Quoted 2 lines

Why should this be done in the kernel rather than libc? libc is perfectly capable of specifying random numbers in the first argument of mmap.

Well, there is following reasons:
1. It should be done in any libc implementation, what is not possible IMO;

Is this really so helpful?

Yes, ASLR is one of very important mitigation techniques which are really used to protect applications. If there is no ASLR, it is very easy to exploit vulnerable application and compromise the system. We can’t just fix all the vulnerabilities right now, thats why we have mitigations - techniques which are makes exploitation more hard or impossible in some cases.

Quoted 6 lines

Quoted 1 line

Thats why it is helpful.

I am not questioning ASLR in general. I am asking whether we really need per mmap ASLR in general. I can imagine that some environments want to pay the additional price and other side effects, but considering this can be achieved by libc, why to add more code to the kernel?

Quoted 4 lines

I believe this is the only one right place for it. Adding these 200+ lines of code we give this feature for any user - on desktop, on server, on IoT device, on SCADA, etc. But if only glibc will implement ‘user-mode-aslr’ IoT and SCADA devices will never get it.

I guess it would really help if you could be more specific about the class of security issues this would help to mitigate. My first understanding was that we we need some randomization between program executable segments to reduce the attack space when a single address leaks and you know the segments layout (ordering). But why do we need _all_ mmaps to be randomized. Because that complicates the implementation consirably for different reasons you have mentioned earlier.

Do you have any specific CVE that would be mitigated by this randomization approach?
I am sorry, I am not a security expert to see all the cosequences but a vague - the more randomization the better - sounds rather weak to me.

Quoted 1 line

/dev/[u]random is not sufficient?

Using /dev/[u]random makes 3 syscalls - open, read, close. This is a performance issue.

Quoted 2 lines

Well, I am pretty sure userspace can implement proper free ranges tracking…

I think we need to know what libc developers will say on implementing ASLR in user-mode. I am pretty sure they will say ‘nether’ or ‘some-day’. And problem of ASLR will stay forever.

Quoted 4 lines · Ilya Smith

Quoted 1 line

/dev/[u]random is not sufficient?

Using /dev/[u]random makes 3 syscalls - open, read, close. This is a performance issue.

You may want to take a look at the getrandom(2) system call, which is the recommended way getting secure random numbers from the kernel.

Quoted 6 lines

Quoted 2 lines

Well, I am pretty sure userspace can implement proper free ranges tracking…

I think we need to know what libc developers will say on implementing ASLR in user-mode. I am pretty sure they will say ‘nether’ or ‘some-day’. And problem of ASLR will stay forever.

Why can't you send patches to the libc developers?

Quoted 4 lines · Ilya Smith

Quoted 1 line

/dev/[u]random is not sufficient?

Using /dev/[u]random makes 3 syscalls - open, read, close. This is a performance issue.

You may want to take a look at the getrandom(2) system call, which is the recommended way getting secure random numbers from the kernel.

Quoted 6 lines

Quoted 2 lines

Well, I am pretty sure userspace can implement proper free ranges tracking…

I think we need to know what libc developers will say on implementing ASLR in user-mode. I am pretty sure they will say ‘nether’ or ‘some-day’. And problem of ASLR will stay forever.

Why can't you send patches to the libc developers?

Regards,

- Ted

Quoted 31 lines · Michal Hocko

Quoted 27 lines · Ilya Smith

Quoted 14 lines · Michal Hocko

Quoted 10 lines · Ilya Smith

Quoted 10 lines · Matthew Wilcox

Quoted 5 lines · Ilya Smith

Current implementation doesn't randomize address returned by mmap. All the entropy ends with choosing mmap_base_addr at the process creation. After that mmap build very predictable layout of address space. It allows to bypass ASLR in many cases. This patch make randomization of address on any mmap call.

Quoted 6 lines

Quoted 4 lines

Quoted 2 lines

Why should this be done in the kernel rather than libc? libc is perfectly capable of specifying random numbers in the first argument of mmap.

Well, there is following reasons:
1. It should be done in any libc implementation, what is not possible IMO;

Is this really so helpful?

Yes, ASLR is one of very important mitigation techniques which are really used to protect applications. If there is no ASLR, it is very easy to exploit vulnerable application and compromise the system. We can’t just fix all the vulnerabilities right now, thats why we have mitigations - techniques which are makes exploitation more hard or impossible in some cases.

Quoted 6 lines

Quoted 1 line

Thats why it is helpful.

I am not questioning ASLR in general. I am asking whether we really need per mmap ASLR in general. I can imagine that some environments want to pay the additional price and other side effects, but considering this can be achieved by libc, why to add more code to the kernel?

I believe this is the only one right place for it. Adding these 200+ lines of code we give this feature for any user - on desktop, on server, on IoT device, on SCADA, etc. But if only glibc will implement ‘user-mode-aslr’ IoT and SCADA devices will never get it.

I agree: pushing this off to libc leaves a lot of things unprotected. I think this should live in the kernel. The question I have is about making it maintainable/readable/etc.

The state-of-the-art for ASLR is moving to finer granularity (over just base-address offset), so I'd really like to see this supported in the kernel. We'll be getting there for other things in the future, and I'd like to have a working production example for researchers to study, etc.

Quoted 9 lines · Kees Cook

I agree: pushing this off to libc leaves a lot of things unprotected. I think this should live in the kernel. The question I have is about making it maintainable/readable/etc.

The state-of-the-art for ASLR is moving to finer granularity (over just base-address offset), so I'd really like to see this supported in the kernel. We'll be getting there for other things in the future, and I'd like to have a working production example for researchers to study, etc.

One thing we need is to limit the fragmentation of this approach. Even on 64-bit systems, we can easily get into a situation where there isn't space to map a contiguous terabyte.

Quoted 9 lines · Kees Cook

I agree: pushing this off to libc leaves a lot of things unprotected. I think this should live in the kernel. The question I have is about making it maintainable/readable/etc.

The state-of-the-art for ASLR is moving to finer granularity (over just base-address offset), so I'd really like to see this supported in the kernel. We'll be getting there for other things in the future, and I'd like to have a working production example for researchers to study, etc.

One thing we need is to limit the fragmentation of this approach. Even on 64-bit systems, we can easily get into a situation where there isn't space to map a contiguous terabyte.

The default limit of only 65536 VMAs will also quickly come into play if consecutive anon mmaps don't get merged. Of course this can be raised, but it has significant resource and performance (fork) costs.

Quoted 4 lines

The default limit of only 65536 VMAs will also quickly come into play if consecutive anon mmaps don't get merged. Of course this can be raised, but it has significant resource and performance (fork) costs.

Could the random mmap address chooser look for how many existing VMAs have space before/after and the right attributes to merge with the new one you want to create? If this is above some threshold (100?) then pick one of them randomly and allocate the new address so that it will merge from below/above with an existing one.

That should still give you a very high degree of randomness, but prevent out of control numbers of VMAs from being created.

Quoted 9 lines · Kees Cook

I agree: pushing this off to libc leaves a lot of things unprotected. I think this should live in the kernel. The question I have is about making it maintainable/readable/etc.

The state-of-the-art for ASLR is moving to finer granularity (over just base-address offset), so I'd really like to see this supported in the kernel. We'll be getting there for other things in the future, and I'd like to have a working production example for researchers to study, etc.

One thing we need is to limit the fragmentation of this approach. Even on 64-bit systems, we can easily get into a situation where there isn't space to map a contiguous terabyte.

Quoted 5 lines · Ilya Smith

Current implementation doesn't randomize address returned by mmap. All the entropy ends with choosing mmap_base_addr at the process creation. After that mmap build very predictable layout of address space. It allows to bypass ASLR in many cases. This patch make randomization of address on any mmap call.

Why should this be done in the kernel rather than libc? libc is perfectly capable of specifying random numbers in the first argument of mmap.

Quoted 7 lines · Matthew Wilcox

Quoted 5 lines · Ilya Smith

Current implementation doesn't randomize address returned by mmap. All the entropy ends with choosing mmap_base_addr at the process creation. After that mmap build very predictable layout of address space. It allows to bypass ASLR in many cases. This patch make randomization of address on any mmap call.

Quoted 2 lines

Why should this be done in the kernel rather than libc? libc is perfectly capable of specifying random numbers in the first argument of mmap.

Generally libc does not have a view of the current vm maps, and thus in passing "random numbers", they would have to be uniform across the whole vm space and thus non-uniform once the kernel rounds up to avoid existing mappings.

Also this would impose requirements that libc be
aware of the kernel's use of the virtual address space and what's available to userspace -- for example, on 32-bit archs whether 2GB, 3GB, or full 4GB (for 32-bit-user-on-64-bit-kernel) is available, and on 64-bit archs where fewer than the full 64 bits are actually valid in addresses, what the actual usable pointer size is. There is currently no clean way of conveying this information to userspace.

Quoted 11 lines · Rich Felker

Quoted 9 lines · Matthew Wilcox

Quoted 5 lines · Ilya Smith

Current implementation doesn't randomize address returned by mmap. All the entropy ends with choosing mmap_base_addr at the process creation. After that mmap build very predictable layout of address space. It allows to bypass ASLR in many cases. This patch make randomization of address on any mmap call.

Why should this be done in the kernel rather than libc? libc is perfectly capable of specifying random numbers in the first argument of mmap.

Quoted 4 lines

Generally libc does not have a view of the current vm maps, and thus in passing "random numbers", they would have to be uniform across the whole vm space and thus non-uniform once the kernel rounds up to avoid existing mappings.

I'm aware that you're the musl author, but glibc somehow manages to provide etext, edata and end, demonstrating that it does know where at least some of the memory map lies.

Virtually everything after that is
brought into the address space via mmap, which at least glibc intercepts,

Quoted 7 lines

Also this would impose requirements that libc be
aware of the kernel's use of the virtual address space and what's available to userspace -- for example, on 32-bit archs whether 2GB, 3GB, or full 4GB (for 32-bit-user-on-64-bit-kernel) is available, and on 64-bit archs where fewer than the full 64 bits are actually valid in addresses, what the actual usable pointer size is. There is currently no clean way of conveying this information to userspace.

Huh, I thought libc was aware of this. Also, I'd expect a libc-based implementation to restrict itself to, eg, only loading libraries in the bottom 1GB to avoid applications who want to map huge things from running out of unfragmented address space.

Quoted 4 lines

Huh, I thought libc was aware of this. Also, I'd expect a libc-based implementation to restrict itself to, eg, only loading libraries in the bottom 1GB to avoid applications who want to map huge things from running out of unfragmented address space.

That seems like a rather arbitrary expectation and I'm not sure why you'd expect it to result in less fragmentation rather than more. For example if it started from 1GB and worked down, you'd immediately reduce the contiguous free space from ~3GB to ~2GB, and if it started from the bottom and worked up, brk would immediately become unavailable, increasing mmap pressure elsewhere.

Quoted 11 lines · Rich Felker

Quoted 4 lines

Huh, I thought libc was aware of this. Also, I'd expect a libc-based implementation to restrict itself to, eg, only loading libraries in the bottom 1GB to avoid applications who want to map huge things from running out of unfragmented address space.

That seems like a rather arbitrary expectation and I'm not sure why you'd expect it to result in less fragmentation rather than more. For example if it started from 1GB and worked down, you'd immediately reduce the contiguous free space from ~3GB to ~2GB, and if it started from the bottom and worked up, brk would immediately become unavailable, increasing mmap pressure elsewhere.

By *not* limiting yourself to the bottom 1GB, you'll almost immediately fragment the address space even worse. Just looking at 'ls' as a hopefully-good example of a typical app, it maps:

	linux-vdso.so.1 (0x00007ffef5eef000)
	libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007fb3657f5000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb36543b000)
	libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fb3651c9000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fb364fc5000)
	/lib64/ld-linux-x86-64.so.2 (0x00007fb365c3f000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fb364da7000)

The VDSO wouldn't move, but look at the distribution of mapping 6 things into a 3GB address space in random locations. What are the odds you have a contiguous 1GB chunk of address space? If you restrict yourself to the bottom 1GB before running out of room and falling back to a sequential allocation, you'll prevent a lot of fragmentation.

Quoted 11 lines · Rich Felker

Quoted 9 lines · Matthew Wilcox

Quoted 5 lines · Ilya Smith

Current implementation doesn't randomize address returned by mmap. All the entropy ends with choosing mmap_base_addr at the process creation. After that mmap build very predictable layout of address space. It allows to bypass ASLR in many cases. This patch make randomization of address on any mmap call.

Why should this be done in the kernel rather than libc? libc is perfectly capable of specifying random numbers in the first argument of mmap.

Quoted 4 lines

Generally libc does not have a view of the current vm maps, and thus in passing "random numbers", they would have to be uniform across the whole vm space and thus non-uniform once the kernel rounds up to avoid existing mappings.

I'm aware that you're the musl author, but glibc somehow manages to provide etext, edata and end, demonstrating that it does know where at least some of the memory map lies.

Current implementation doesn't randomize address returned by mmap. All the entropy ends with choosing mmap_base_addr at the process creation. After that mmap build very predictable layout of address space. It allows to bypass ASLR in many cases. This patch make randomization of address on any mmap call.

Hi!

Quoted 5 lines

Current implementation doesn't randomize address returned by mmap. All the entropy ends with choosing mmap_base_addr at the process creation. After that mmap build very predictable layout of address space. It allows to bypass ASLR in many cases. This patch make randomization of address on any mmap call.

How will this interact with people debugging their application, and getting different behaviours based on memory layout?

strace, strace again, get different results?

Hi

Quoted 13 lines · Pavel Machek

Hi!

Quoted 5 lines

Current implementation doesn't randomize address returned by mmap. All the entropy ends with choosing mmap_base_addr at the process creation. After that mmap build very predictable layout of address space. It allows to bypass ASLR in many cases. This patch make randomization of address on any mmap call.

How will this interact with people debugging their application, and getting different behaviours based on memory layout?

Quoted 2 lines

strace, strace again, get different results?

Honestly I’m confused about your question. If the only one way for debugging application is to use predictable mmap behaviour, then something went wrong in this live and we should stop using computers at all.

Quoted 18 lines · Ilya Smith

Hi

Quoted 15 lines · Pavel Machek

Hi!

Quoted 5 lines

Current implementation doesn't randomize address returned by mmap. All the entropy ends with choosing mmap_base_addr at the process creation. After that mmap build very predictable layout of address space. It allows to bypass ASLR in many cases. This patch make randomization of address on any mmap call.

How will this interact with people debugging their application, and getting different behaviours based on memory layout?

strace, strace again, get different results?

Quoted 3 lines

Honestly I’m confused about your question. If the only one way for debugging application is to use predictable mmap behaviour, then something went wrong in this live and we should stop using computers at all.

I'm not saying "only way". I'm saying one way, and you are breaking that. There's advanced stuff like debuggers going "back in time".

Hi!

Quoted 5 lines

Current implementation doesn't randomize address returned by mmap. All the entropy ends with choosing mmap_base_addr at the process creation. After that mmap build very predictable layout of address space. It allows to bypass ASLR in many cases. This patch make randomization of address on any mmap call.

How will this interact with people debugging their application, and getting different behaviours based on memory layout?

strace, strace again, get different results?