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 17:00:51 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Daniel Pittman <daniel@...space.net>
CC:	Alan Cox <alan@...rguk.ukuu.org.uk>, Avi Kivity <avi@...hat.com>,
	Willy Tarreau <w@....eu>, Pavel Machek <pavel@....cz>,
	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 04:51 PM, Daniel Pittman wrote:
>>
>> Consider SSE3, for example.  Why should the same concept not apply to
>> SSE3 instructions as to CMOV?
> 
> FWIW, the issue of the binary-only flashplayer.so came up later in the thread,
> but to add my few cents:
> 
> When flash 10 was released the binary only 64-bit version generated
> instructions from the LAHF set unconditionally, in part because Windows chose
> to emulate those on the very few x86-64 platforms that didn't do them in
> hardware.
> 
> At that time it would have been very nice from a "user support" point of view
> to be able to add LAHF emulation to support the software.  Yes, it is ugly,
> binary-only code, but it is reasonably popular...
> 
> ...in the end, in fact, popular enough to have at least a couple of people
> I know purchase a new CPU that did implement it, just for flash on Linux.

The main use case for emulation is indeed to support binary-only or
otherwise precompiled software that exposes holes in the instruction
set.  As such, emulation can also be used to "raise the baseline", which
can be a highly desirable thing to do.

My point in all of this is that this is not a static problem, and that
if we're going to do emulation we need to consider the requirements
going forward.  I would *prefer* to have only one interpreter to deal
with when it's broken, and I certainly trust Avi & co to do the right
thing, but I'm certainly willing to entertain technical reasons why it
is not the right thing to do -- *not just now but in the future*.  The
latter is an absolutely critical constraint, though.

Once we have a general enough interpreter framework, we can add new
instructions as needed; it should make it a lot easier to phase in new
instructions while not breaking old legacy machines.

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