tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: UVM and the NULL page



Le 29/07/2016 à 22:42, Joerg Sonnenberger a écrit :
On Fri, Jul 29, 2016 at 10:08:48AM +0200, Maxime Villard wrote:
It is not possible to keep a sysctl, since VM_MIN_ADDRESS is a constant
used in assembly, so it won't be turned to a variable.

So find a different solution to fix the bugs.


Now, it is a little hard to know how many emulators or whatever rely on
null to be available. But many (most?) systems don't allow null nowadays,
and null dereferences are a well-known issue. It is more or less becoming
a standard. If a software fails on NetBSD because of a null mmap, then it
is likely to fail on many other systems.

Just because many newer ("hardened") systems break compatibility with
existing programs doesn't justify the same to be done to NetBSD.


I will commit [3] soon.

I strongly object that.

Joerg


This is something you generally don't need to remind people of, but I guess I'll
have to here: you are neither my boss, nor my manager, nor my father, nor
whoever. You don't get to tell me "find a different solution" with that tone,
especially when it is clear you didn't try to make any effort to understand the
issue.

You know - as well as I do - that NULL pointer dereferences are quite common,
and that it is the main way to execute malicious code in kernel mode. Allowing
NULL is a huge problem on architectures like amd64. The way you are talking
about compatibility sounds like you are ready to sacrifice the security of
almost every NetBSD user just to allow a few programs that make use of a mapping
model which has been known to be flawed for years. This is ridiculous.

When it comes to the way to fix it properly (which you clearly didn't try to
understand or investigate), we could try to improve the 'if' by not checking
specifically for MAP_FIXED, but the underlying code could still take NULL as a
hint because it is in the VM space. The only way to fix this is by changing the
VM range itself.

The VM range for a process is created here [1], and it uses VM_MIN_ADDRESS which
is architecture-dependent. But I have another idea. We could do the following:

	#define GUARD_NULL	(2 * PAGE_SIZE) /* defined somewhere */

	if (user_va0_disable)
		epp->ep_vm_minaddr = VM_MIN_ADDRESS + GUARD_NULL;
	else
		epp->ep_vm_minaddr = VM_MIN_ADDRESS;

We would also have to patch netbsd32 and linux32, because they redefine the
value. There is one architecture [2] which has a non-zero min address, but we
could set va0_disable to zero in it.

[1] https://nxr.netbsd.org/xref/src/sys/kern/kern_exec.c#401
[2] https://nxr.netbsd.org/xref/src/sys/arch/arm/include/arm32/vmparam.h#91


Home | Main Index | Thread Index | Old Index