linux-kernel - Re: [PATCH] x86/acpi: keep x86_cpu_to_acpiid mapping valid on cpu hotplug

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] [day] [month] [year] [list]

Message-ID: <87shnqs61s.fsf@vitty.brq.redhat.com>
Date:   Tue, 07 Feb 2017 10:29:03 +0100
From:   Vitaly Kuznetsov <vkuznets@...hat.com>
To:     "Rafael J. Wysocki" <rafael@...nel.org>
Cc:     "the arch\/x86 maintainers" <x86@...nel.org>,
        ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "linux-ia64\@vger.kernel.org" <linux-ia64@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>, Andrew Jones <drjones@...hat.com>
Subject: Re: [PATCH] x86/acpi: keep x86_cpu_to_acpiid mapping valid on cpu hotplug

"Rafael J. Wysocki" <rafael@...nel.org> writes:

> On Mon, Feb 6, 2017 at 6:01 PM, Vitaly Kuznetsov <vkuznets@...hat.com> wrote:
>> We may or may not have all possible CPUs in MADT on boot but in any case
>> we're overwriting x86_cpu_to_acpiid mapping with U32_MAX when
>> acpi_register_lapic() is called again on the CPU hotplug path:
>> acpi_processor_hotadd_init() -> acpi_map_cpu() -> acpi_register_lapic().
>>
>> As we have the required acpi_id information in acpi_processor_hotadd_init()
>> propagate it to acpi_map_cpu() to always keep x86_cpu_to_acpiid mapping
>> valid.
>>
>> Reported-by: Andrew Jones <drjones@...hat.com>
>> Signed-off-by: Vitaly Kuznetsov <vkuznets@...hat.com>
>
> Is the bug report available and if so, do you have a pointer to it?
>

There was no 'real' bug, the issue was found by code inspection.
Potentially, the following scenario is currently broken:
- boot Xen HVM guest and do kdump on a secondary CPU
- with kdump kernel running try to hot-plug additional CPUs.
we'll end up with U32_MAX in x86_cpu_to_acpiid for hot-plugged CPUs so
we'll be assuming direct Linux<->Xen mapping which won't be the case and
all hypercalls referring to these CPUs will end up affecting some other
CPUs.

-- 
  Vitaly