linux-kernel - Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64 with MCP51 laptops

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:	Fri, 7 Dec 2007 16:04:39 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	Andi Kleen <andi@...stfloor.org>
Cc:	"David P. Reed" <dpreed@...d.com>, linux-kernel@...r.kernel.org,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: RFC: outb 0x80 in inb_p, outb_p harmful on some modern AMD64
 with MCP51 laptops

> modern CPU compared to the bus. But the delay really needs to be something
> that is about IO port speed. Ok in theory you could try to measure
> a outb using RDTSC and then use udelay, but first you would need

You don't need to. Port 0x80 historically is about 8uS so just udelay(8)
and make sure the initial default delay is conservative enough before the
CPU speed is computed.

0x80 should be fine for anything PC compatible anyway, its specifically
reserved as a debug port and supported for *exactly* that purpose by
many chipsets.

The afflicted laptop should really be taken up with the vendor. If its
got port 0x80 wrong gods knows what else it might have problems with.

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