linux-kernel - Re: Re: [PATCH] x86: use explicit timing delay for pit accesses in kernel and pcspkr driver

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] [day] [month] [year] [list]

Date:	Thu, 21 Feb 2008 07:21:11 +0100
From:	Rene Herman <rene.herman@...access.nl>
To:	"David P. Reed" <dpreed@...d.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	Dmitry Torokhov <dtor_core@...ritech.net>,
	linux-kernel@...r.kernel.org
Subject: Re: Re: [PATCH] x86: use explicit timing delay for
 pit accesses in kernel and pcspkr driver

On 20-02-08 21:13, David P. Reed wrote:

> Actually, disparaging things as "one idiotic system" doesn't seem like a 
> long-term thoughtful process - it's not even accurate.

Whatever we think about systems using port 0x80, fact of the matter is that 
they do and outside of legacy stuff that isn't applicable to these systems, 
Linux needs to stop using it (post ACPI init at least) to be able to run on 
them.

As options of doing so we have:

1) Replace the port 0x80 I/O delay with nothing. Determined to be unsafe.

2) Replace 0x80 with another port. None are really available and DMI based 
switching gets to be unmaintainable and has a such been shot down.

3) Replace the port 0x80 I/O delay with a udelay(2). Should work well enough 
in practice for the remaining users outside legacy drivers after (Alan's) 
cleaning up.

The remaining (possible) problem is that pre calibration microseconds are a 
total fiction and at least PIT init happens before calibration. In practice 
I believe this might not be much of a real-world problem since for whatever 
initial value for loops_per_jiffy we get at least our old double short jump 
that is enough of a delay for 386 and 486 but I sympathise with anone, such 
as HPA, who'd consider my beliefs not a particular guarantee.

So, we need a more useful pre calibration udelay. Ugly as it might be, 
through something like the attached. Alan, could you perhaps comment?

With the problam surfacing only post ACPI init, the _last_ remaining option 
is talking to the PIT using port 0x80 at init and using udelay after but I 
myself will not be submitting a patch to do so. Insane mess.

It would be good to get this crap sorted relatively quickly so we can do 
away with the io_delay mongering even pre .26 again. It introduces boot 
parameters and as such becomes part of API somewhat, so if it's not going to 
stay let's kill it quickly.

Ren

View attachment "per-family-loops_per_jiffy.diff" of type "text/plain" (2526 bytes)