linux-kernel - Re: Linux 5.13+ as Xen dom0 crashes on Ryzen CPU (ucode loading related?)

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: <YUBeUZdduCAbOQJN@linux.ibm.com>
Date:   Tue, 14 Sep 2021 11:33:21 +0300
From:   Mike Rapoport <rppt@...ux.ibm.com>
To:     Juergen Gross <jgross@...e.com>
Cc:     Marek Marczykowski-Górecki 
        <marmarek@...isiblethingslab.com>, Ingo Molnar <mingo@...hat.com>,
        Borislav Petkov <bp@...e.de>,
        Thomas Gleixner <tglx@...utronix.de>, x86@...nel.org,
        linux-kernel@...r.kernel.org,
        xen-devel <xen-devel@...ts.xenproject.org>
Subject: Re: Linux 5.13+ as Xen dom0 crashes on Ryzen CPU (ucode loading
 related?)

On Tue, Sep 14, 2021 at 09:14:38AM +0200, Juergen Gross wrote:
> On 13.09.21 14:50, Marek Marczykowski-Górecki wrote:
> > Hi,
> > 
> > Since 5.13, the Xen (PV) dom0 crashes on boot, before even printing the
> > kernel version.
> > Test environment:
> >   - Xen 4.14.2
> >   - AMD Ryzen 5 4500U (reported also on AMD Ryzen 7 4750U)
> >   - Linux 5.13.13, confirmed also on 5.14
> > 
> > The crash happens only if the initramfs has earlycpio with microcode.
> > I don't have a serial console, but I've got a photo with crash message
> > (from Xen, Linux doesn't managed to print anything):
> > https://user-images.githubusercontent.com/726704/133084966-5038f37e-001b-4688-9f90-83d09be3dc2d.jpg
> > 
> > Transcription of some of it:
> > 
> >      mapping kernel into physical memory
> >      about to get started
> >      (XEN) Pagetable walk from ffffffff82810888:
> >      (XEN)  L4[0x1ff] = 0000000332815067 0000000000002815
> >      (XEN)  L3[0x1fe] = 0000000332816067 0000000000002816
> >      (XEN)  L2[0x014] = 0000000334018067 0000000000004018
> >      (XEN)  L1[0x010] = 0000000332810067 0000000000002810
> >      (XEN) domain_crash_sync called from entry.S: fault at ffff82d04033e790 x86_64/entry.S#domain_crash_page_fault
> >      (XEN) Domain 0 (vcpu#0) crashed on cpu#0:
> >      (XEN) ----[ Xen-4.14.2  x86_64  debug=n  Not tainted ]----
> >      (XEN) CPU:    0
> >      (XEN) RIP:    e033:[<0000000000000000>]
> 
> The domain's run state seems to be completely clobbered.
> 
> Did you try to boot the kernel with "earlyprintk=xen" to get some idea
> how far it progressed?
> 
> I could imagine that doing the early reservations after the call of
> e820__memory_setup() is problematic, as Xen PV guests have a hook in
> this function performing some rather extended actions.

Right, among them it may relocate initrd:

https://elixir.bootlin.com/linux/latest/source/arch/x86/xen/setup.c#L872
 
and this may cause the reported crash.

> I'm not sure the call of early_reserve_memory() can be moved just before
> the e820__memory_setup() call. If this is possibel it should be done
> IMO, if not then the reservations which have been at the start of
> setup_arch() might need to go there again.

early_reserve_memory() can be moved to the beginning of setup_arch().

Anther possibility is to move initrd relocation out of xen_setup_memory()
and maybe even integrate it somehow in reserve_initrd().

-- 
Sincerely yours,
Mike.