Re: UVM and the NULL page

[David Holland <dholland-tech%netbsd.org@localhost>]

On Tue, Dec 27, 2016 at 11:15:59AM -0500, Mouse wrote:
 > >> Perhaps it's time to implement null pointers as something other than
 > >> all-bits-zero?
 > > Wouldn't help much; the next obvious (probably only viable) candidate
 > > is all-bits-1 and then you just need a slightly larger offset from it
 > > to jump to userspace.

Plus there's the problem that if one of these accidents occurs, the
kernel is as likely to have accidentally jumped to (or dereferenced
and trusted, or whatever, an explicit null pointer, with whatever bit
encoding that has, as an all-bits-0 pointer. Perhaps more likely.

 > Depends on the architecture.  For example, on the VAX, I would say
 > c0000000 and e0000000 would be prime candidates, because the high
 > quarter of the possible address space is permanently reserved.

Then the bit encoding for null should obviously be 0xdeadbeef :-)

(it is better, i.e., more likely for it to fault if used by accident
even with a large offset, if it's unaligned)

 > Machines with ring-based addressing architectures (does NetBSD run on
 > any such?) might have a ring that's ideal for the purpose.

There's i386... but we don't use a memory model that uses segment
addressing directly. If we did, though, it's segment 0 that's
hardwired to be invalid.

More RISCish architectures generally either don't have a hardwired
reserved region of virtual space, or only have invalid ranges where
you have to assume that some future processor model will eventually
allocate them for something.

If you don't have a hardware-reserved address, then you're designating
a reserved region yourself (regardless of what it is) and relying on
the VM system to not map it. At which point zero is as good (or bad)
as anything else.

There was a bunch of fuss before about being able to "fool" UVM into
mapping at address 0 in spite of this supposedly being disabled; for
some reason the "fix" was to bodge around it rather than to fix UVM to
honor its specification, which I don't understand. If you can fool UVM
into mapping user stuff at 0, what guarantee do you have that you
can't fool UVM into mapping user stuff over the kernel?

I would expect the GE whatsit that Multics ran on would deny execute
permission on less-privileged (and non-"conforming") segments, but
<troll>that hardware's long been irrelevant</troll>.

-- 
David A. Holland
dholland%netbsd.org@localhost