linux-kernel - Re: PCI, ACPI, IRQ, IOAPIC: reroute PCI interrupt to legacy boot interrupt equivalent

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, 12 Jan 2009 15:36:29 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Bjorn Helgaas <bjorn.helgaas@...com>
Cc:	Stefan Assmann <sassmann@...e.de>, Len Brown <lenb@...nel.org>,
	Ingo Molnar <mingo@...e.hu>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Olaf Dabrunz <od@...e.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	Steven Rostedt <rostedt@...dmis.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-acpi@...r.kernel.org, Sven Dietrich <sdietrich@...ell.com>,
	"Maciej W. Rozycki" <macro@...ux-mips.org>,
	Jon Masters <jcm@...hat.com>
Subject: Re: PCI, ACPI, IRQ, IOAPIC: reroute PCI interrupt to legacy boot interrupt equivalent

I don't get it. Why are we trying to do such a stupid thing?

This hardware behavior is not specific to boot interrupts or Intel.
This is the classic x86 ioapic behaviour of redirecting a ioapic irq
into a legacy irq when the ioapic entry is disabled.

If you really want not to have problems ensure all irqs 0-15
are disabled, and not needed.  Otherwise you are taking the chance
on something like this happening.

Disabling irqs generically appears to be a crap shoot, and not on a
path hardware vendors look at or care about heavily.  Disabling an irq
in hardware on every interrupt, increasing the cost of the interrupt
and walking down these neglected hardware paths seems stupid.  Especially
when the interrupt line might be shared and we can be disabling several
devices at once.

Is this case really so interesting and compelling that we want to fight
through and figure what we need to do to make this work reliably on every
x86 chipset?

Eric
--
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/