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 09:17:28 +0100
From:	Pavel Machek <pavel@....cz>
To:	Willy Tarreau <w@....eu>
Cc:	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...e.hu>,
	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

Hi!

> > >>> *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?
No.
								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
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/