On 11:41 Wed 03 Jun , Christoph Lameter wrote:> On Wed, 3 Jun 2009, Stephen Smalley wrote:> > > > If one remaps page 0 then the kernel checks for NULL pointers of various> > > flavors are bypassed and this may be exploited in various creative ways> > > to transfer data from kernel space to user space.> > >> > > Fix this by not allowing the remapping of page 0. Return -EINVAL if> > > such a mapping is attempted.

Christopher, crippling the system is truly not the way to fix this.There are many legitimate users of private|fixed mappings at 0. Inaddition, if you want to go ahead and break POSIX, at least make sureyour patch closes the loophole.

Given these circumstances, are you proposing this over my patch?

Linus already pointed out the main (functional) problem about it. Itseems you are also confusing the issue, albeit already realized it canbe a venue of attack, which is good.

For instance, there are many scenarios in which a fixed mapping can beused in a non-zero address to abuse kernel flaws... your patch isuseless against those.

Please let me remind you that my original intent was to preventkmalloc(0) from leading to potential NULL or offset-from-NULL accessissues, and not deterring NULL pointer deferences in kernel-land whichis a whole different thing (see PaX UDEREF for clues on this).

If you want to solve NULL/ptr deference abuse from userland, you betterstart thinking about separating kernel virtual address space fromuserland's, with the performance impact that implies. Few architecturesprovide this capability without performance hit, and x86 ain't one ofthem.

> mmap_min_addr depends on CONFIG_SECURITY which establishes various> strangely complex "security models".> > The system needs to be secure by default.

Correct, so what was wrong with my patch again? That the original twoline change was written by the PaX team?

Come on chap, It's not like you will lose your bragging rights amongyour peers for admitting that I was right. Just this one time. I won'ttell anybody. Promise.