linux-kernel - Re: i686 quirk for AMD Geode

lists.openwall.net		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 linux-cve-announce 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 06:52:20 +0100
From:	Willy Tarreau <w@....eu>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Ingo Molnar <mingo@...e.hu>, Pavel Machek <pavel@....cz>,
	Avi Kivity <avi@...hat.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Matteo Croce <technoboy85@...il.com>,
	Sven-Haegar Koch <haegar@...net.de>,
	linux-kernel@...r.kernel.org
Subject: Re: i686 quirk for AMD Geode

On Tue, Nov 10, 2009 at 02:47:20PM -0800, H. Peter Anvin wrote:
> On 11/10/2009 02:42 PM, Willy Tarreau wrote:
> > On Tue, Nov 10, 2009 at 11:20:31PM +0100, Ingo Molnar wrote:
> >>
> >> * H. Peter Anvin <hpa@...or.com> wrote:
> >>
> >>> *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 !

On the other hand, I certainly understand why this would be
an important check in a complete emulator which could parse
and emulate a flow of instructions.

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.

Regards,
Willy

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/