linux-kernel - Re: Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

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:	Tue, 08 Jan 2008 18:52:42 -0800
From:	Zachary Amsden <zach@...are.com>
To:	"David P. Reed" <dpreed@...d.com>, Avi Kivity <avi@...amnet.com>
Cc:	Christer Weinigel <christer@...nigel.se>,
	Ondrej Zary <linux@...nbow-software.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Rene Herman <rene.herman@...access.nl>,
	Bodo Eggert <7eggert@....de>, Ingo Molnar <mingo@...e.hu>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Paul Rolland <rol@...917.net>, Pavel Machek <pavel@....cz>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...hat.com>,
	rol <rol@...be.net>
Subject: Re: Re: [PATCH] x86: provide a DMI based port 0x80
	I/O delay override.

On Tue, 2008-01-08 at 14:15 -0500, David P. Reed wrote:
> Alan Cox wrote:
> > The natsemi docs here say otherwise. I trust them not you.
> >   
> As well you should. I am honestly curious (for my own satisfaction) as 
> to what the natsemi docs say the delay code should do  (can't imagine 
> they say "use io port 80 because it is unused").  I don't have any 

What is the outcome of this thread?  Are we going to use timing based
port delays, or can we finally drop these things entirely on 64-bit
architectures?

I a have a doubly vested interest in this, both as the owner of an
affected HP dv9210us laptop and as a maintainer of paravirt code - and
would like 64-bit Linux code to stop using I/O to port 0x80 in both
cases (as I suspect would every other person involved with
virtualization).

BTW, it isn't ever safe to pass port 0x80 through to hardware from a
virtual machine; some OSes use port 0x80 as a hardware available scratch
register (I believe Darwin/x86 did/does this during boot).  This means
simultaneous execution of two virtual machines can interleave port 0x80
values or share data with a hardware provided covert channel.  This
means KVM should be trapping port 0x80 access, which is really
expensive, or alternatively, Linux should not be using port 0x80 for
timing bus access on modern (64-bit) hardware.

I've tried to follow this thread, but with all the jabs, 1-ups, and
obscure legacy hardware pageantry going on, it isn't clear what we're
really doing.

Thanks,

Zach

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