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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 11 Nov 2009 08:15:28 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Willy Tarreau <w@....eu>
CC:	Alan Cox <alan@...rguk.ukuu.org.uk>, 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 11/11/2009 02:43 AM, Willy Tarreau wrote:
> 
> 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.
> 

RIGHT NOW. Except that, guess what, once we have emulation in the
kernel, people are going to demand new instructions to cover *new* gaps
in the instruction set.  And yes, this is going to mean 64 bits and what
not.

The main reason to unify with KVM is not because KVM is doing everything
right (I am perfectly aware that it doesn't), but because I don't really
want to see a plethora of half-arsed emulators spread across the kernel,
each with its own bugs.  If unified, at least there is one codebase
which can get fixed.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

--
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/