linux-kernel - Re: [PATCH] x86/cpuid: Deal with broken firmware once more

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: <eecbbfdf-38c1-acdd-402b-3be48cf5fdb7@brocade.com>
Date:   Thu, 10 Nov 2016 10:05:01 -0500
From:   "Charles (Chas) Williams" <ciwillia@...cade.com>
To:     Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        "M. Vefa Bicakci" <m.v.b@...box.com>
CC:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
        "x86@...nel.org" <x86@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Borislav Petkov <bp@...en8.de>,
        David Vrabel <david.vrabel@...rix.com>,
        Juergen Gross <jgross@...e.com>
Subject: Re: [PATCH] x86/cpuid: Deal with broken firmware once more



On 11/10/2016 09:02 AM, Boris Ostrovsky wrote:
> On 11/10/2016 06:13 AM, Thomas Gleixner wrote:
>> On Thu, 10 Nov 2016, M. Vefa Bicakci wrote:
>>
>>> I have found that your patch unfortunately does not improve the situation
>>> for me. Here is an excerpt obtained from the dmesg of a kernel compiled
>>> with this patch *as well as* Sebastian's patch:
>>> [    0.002561] CPU: Physical Processor ID: 0
>>> [    0.002566] CPU: Processor Core ID: 0
>>> [    0.002572] [Firmware Bug]: CPU0: APIC id mismatch. Firmware: ffff CPUID: 2
>> So apic->cpu_present_to_apicid() gives us a completely bogus APIC id which
>> translates to a bogus package id. And looking at the XEN code:
>>
>>    xen_pv_apic.cpu_present_to_apicid = xen_cpu_present_to_apicid,
>>
>> and xen_cpu_present_to_apicid does:
>>
>> static int xen_cpu_present_to_apicid(int cpu)
>> {
>>         if (cpu_present(cpu))
>>                 return xen_get_apic_id(xen_apic_read(APIC_ID));
>>         else
>>                 return BAD_APICID;
>> }
>>
>> So independent of which present CPU we query we get just some random
>> information, in the above case we get BAD_APICID from xen_apic_read() not
>> from the else path as this CPU _IS_ present.
>>
>> What's so wrong with storing the fricking firmware supplied APICid as
>> everybody else does and report it back when queried?
>
> By firmware you mean ACPI? It is most likely not available to PV guests.
> How about returning cpu_data(cpu).initial_apicid?
>
> And what was the original problem?

The original issue I found was that VMware was returning a different set
of APIC id's in the ACPI tables than what it advertised on the CPU's.

http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1266716.html

>>
>> This damned attitude of we just hack the code into submission and let
>> everybody else deal with the outcoming is utterly annoying.
>>
>> Thanks,
>>
>> 	tglx
>
>