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 10:03:37 +0000
From:	Alan Cox <>
To:	"H. Peter Anvin" <>
Cc:	Willy Tarreau <>, Ingo Molnar <>,
	Pavel Machek <>, Avi Kivity <>,
	Matteo Croce <>,
	Sven-Haegar Koch <>,
Subject: Re: i686 quirk for AMD Geode

On Tue, 10 Nov 2009 22:15:58 -0800
"H. Peter Anvin" <> wrote:

> On 11/10/2009 09:52 PM, Willy Tarreau wrote:
> > 
> >   - 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 !
> > 
> Do you have *any* *evidence* *whatsoever* for that assertion?!
> I personally will consider something that doesn't implement proper
> security check to be a potential security hole and will NAK the patch.

Assuming you are doing the fault handling only for a CPU where you expect
to need it (which would be wise I think) then it's a question of whether
the CPU supports NX in the first place.

Even if it does the only thing you can reasonably hope to do is move the
program counter one instruction into the next page. The user access
checks will trap any attempt to cross 0xC0000000 and the protection
fault might just occur one or part of an instruction on in the other

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