linux-kernel - 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:	Wed, 02 Jan 2008 01:25:15 +0100
From:	Rene Herman <rene.herman@...access.nl>
To:	"H. Peter Anvin" <hpa@...or.com>
CC:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	"David P. Reed" <dpreed@...d.com>, Ingo Molnar <mingo@...e.hu>,
	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@...be.net
Subject: Re: [PATCH] x86: provide a DMI based port 0x80 I/O delay override.

On 02-01-08 00:11, Rene Herman wrote:

> On 01-01-08 23:39, H. Peter Anvin wrote:
> 
>>>> Yes, we do.  It's exactly this side effect which makes this safer 
>>>> than either 0x80 or 0xED -- it's a port that *guaranteed* can't be 
>>>> reclaimed for other purposes without breaking MS-DOS compatibility.
>>>
>>> I see that with CR0.NE set (*) we indeed don't care about IGNNE#...
>>>
>>> However, I'm worried about this comment in arch/x86/kernel/i8259_32.c
>>>
>>> ===
>>> /*
>>>  * New motherboards sometimes make IRQ 13 be a PCI interrupt,
>>>  * so allow interrupt sharing.
>>>  */
>>> ===
>>>
>>> Is it really safe to just blindly negate IRQ13 on everything out 
>>> there, from regular PC through funky embedded thingies?
>>
>> It's not any IRQ 13, it's IRQ 13 from the FPU.
> 
> Well, on the PIIX it is and I guess on anything where it's _not_ fully 
> internal an 0xf0 write wouldn't have any effect on IRQ13...
> 
> When you earlier mentioned this it seemed 0xed switched on DMI would be 
> good enough, but well.
> 
> Alan, do you have an opinion on the port 0xf0 write? It should probably 
> still be combined with a replacement/deletion for new machines due to 
> the bus-locking "bad for real-time" thing you mentioned earlier but in 
> the short run it could be a fairly low-impact replacement on anything 
> except a 386+387
> 
> We should do a another timing measurement survey and it makes for 
> sligtly worse code if we indeed feel it's not safe enough to write 
> anything other than 0, but otherwise it's quite minimal.

Thinking about this, my main worry about 0xf0 as a 0x80 replacement would be 
systems that have elected to _not_ let port 0xf0 writes flow through to ISA 
changing the timing-characteristics. Given that it's a known port, someone 
may have elected to just keep it fully internal.

Upto now the datasheets I've read do put it on ISA...

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/