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: <7d5500be-7bf6-4b6e-063d-6f5a8d031115@suse.com>
Date:   Thu, 15 Dec 2016 18:06:29 +0100
From:   Juergen Gross <jgross@...e.com>
To:     Borislav Petkov <bp@...e.de>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        xen-devel <xen-devel@...ts.xenproject.org>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>
Subject: Re: Can't boot as Xen dom0 due to commit fe055896

On 15/12/16 17:46, Borislav Petkov wrote:
> On Thu, Dec 15, 2016 at 05:12:04PM +0100, Juergen Gross wrote:
>> with today's kernel the system isn't coming up when booted as Xen dom0:
> 
> Remind me again pls, is dom0 even supposed to load microcode? Isn't the
> hypervisor supposed to apply microcode?
> 
>> Looking into the state of cpu 1 I find the following backtrace (created
>> manually by looking up addresses from a stack dump retrieved from the
>> hypervisor):
>>
>> find_cpio_data()
>> find_microcode_in_initrd()
>> __load_ucode_intel()
>> load_ucode_intel_ap()
>> cpu_init()
>> cpu_bringup()
>> cpu_bringup_and_idle()
>>
>> It seems as if load_ucode_intel_ap() is looping. You introduced a
>> possibly endless loop in it with commit fe055896.
> 
> Are you sure you mean:
> 
>   fe055896c040 ("x86/microcode: Merge the early microcode loader")
> 
> because that commit is a year old.

OMG. Sorry, somehow I managed to read the date of that patch wrong.

> So from looking at the *current* code:
> 
> 	if (apply_microcode_early(&uci, true)) {
> 
> fails probably because MSR_IA32_UCODE_REV doesn't get read properly due
> to virtualized MSRs, bla, yadda yadda...

I'll check.

BTW: Adding a retry count doesn't help. Just tried.

> But before we debug this further, I'd like to make sure I'm debugging
> the proper thing and not some situation again where xen wasn't even
> supposed to run the microcode loader but it does it anyway...

I guess this might be the case.


Juergen