linux-kernel - Re: [tip: x86/urgent] x86/acpi: Ignore invalid x2APIC entries

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: <1e565bb08ebdd03897580a5905d1d2de01e15add.camel@intel.com>
Date:   Thu, 23 Nov 2023 12:50:47 +0000
From:   "Zhang, Rui" <rui.zhang@...el.com>
To:     "jsperbeck@...gle.com" <jsperbeck@...gle.com>,
        "tip-bot2@...utronix.de" <tip-bot2@...utronix.de>
CC:     "tglx@...utronix.de" <tglx@...utronix.de>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-tip-commits@...r.kernel.org" 
        <linux-tip-commits@...r.kernel.org>,
        "x86@...nel.org" <x86@...nel.org>
Subject: Re: [tip: x86/urgent] x86/acpi: Ignore invalid x2APIC entries

Hi, John,

Thanks for catching this issue.

On Wed, 2023-11-22 at 22:19 +0000, John Sperbeck wrote:
> I have a platform with both LOCAL_APIC and LOCAL_X2APIC entries for
> each CPU.  However, the ids for the LOCAL_APIC entries are all
> invalid ids of 255, so they have always been skipped in
> acpi_parse_lapic()
> by this code from f3bf1dbe64b6 ("x86/acpi: Prevent LAPIC id 0xff from
> being
> accounted"):
> 
>     /* Ignore invalid ID */
>     if (processor->id == 0xff)
>             return 0;
> 
> With the change in this thread, the return value of 0 means that the
> 'count' variable in acpi_parse_entries_array() is incremented.  The
> positive return value means that 'has_lapic_cpus' is set, even though
> no entries were actually matched.

So in acpi_parse_madt_lapic_entries, without this patch,
madt_proc[0].count is a positive value on this platform, right?

This sounds like a potential issue because the following checks to fall
back to MPS mode can also break. (If all LOCAL_APIC entries have
apic_id 0xff and all LOCAL_X2APIC entries have apic_id 0xffffffff)

>   Then, when the MADT is iterated
> with acpi_parse_x2apic(), the x2apic entries with ids less than 255
> are skipped and most of my CPUs aren't recognized.
> 
> I think the original version of this change was okay for this case in
> https://lore.kernel.org/lkml/87pm4bp54z.ffs@tglx/T/

Yeah.

But if we want to fix the potential issue above, we need to do
something more.

Say we can still use acpi_table_parse_entries_array() and convert
acpi_parse_lapic()/acpi_parse_x2apic() to
acpi_subtable_proc.handler_arg and save the real valid entries via the
parameter.

or can we just use num_processors & disabled_cpus to check if there is
any CPU probed when parsing LOCAL_APIC/LOCAL_X2APIC entires?

thanks,
rui
> 
> P.S. I could be convinced that the MADT for my platform is somewhat
> ill-formed and that I'm relying on pre-existing behavior.  I'm not
> well-versed enough in the topic to know for sure.