| |||||||||||||
Linux 2.6.30 exploit postedLinux 2.6.30 exploit postedPosted Jul 17, 2009 16:57 UTC (Fri) by iabervon (subscriber, #722)Parent article: Linux 2.6.30 exploit posted
Every time a null-pointer-dereference bug comes up, I wonder why the kernel doesn't ensure on entry to the kernel from a userspace task that mmaps at address 0 that null pointers will cause a fault, and refuse to handle such a fault when it occurs within the kernel. It's not like the kernel ever needs to read from virtual address 0, even if userspace does, or that userspace cares a ton about avoiding cache misses at address 0. I think userspace processes that mmap at address 0 are actually running code that expects this to be a trap of some sort handled by the operating system, more like mmio than just ordinary RAM, or they're so old that they don't expect memory access to be faster than taking the fault on a modern system will be anyway.
(Log in to post comments)
NULL pointers in kernel space Posted Jul 17, 2009 17:13 UTC (Fri) by corbet (editor, #1) [Link] I think the only way that could be done would be to just remove the user-space page tables entirely on entry into the kernel. There's a precedent for that - the 4G/4G patches did it years ago. But it's a very expensive thing to do, to the point that people wouldn't really stand for it. Far better to just configure the kernel not to allow mappings at zero.
NULL pointers in kernel space Posted Jul 18, 2009 1:15 UTC (Sat) by proski (subscriber, #104) [Link] Perhaps the 4G/4G split was wrongly marketed as a way to use more memory. Had it been presented as a security measure, it would have a better chance. Many users are ready to pay a high price for security.
NULL pointers in kernel space Posted Jul 18, 2009 9:09 UTC (Sat) by PaXTeam (subscriber, #24616) [Link]
given the security track record of the 4:4 split patch, i don't think you'd wanted to pay that price ;)
mmap(0,,,MAP_FIXED,,) is *useful* Posted Jul 17, 2009 17:41 UTC (Fri) by jreiser (subscriber, #11027) [Link] For over thirty years I have been using mmap(0,,,MAP_FIXED,,) to implement fraid, a file debugger. Invoke gdb on fraid, run with the name of the target file. fraid does open+fstat+mmap(0,.st_size,,MAP_FIXED,fd,0); then traps into gdb. That's the whole program: a dozen lines. The identity mapping from offset in the file to address in the address space of the debugger is exceedingly powerful. This is not something to give up, ever.
mmap(0,,,MAP_FIXED,,) is *useful* Posted Jul 17, 2009 18:15 UTC (Fri) by quotemstr (subscriber, #45331) [Link]
I don't understand -- how is a "file debugger" useful?
mmap(0,,,MAP_FIXED,,) is *useful* Posted Jul 17, 2009 18:32 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
Limit it to running only root, then. Or add a special capability.
when all you have is a hammer Posted Jul 17, 2009 19:34 UTC (Fri) by xorbe (subscriber, #3165) [Link]
um seriously, using GDB to examine a binary file is just the wrong tool ... clever, but wrong!
mmap(0,,,MAP_FIXED,,) is *useful* Posted Jul 17, 2009 19:39 UTC (Fri) by iabervon (subscriber, #722) [Link]
It's not the address space of the debugger, it's the process being debugged, right? So you wouldn't actually have any code running while the processor has a mapping in the TLB at address zero, because fraid is stopped and gdb is probing it indirectly. So you wouldn't care if any process which has a mapping at address zero has lousy performance on return from interrupt or system call.
|
|||||||||||||