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 dholl...@netbsd.org