~alpine/users

1

Re: Syslinux & Xen & microcode updates

Chris Brannon <cmb@prgmr.com>
Details
Message ID
<87r236t8cl.fsf@cmbmachine.messageid.invalid>
DKIM signature
missing
Download raw message
Christian Kujau <lists@nerdbynature.de> writes:

> Hello,
>
> I'm having trouble applying CPU microcode updates to this system running a 
> Xen dom0. Lots of internet resources appear to recommend to add 
> "ucode=early_ucode.cpio" to the EFI xen.cfg configuration file and it will 
> magically work, but even though EFI support is now available[0], this 
> system of mine is using Syslinux to boot:

Hi,
ucode=scan should work reliably.  But you'll need to change your command
line in syslinux.  You have:

>  LABEL xen-vanilla
>    MENU LABEL Xen + Linux vanilla
>    COM32 mboot.c32
>    APPEND xen.gz dom0_mem=512M,max:1024M ucode=scan --- vmlinuz-vanilla \
>      root=[...] modules=ext4 --- initramfs-vanilla

Instead, would you try:

    APPEND xen.gz dom0_mem=512M,max:1024M ucode=scan --- vmlinuz-vanilla \
      root=[...] modules=ext4 --- intel-ucode.img --- initramfs-vanilla

That will pass in both the microcode file and initramfs.

> Also, combining microcode+intrd on the Syslinux command line[3] didn't 
> work either:
>
>   [...]
>   APPEND xen.gz dom0_mem=512M,max:1024M ucode=scan --- vmlinuz-vanilla 
>       root=[...] early_ucode.cpio,initramfs-vanilla
>
> Booting this failed with:
>
>    Loading xen.gz.... ok
>    Loading vmlinuz-vanilla... ok
>    Loading early_ucode.cpio,initramfs-vanilla... failed!
>    No files found!

Yes, I'm pretty sure this was a syntax issue with syslinux.  But the
syntax I gave earlier should work.

FWIW there is a subtle difference in how microcode is handled on EFI and
non-EFI Xen.  For non-EFI Xen, the ucode= parameter is either a
zero-based index into the list of loaded modules, the value "scan" to
scan the list, or -1 to use the last module in the list.  See here:
https://xenbits.xenproject.org/docs/4.12-testing/misc/xen-command-line.html#ucode-x86

On the other hand, EFI Xen takes ucode=<filename> as a parameter in a
configuration file.  I don't have any experience with EFI Xen.

Does that help?

-- Chris

Re: Syslinux & Xen & microcode updates

Christian Kujau <lists@nerdbynature.de>
Details
Message ID
<alpine.DEB.2.21.99999.352.1910211025010.13135@trent.utfs.org>
In-Reply-To
<87r236t8cl.fsf@cmbmachine.messageid.invalid> (view parent)
DKIM signature
missing
Download raw message
On Mon, 21 Oct 2019, Chris Brannon wrote:
>     APPEND xen.gz dom0_mem=512M,max:1024M ucode=scan --- vmlinuz-vanilla \
>       root=[...] modules=ext4 --- intel-ucode.img --- initramfs-vanilla

That didn't work, as vmlinuz-vanilla now tried to find its initrd in 
intel-ucode.img, but that did not contain a rootfs and it panicked with 
this infamous "Kernel panic - not syncing: VFS: Unable to mount root 
fs..." message.

> FWIW there is a subtle difference in how microcode is handled on EFI and
> non-EFI Xen.  For non-EFI Xen, the ucode= parameter is either a
> zero-based index into the list of loaded modules, the value "scan" to
> scan the list, or -1 to use the last module in the list.  See here:
> https://xenbits.xenproject.org/docs/4.12-testing/misc/xen-command-line.html#ucode-x86

Ah, I didn't know about that value being different depending on whether 
EFI or non-EFI systems are used, thanks!

So, while "intel-ucode.img --- initramfs-vanilla" did not work (tested 
just now), I fiddled around some more (boy, was it late last night) and 
although I dismissed it first, the concatenation of the microcode and the 
initrd[0] did indeed work, although I am missing the usual "microcode" 
messages in dmesg, something like:

  microcode: sig=0x806e9, pf=0x80, revision=0xb4
  microcode: Microcode Update Driver: v2.2.

So, with this absent, the following message is now gone:

  MDS: Vulnerable: Clear CPU buffers attempted, no microcode

...and this spectre-meltdown-checker.sh check script (that bugged me to 
attempt a microcode update) is now much happier :-D

So, to recap, the following worked, although it bugs me that dmesg is 
quiet about this:

==============================================================
# cd /boot
# apk info -W intel-ucode.img 
/boot/intel-ucode.img is owned by intel-ucode-20190918-r0


# cat intel-ucode.img initramfs-vanilla > intel-ucode_initramfs-vanilla.img 

# update-extlinux -v
Updating extlinux configuration.
Found Xen hypervisor: /boot/xen.gz, kernel: /boot/vmlinuz-vanilla
Found initramfs: /boot/initramfs-vanilla
Found kernel: /boot/vmlinuz-vanilla
Found initramfs: /boot/initramfs-vanilla
Found microcode for Intel CPUs: /boot/intel-ucode.img
2 entries found.
Installing libutil.c32 libcom32.c32 mboot.c32 menu.c32 vesamenu.c32 to /boot.
/boot is device /dev/sda1



# sed -i 's/ initramfs-vanilla$/ intel-ucode_initramfs-vanilla.img/' extlinux.conf

# cat extlinux.conf
DEFAULT menu.c32
PROMPT 0
MENU TITLE Alpine/Linux Boot Menu
MENU AUTOBOOT Alpine will be booted automatically in # seconds.
TIMEOUT 50
LABEL xen-vanilla
  MENU LABEL Xen + Linux vanilla
  COM32 mboot.c32
  APPEND xen.gz dom0_mem=512M,max:1024M ucode=scan --- vmlinuz-vanilla root=[...] modules=ext4 rootfstype=ext4 --- intel-ucode_initramfs-vanilla.img
==============================================================


Thanks for responding,
Christian.

[0] https://bbs.archlinux.org/viewtopic.php?pid=1814467#p1814467
    "Advice: Where to capture custom Microcode system requirements/setup?"
-- 
BOFH excuse #412:

Radial Telemetry Infiltration
Reply to thread Export thread (mbox)