linux-kernel - 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] [thread-next>] [day] [month] [year] [list]

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

On 18-02-08 22:04, Rene Herman wrote:
> On 18-02-08 21:43, H. Peter Anvin wrote:
> 
>> Rene Herman wrote:
>>>
>>> Now with respect to the original pre port 80 "jmp $+2" I/O delay 
>>> (which the Pentium obsoleted) I suppose it'll probably be okay even 
>>> without fixing that specifically but do note such -- it's a vital 
>>> part of the problem.
>>>
>>
>> Sorry, that paragraph didn't parse for me.
> 
> I mean that before the linux kernel used a port 0x80 write as an I/O 
> delay it used a short jump (two in a row actually...) as such and this 
> was at the time that it actually ran on the old legacy stuff that is of 
> most concern here.
> 
> No, if I'm not mistaken, those two jumps are actually what the udelay() 

_Now_, if I'm ...

> is going to do anyway as part of delay_loop() at that early stage so 
> that even before loops_per_jiffy calibration, I believe we should still 
> be okay.
> 
> Yes, it's a bit of a "well, hrrm" thing, but, well... loops_per_jiffy 
> can be initialised a bit more conservatively then today as well (and as 
> discussed earlier, possibly per CPU family) but I believe it's actually 
> sort of fine not too worry much about it...

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