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

On Wed, Nov 11, 2009 at 10:21:36AM +0000, Alan Cox wrote:
> 
> > So in my opinion, we should have :
> >   - CMOV (for 486, Pentium, C3, K6, ...)
> >   - NOPL (newcomer)
> > 
> > And if we want to extend down to i386 :
> >   - BSWAP (=htonl)
> >   - CMPXCHG (mutex)
> >   - XADD (never encoutered but cheap)
> > 
> > I still have the 2.4 patch for BSWAP, CMPXCHG, CMOV and XADD lying
> 
> If we go that far it needs a lot more thought and probably to use the KVM
> code simply because of all the complexities around prefixes and the like

well, ironically the KVM decoder can decode an infinite string
of prefixes while the very simple and limited one in the patch
I showed did correct checks for invalid cases (multiple segments,
repeated locks, etc...). It would only accept one data size prefix,
one address size prefix, one lock and one segment prefix.

I have nothing against the KVM one, it's just that it's a
full-featured emulator while we were speaking about a 686
emulators for lower-end processors. 98% of the instructions
supported by KVM will never be used for that purpose. This
is where I see a waste. We're comparing 7000 lines of code
supporting 64-bit, real mode, NX, etc... to 400. I fail to
see how we can guarantee that we do it right in that larger
code (and the example above proves it wrong).

And as you said, NX is not an issue on the CPUs we're
targetting.

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/

Powered by blists - more mailing lists