linux-kernel - Re: Can't boot as Xen dom0 due to commit fe055896

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: <539c1b43-009d-9a59-0c80-7b1e552ab0ed@oracle.com>
Date:   Thu, 15 Dec 2016 22:56:25 -0500
From:   Boris Ostrovsky <boris.ostrovsky@...cle.com>
To:     Borislav Petkov <bp@...e.de>
Cc:     Juergen Gross <jgross@...e.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        xen-devel <xen-devel@...ts.xenproject.org>
Subject: Re: Can't boot as Xen dom0 due to commit fe055896

On 12/15/2016 06:04 PM, Borislav Petkov wrote:
> On Thu, Dec 15, 2016 at 05:56:44PM -0500, Boris Ostrovsky wrote:
>> With CONFIG_PARAVIRT (which I suspect you don't have on) cpuid() is a
>> call via a pointer, you can see it, for example, if you disassemble
>> load_ucode_amd_bsp(). And we don't have paging on yet when we call
>> load_ucode_amd_bsp (at least in 32-bit mode).
>
> That's a good catch, you can send me that one as a proper patch with a
> commit message and so on...

OK, I'll send something tomorrow.

>
>> Since this happens during AP bringup PV cpuid is available and can be
>> checked to see whether we are a guest.
>
> What exactly do I need to check there? CPUID(4), leaf which, reg which?
> How do I identify a xen hypervisor properly?

You can use xen_cpuid_base(), for example. It will prevent microcode 
loading for all types of Xen guests (PV, HVM and, in the near future, 
PVH). Which I think is fine. This will require adding a #define for 
xen_cpu_base() for !CONFIG_XEN.

Alternatively, if we think that no guest should ever load microcode, we 
could check for 'x86_hyper != 0'. This will be cleaner but I can't speak 
for KVM/VMware/Hyper-V.

Neither of these solutions will work for load_ucode_bsp() because 
xen_cpuid_base() calls cpuid() (and so we are back to the above bug) and 
x86_hyper is not set yet. This is OK for Xen as PV guests never call 
load_ucode_bsp and HVM/PVH guests should be able to handle MSR accesses.

>
>> But I think it may be worthwhile trying to understand why we are
>> dying, it hasn't happened until now.
>
> What for? We don't want to run the microcode loader on xen at all.

True. But I don't think it's clear that the problem we are seeing is 
Xen-specific.

-boris