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

Message-ID: <1edbdac8-dfef-5529-8246-bbcd499e6d5a@oracle.com>
Date:   Fri, 18 Nov 2016 09:22:29 -0500
From:   Boris Ostrovsky <boris.ostrovsky@...cle.com>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     "M. Vefa Bicakci" <m.v.b@...box.com>,
        "Charles (Chas) Williams" <ciwillia@...cade.com>,
        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>,
        xen-devel <xen-devel@...ts.xen.org>
Subject: Re: [PATCH] x86/cpuid: Deal with broken firmware once more

On 11/18/2016 06:16 AM, Thomas Gleixner wrote:
> On Mon, 14 Nov 2016, Boris Ostrovsky wrote:
>> On 11/13/2016 06:42 PM, M. Vefa Bicakci wrote:
>>
>>> I found out that my domU kernels invoke the 'apic_disable' function
>>> because CONFIG_X86_MPPARSE was not enabled in my kernel configuration,
>>> which would cause the 'smp_found_config' bit to be unset at boot-up.
>> smp_found_config is not the problem, it is usually zero for Xen PV guests.
>>
>> What is the problem is that because of your particular config selection
>> acpi_mps_check() fails (with the error message that you mention below) and
>> that leads to X86_FEATURE_APIC being cleared. And then we indeed switch to
>> APIC noop and things go south after that.
> Indeed. And what really puzzles me is that Xen manages to bring up a
> secondary CPU despite APIC being disabled. 

PV guests bring secondary VCPUs up using hypercalls (see xen_cpu_up()).

> There are quite some assumptions about no APIC == no SMP in all of x86. Can
> we please make Xen behave like anything else?
>

I will try to see if we can improve APIC emulation for these guests.
Unfortunately it will have to be done on kernel side since we still need
to support older Xen versions.

But as I said earlier, the right answer to this is PVH.

-boris