linux-kernel - Re: [PATCH RFC 1/2] x86/apic: Do not make an exception for PIC_CASCADE_IR when marking legacy irqs in irq

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, 17 Mar 2021 22:40:45 +0100
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Vitaly Kuznetsov <vkuznets@...hat.com>, x86@...nel.org
Cc:     Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC 1/2] x86/apic: Do not make an exception for PIC_CASCADE_IR when marking legacy irqs in irq_matrix

On Wed, Mar 17 2021 at 22:18, Thomas Gleixner wrote:

> On Wed, Mar 17 2021 at 21:14, Thomas Gleixner wrote:
>> On Fri, Feb 19 2021 at 12:31, Vitaly Kuznetsov wrote:
>> Even without looking at the machine I can tell you what's going on. MP
>> config or ACPI has a pin assigned to IRQ 2 which I've not seen before.
>> The code there is ignoring IRQ 2 because that's how the original code
>> worked as well as it is reserved for the PIC_CASCADE_IRQ which should
>> never fire and we actually want to catch an spurious interrupt on it.
>>
>> So depending on the overall configuration of that system and the
>> resulting delivery modes this might be ok, but I'm really nervous about
>> doing this wholesale as it might break old machines.
>>
>> Out of paranoia I'd rather ignore that IO/APIC pin completely if it
>> claims to be IRQ2. I assume there is no device connected to it at all,
>> right?
>
> Seems at some point we lost the 'ignore cascade IRQ' logic in
> IO/APIC. There is still a comment to that effect.
>
> Let me do some archaeology.

af174783b925 ("x86: I/O APIC: Never configure IRQ2")

has a very nice explanation why.

Back then the logic was quite different. All legacy PIC interrupts
(0-15) were bound to the legacy vectors at boot and never moved away.

There was a check in the back then setup routing which prevented the
IOAPIC routing of IRQ2 which got lost at some point. Haven't figured out
yet where this might be. Still digging in those ancient horrors.

Thanks,

        tglx