Submit #2299
closedPrevent mapping to page 0 on pc32
0%
Description
OpenBSD prevents mapping to page 0 to prevent certain
class of exploits.
It has been reported that it can break Wine.
I tested it on pc32.
Feedback welcomed.
Files
Updated by vsrinivas almost 13 years ago
Just some preliminary observations:
1) I'd prefer this be under a sysctl rather than require recompiling a kernel w/ a different VM_MIN_USER_ADDRESS.
2) VM_MIN_USER_ADDRESS is used for a number of other things in kernel; we'd have to look more closely at what this change does to them.
3) The changes to vm_mmap.c above only affect mcontrol and madvise; its not clear to me that changes to madvise() are required -- if you can't create a mapping at zero, there's no reason to check in madvise() that its being applied to 0, as the 'is-there-a-mapping' test will cover that.
I'd rather see something like this in kern_mmap():
/*
* Address range must be all in user VM space and not wrap.
*/
tmpaddr = addr + size;
if (tmpaddr < addr)
return (EINVAL);
if (VM_MAX_USER_ADDRESS > 0 && tmpaddr > VM_MAX_USER_ADDRESS)
return (EINVAL);
if (VM_MIN_USER_ADDRESS > 0 && addr < VM_MIN_USER_ADDRESS)
return (EINVAL);
if (addr NULL && zero_mmap_ok 0)
+ return (EINVAL);
where zero_mmap_ok comes from a sysctl that defaults to '0'. (this section is under a MAP_FIXED/MAP_TRYFIXED test.
5) fp_mmap() also exists; it is mostly a hacked up clone of kern_mmap. May need to be checked to see if null mappings can be made via checkpoints from it.
Updated by dillon over 3 years ago
- Description updated (diff)
- Status changed from New to Closed
We're cleaning up the bug database. I think I'm going to close this particular report for a few reasons. First, we do not want to disallow mmap()ings at address 0 per-say, its just that the default is to not put anything there in order to catch common null pointer indirection bugs. Actually disallowing such mappings can lead to issues with interpreters and other special-purpose applications.
For kernel accesses, modern CPUs have support to fault on accesses to userspace from kernel mode so that is not a pressing issue either.
I like the idea of the user address limits being sysctl'd, but there aren't any practical use cases. Since we are maximal in that regard, there also aren't any potential portability issues either. So I think... if someone really wanted to they could submit a quick patch for user access to such limits. For the kernel, defined constants are ideal due to miscellaneous calculations made with them.
-Matt