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]

Message-ID: <20071217143900.GA16604@elte.hu>
Date:	Mon, 17 Dec 2007 15:39:00 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	"David P. Reed" <dpreed@...d.com>
Cc:	Rene Herman <rene.herman@...il.com>,
	"H. Peter Anvin" <hpa@...or.com>, Paul Rolland <rol@...917.net>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	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.


* David P. Reed <dpreed@...d.com> wrote:

> Rene Herman wrote:
>> No, most definitely not. Having the user select udelay or none through the 
>> kernel config and then the kernel deciding "ah, you know what, I'll know 
>> better and use port access anyway" is _utterly_ broken behaviour. Software 
>> needs to listen to its master.
>
> When acting as an ordinary user, the .config is beyond my control 
> (except on Gentoo).  It is in control of the distro (Fedora, Ubuntu, 
> ... but perhaps not Gentoo).  I think the distro guys want a default 
> behavior that is set in .config, with quirk overrides being done when 
> needed.  And of course the user in his/her boot params gets the final 
> say.

yeah, that's exactly the thinking. Distros basically set general policy, 
but a quirk is (almost) always specific and correct enough to override 
that. We could perhaps refine this by directing the quirk to only be 
applied if the current type is 0x80 - because in that case we know that 
it's definitely not going to work. I.e. something like the small patch 
below?

	Ingo

---
 arch/x86/kernel/io_delay.c |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

Index: linux-x86.q/arch/x86/kernel/io_delay.c
===================================================================
--- linux-x86.q.orig/arch/x86/kernel/io_delay.c
+++ linux-x86.q/arch/x86/kernel/io_delay.c
@@ -47,8 +47,11 @@ EXPORT_SYMBOL(native_io_delay);
 
 static int __init dmi_io_delay_0xed_port(const struct dmi_system_id *id)
 {
-	printk(KERN_NOTICE "%s: using 0xed I/O delay port\n", id->ident);
-	io_delay_type = CONFIG_IO_DELAY_TYPE_0XED;
+	if (io_delay_type == CONFIG_IO_DELAY_TYPE_0X80) {
+		printk(KERN_NOTICE "%s: using 0xed I/O delay port\n",
+			id->ident);
+		io_delay_type = CONFIG_IO_DELAY_TYPE_0XED;
+	}
 
 	return 0;
 }
--
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/