linux-kernel - Re: [PATCH] x86/i8259: Work around buggy legacy PIC

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, 17 May 2021 21:25:51 +0200
From:   Maximilian Luz <luzmaximilian@...il.com>
To:     Thomas Gleixner <tglx@...utronix.de>,
        "H. Peter Anvin" <hpa@...or.com>, Sachi King <nakato@...ato.io>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        David Laight <David.Laight@...lab.com>
Cc:     "x86@...nel.org" <x86@...nel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>
Subject: Re: [PATCH] x86/i8259: Work around buggy legacy PIC

On 5/17/21 8:40 PM, Thomas Gleixner wrote:
> Max,
> 
> On Sat, May 15 2021 at 00:47, Maximilian Luz wrote:
>> I believe the theory was that, while the PIC is advertised in ACPI, it
>> might be expected to not be used and only present for some legacy reason
>> (therefore untested and buggy). Which I believe led to the question
>> whether we shouldn't prefer IOAPIC on systems like that in general. So I
>> guess it comes down to how you define "systems like that". By Tomas'
>> comment, I guess it should be possible to implement this as "systems
>> that should prefer IOAPIC over legacy PIC" quirk.
>>
>> I guess all modern machines should have an IOAPIC, so it might also be
>> preferable to expand that definition, maybe over time and with enough
>> testing.
> 
> I just double checked and we actually can boot just fine without the
> PIC even when it is advertised, but disfunctional.
> 
> Can you please add "apic=verbose" to the kernel command line and provide
> full dmesg output for a kernel w/o your patch and one with your patch
> applied?

I don't actually own an affected device, but I'm sure Sachi can provide
you with that.

As far as we can tell, due to the NULL PIC being chosen nr_legacy_irqs()
returns 0. That in turn causes mp_check_pin_attr() to return false
because is_level and active_low don't seem to match the expected values.
That check is essentially ignored if nr_legacy_irqs() returns a high
enough value. I guess that might also be a firmware bug here? Not sure
where the expected values come from.

Due to this, mp_map_pin_to_irq() fails with -EBUSY which causes
acpi_register_gsi() to fail. That fails in acpi_dev_get_irqresource(),
which causes the IRQ resource to be marked as disabled.

Down the line, this then causes platform_get_irq() to return -EINVAL,
because the IRQ we're trying to get has the IORESOURCE_DISABLED bit set.

Sachi can probably walk you through this a bit better as she's the one
who tracked this down. See also [1, 2] and following comments.

Regards,
Max

[1]: https://github.com/linux-surface/linux-surface/issues/425#issuecomment-835309201
[2]: https://github.com/linux-surface/linux-surface/issues/425#issuecomment-835261784