linux-kernel - Re: [PATCH] x86/sfi: fix ioapic gsi range

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20100608201258.6c813085@linux.intel.com>
Date:	Tue, 8 Jun 2010 20:12:58 +0100
From:	Alan Cox <alan@...ux.intel.com>
To:	ebiederm@...ssion.com (Eric W. Biederman)
Cc:	jacob pan <jacob.jun.pan@...ux.intel.com>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...e.hu>,
	Feng Tang <feng.tang@...el.com>,
	Len Brown <len.brown@...el.com>
Subject: Re: [PATCH] x86/sfi: fix ioapic gsi range

> The issue is what acpi calls bus 0 irqs, and how drivers deal with
> them.  We wind up having well know irqs:  irqs 3 and 4 for serial
> ports, irq 7 for parallel ports. irqs 14, and 15 for ide.

Only we don't.

IRQ 3/4 for serial is not true on many boxes today that have serial -
in fact its been iffy since about the Thinkpad 600 !
IRQ 7 for parallel is rarely used (and in fact we usually poll)
IRQ 14/15 is wrong for ATA today as its AHCI based on modern boxes

And all the drivers you list are *cross platform* already.

> A bunch of these hardware devices we can get if someone connects up a
> lpc superio chip.

To an x86 PC class system using some very traditional (and no longer
valid) bits of behaviour.

> Even if sfi is never implemented on a platform where that kind of
> hardware exists, the current sfi code is setup to coexist
> simultaneously in the kernel with all of the infrastructure of other
> platforms where those kinds of devices exist.  Which means there can
> be drivers compiled into your kernel that make assumptions about
> special properties of the irqs 0-15.

That would be a driver bug. It would be bite other systems beyond the
legacy PC. In the PC world its been unsafe since PnP BIOS let alone
ACPI.

> With the current code you should get all of the remapping of the
> gsi's out of the legacy irq space without needing to lift a finger,
> and if someone later decides we need an irq override so we can have
> an isa irq present on a weird embedded system on a chip the code will
> be able to handle that easily.

There is only one reason to care about this - that is ISA bus devices
with software IRQ steering registers for the ISA lines. Now that might
just about be a real reason, but as former maintainer of both serial
and IDE (and part time fixer of parport) I'd say the other reasons are
bunkum.

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/