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]
Message-ID: <476932C1.8040703@qumranet.com>
Date:	Wed, 19 Dec 2007 17:03:29 +0200
From:	Avi Kivity <avi@...ranet.com>
To:	"David P. Reed" <dpreed@...d.com>
CC:	Thomas Gleixner <tglx@...utronix.de>, linux-kernel@...r.kernel.org,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Rene Herman <rene.herman@...access.nl>,
	Pavel Machek <pavel@....cz>,
	kvm-devel <kvm-devel@...ts.sourceforge.net>
Subject: Re: [PATCH] x86_64: fix problems due to use of "outb" to port 80
 on some AMD64x2 laptops, etc.

David P. Reed wrote:
> Avi Kivity wrote:
>> kvm will forward a virtual machine's writes to port 0x80 to the real 
>> port.  The reason is that the write is much faster than exiting and 
>> emulating it; the difference is measurable when compiling kernels.
>>
>> Now if the cause is simply writing to port 0x80, then we must stop 
>> doing that.  But if the reason is the back-to-back writes, when we 
>> can keep it, since the other writes will be trapped by kvm and 
>> emulated.  Do you which is the case?
>>
> As for kvm, I don't have enough info to know anything about that.  Is 
> there a test you'd like me to try?
>

I have a test, but I see that it is broken for mainline.  I'll update it 
eventually, but...

> I think you are also asking if the crash on these laptops is caused 
> only by back-to-back writes.  Actually, it doesn't seem to matter if 
> they are back to back.  I can cause the crash if the writes to 80 are 
> very much spread out in time - it seems only to matter how many of 
> them get executed - almost as if there is a buffer overflow.  (And of 
> course if you do back to back writes to other ports that are 
> apparently fully unused, such as 0xED on my machine, no crash occurs).
>
> I believe (though no one seems to have confirming documentation from 
> the chipset or motherboard vendor) that port 80 is actually functional 
> for some unknown function on these machines.   (They do respond to 
> "in" instructions faster than a bus cycle abort does - more evidence).

That seems to be sufficient evidence for me to remove port 0x80 
pass-through from kvm and emulate it instead.  Given that port 80 writes 
take 1 microsecond, and that an in-kernel exit handler takes a similar 
amount of time, there won't be any significant performance loss.

-- 
error compiling committee.c: too many arguments to function

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

Powered by Openwall GNU/*/Linux Powered by OpenVZ