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:	Mon, 23 Nov 2009 11:27:58 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Willy Tarreau <w@....eu>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	Matt Thrailkill <matt.thrailkill@...il.com>,
	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

Willy Tarreau <w@....eu> writes:

> On Wed, Nov 11, 2009 at 09:31:26PM -0800, H. Peter Anvin wrote:
>> On 11/11/2009 09:27 PM, Willy Tarreau wrote:
>> > 
>> > Right. However we just noticed that with the KVM emulator, you
>> > can make it loop for a long time if you feed it with prefixes
>> > only. For instance, write a function which does zillions of 0x66
>> > (data size prefix) then return (0xC3) : 66 66 66 ... 66 C3.
>> > 
>> > This is typically the sort of things we must be very careful about
>> > in emulators, because we don't want users to steal large amounts
>> > of system CPU time doing nothing.
>> > 
>> 
>> That is a (serious) bug in the KVM interpreter, and indeed the exact
>> kind of issues interpreters tend to have... which is why I'd like one
>> piece of code with one set of bugs, and more eyeballs on that one piece
>> of code so they can be fixed.
>
> Well, I could try to work on a fix (basically the same principle as in
> mine, with prefix flags), but I simply don't know how to test the code.
> I've never experimented with KVM yet and learned it embeds an emulator
> for the first time a few days ago in this thread :-/ If it's easy to
> make use of it, I'm not opposed to try.

When working on dosemu and emulating EGA 16 color graphics we had to
unmap the frame buffer so we would cause move instructions to fault.
Trapping for each mov instruction in the loops that wrote to the frame
buffer was unusably slow.  Ultimately that was fixed by trapping on
the first instruction and then running in the emulator until we had
gone N instructions without hitting an instruction we would trap for.
The result was usable software emulated EGA graphics.

I expect the same logic will apply any time there is a trapped and
emulated instruction in an inner loop.  Emulating the entire loop
will be more efficient than trapping for each loop iteration.

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