lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 11 Nov 2009 09:17:28 +0100
From:	Pavel Machek <>
To:	Willy Tarreau <>
Cc:	"H. Peter Anvin" <>, Ingo Molnar <>,
	Avi Kivity <>,
	Alan Cox <>,
	Matteo Croce <>,
	Sven-Haegar Koch <>,
Subject: Re: i686 quirk for AMD Geode


> > >>> *THIS* is the kind of complexity that makes me think that having a 
> > >>> single source for all interpretation done in the kernel is the 
> > >>> preferred option.
> > >>
> > >> Definitely agreed ... The NX code is quite a maze right now, so changes 
> > >> to it should come generously laced with cleanups.
> > > 
> > > BTW, I don't see why we should be impacted by NX. Trying to
> > > execute from an NX page would return a SEGV, not SIGILL, so
> > > we should not be bothered, am I wrong ?
> > 
> > Yes.  Consider a page-crossing instruction.
> OK, but to be pragmatic, NX is there to prevent execution of
> instructions in the stack (or heap) during buffer overflows.
> If we only implement the few instructions lised in previous
> mail, there is very little benefit to check for NX :
>   - those instructions cannot jump to other code, they just
>     change one register or memory location at most (or just nop)
>   - once we return from the signal handler, if we have crossed
>     a NX page boundary, the program will segfault anyway, taking
>     with it the change we just completed.
>   - last, the probability of having an NX page just after an
>     executable one seems too tight to me to even constitute
>     an attack vector ! BTW, I'm not even certain that all CPUs
>     correctly implement this check !

Yes, you can probably "get away" with it. But I would not want to
debug problems on systems with half-instruction-emulation. Please do
it right, or not at all.

> So in short, I think we could reasonably implement CMOV/NOPL
> with the instruction length control, with getuser for data
> accesses but without checking the code pages permissions if
> we know that the CPU could already fetch the beginning of
> the instruction correctly to cause an invalid opcode trap.
> I'm not saying this is perfect, just that this is reasonable.

Reasonable hack to get distro booting yes. Reasonable for mainline?

(cesky, pictures)
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists