[SOLVED] Load intel-ucode.img via systemd-boot when booting Windows?

scot · 2024-12-31 18:06:27

I use systemd-boot to boot arch linux and occasionally Windows 11.
I load the intel-ucode.img firmware when I boot arch via the lines

linux  /EFI/arch/boot/x86_64/vmlinuz-linux  
initrd /EFI/arch/boot/x86_64/intel-ucode.img

in my arch.conf file within .../loader/entries/
is there something I can put in my windows.conf file to load the microcode?
is it good / bad / indifferent practise to do so?

If this is not a topic for even a NEWBIE_CORNER post of arch linux (because strictly speaking, i might be using arch to install and manage my boot loader, but neither the boot loader nor the OS it is booting in this particular case is arch linux), I apologize. In that case, perhaps it's still ok for a newbie to ask about where I should ask....

Thank you

Last edited by scot (2025-01-02 13:09:07)

cryptearth · 2024-12-31 19:47:05

short answer: no, there's no option to do so as anything a linux bootloader can do is to chain the microsoft bootloader - which is what would have to do loading the firmware image - which it can't as it's sole job is to load BCD and get the location of winload from it and chain it which then in the end actually does start the boot process by loading and starting the windows kernel

topcat01 · 2024-12-31 20:57:52

I don't believe Windows has the ability to load microcode on the fly anyway. It has to be flashed into the firmware.

scot · 2025-01-01 08:53:08

Thank you for replying so quickly: two short follow-on questions:

1. Do I learn from this that it safer/faster/more-secure - in short, better - to run Windows as a guest in a linux host, because that way I am immune to whatever ills are corrected by loading intel-ucode.img?

2. Your replies are certainly definitive, and I have every reason to believe that they are also correct . Should I therefore mark this thread as SOLVED (even though the implicit underlying question -- how to load microcode with systemd-boot when I use it to boot windows -- remains unsolved (because it's unsolvable)?

Thx again

progandy · 2025-01-01 10:34:44

If you use windows, then the microcode updates will be supplied by microsoft through windows update. As far as I know it will load microcode from a file called “C:\Windows\System32\mcupdate_GenuineIntel.dll, but this has to be signed by MS.

Last edited by progandy (2025-01-01 10:39:48)

scot · 2025-01-01 11:52:09

I see, thank you.
Just out of curiosity, and FMI: does
1. A VM load the microcode into a virtual processor (or perhaps even into a real one if there is hardware support for virtualization)? or
2. The VM not need to load microcode, if the underlying host did when it booted? or
3. The hypervisor has the responsibility to present virtual CPUs that do not need microcode? or
4. It's complicated, but the bottom line is that I don't have to "do something" and don't have to worry that my VMs are insecure (or bad in some other way) because of CPU microcode issues?

(If it matters, I use virtualbox on an up-to-date arch linux running on a Dell 9500 with up-to-date BIOS (but I will probably switch to QEMU when I grow up;)).

Last edited by scot (2025-01-01 11:55:22)

cryptearth · 2025-01-01 15:46:08

scot wrote:

how to load microcode with systemd-boot when I use it to boot windows

you don'T - because: neither systemd nor grub nor refind nor any other linux bootloader does in fact load or boot windows - all they do is to CHAIN the windows bootloader
also: it's not the bootloader which applies the microcode update but the early stages of the kernel

all a bootloader - or to be more precise about modern ones: boot manager - does:

1) after it got loaded by the bios/uefi and started the first thing a bootloader requires some sort of configuration
this can be done in several ways worth its own topic - but boils down
a) perform some special action like setup network, reboot into bios, chain another bootloader
b) load a kernel and an initial ramdisk image and start it with a set of commands

2a) when chaining another bootloader the simplest option is just terminate and let the bios/uefi handle it by its own boot order - another way is also to point to the next bootloader - I guess also loading one and handle it as an image could be an option
this is what happens when you chain windows from a linux bootloader

2b) when booting linux: loading a kernel and an ramdisk image into memory and start the kernel
in this case its up to the kernel to detect if an microcode image is present and splice it - at this point the bootloader is already history

3) when windows gets chained it does the same: it loads a file called BCD which contains a list of boot options
a) here the same as above applies: perform a reboot into firmware setup - or, yes, even chain yet another bootloader - so one can use the windows boot manager to chain a linux one like systemd or grub
b) look where to find winload - which then in turn loads the windows kernel and starts it

so - even IF you wanted to use a linux bootloader to inject a microcode patch image you would need to somehow inject this information into the windows bootloader and somehow convince it to inject it further down to winload - which then doesn't understand the linux-kernel specific file anyway and discards it - in the worst case in some boot error we seen with crowdstrike

so - even the way longer explanation how a modern computer with uefi boots - the answer remains NO! because it just doesn'T work this way

as for your other questions: I don't know and hence can'T answer them neither with yes, no or anything else - and even using virtual-box seems to be an option - but all experience I have with VB was as userland software on windows with linux as guest
on a linux host I always ever used KVM with qemu and libvirt and virt-manager
and although I do think that yes it does make a difference if a hypervisor already loads a microcode patch at boot it does affect anything at the layer below it could very well be that it works vastly different and that somehow for some reason a VM run different microcode than the host might be - as in the end it's just a bit of software that gets loaded each and every boot into kernel space and is some sort of magic black box noone really understands how it really works
virtual cpu cores are represented as regular applications threads on the host - but as they utilize hardware virtualization they stil are de-coupled from the host - so who knows what happen down at the silicon level

scot · 2025-01-01 17:10:10

> when booting Linux, it's up to the kernel to
>detect .... at this point the boot loader is
>already history.

In the opening post of this thread I quote 2 lines from the arch.conf file in my /boot/loader/entries.

linux  /EFI/arch/boot/x86_64/vmlinuz-linux  
initrd /EFI/arch/boot/x86_64/intel-ucode.img

I assume the initrd line loads the ramdisk. To square your explanation (about the kernel "detecting...." with my assumption that the microcode file location is in the boot loader conf file for a reason (since I didn't put it there:)), I learn that the boot loader loads kernel and the ramdisk and copies that microcode file into the right place in the ramdisk so that the kernel will detect it. Is that the dance?

It's sort of like the way when I was a kid that my mom would "detect" that there're some milk bottles outside the front door. She had to do the detecting, and by the time she did, the milkman was history. But his actions were essential in order for her to detect the milk. If the milkman wasn't configured correctly, my mom wouldn't detect anything, no matter how hard she looked.

Hence my confusion about systemd-boot needing to "do something" with ucode for windows.

(I guess the other possibility is that listing the microcode file in the initrd line does nothing and doesn't need to be there. But I don't recall adding it myself)

Scimmia · 2025-01-01 17:12:00

https://wiki.archlinux.org/title/Arch_boot_process

cryptearth · 2025-01-01 21:36:45

scot wrote:

the boot loader loads kernel

yes

scot wrote:

and the ramdisk and copies that microcode file into the right place in the ramdisk

no

the boot loader only loads the kernel into ram and jumps to its main()
any initrd line becomes just a parameter to the kernel

it's the early kernel itself which has to check the given parameters - like one or maybe multiple initrd= - load them and deal with what's inside them
if a given initrd is a cpu microcode patch the kernel detects that and does whatever it has to do with that
as for what that is or why a cpu microcode has to come before any regular initrd is a question for upstream kernel devs
point is: at the point when the early kernel stages check the parameters the boot process is already past the bootloader but in the kernel itself

again: if done correctly you can even use the windows boot manager and chain an efi-stub / uki from it - it maybe could even be possible to give parameters along - but that's outside of the scope of this forum

maybe this helps: try to see both anything related to any bootloader (systemd, grub, refind, ...), anything related to linux (that is after the bootloader jumped to the kernel) and anything windows as three separate things independent of eachother
you can chain one from the other - but you cannot influence them
in fact: with uefi and arch one doesn't even need a full blown boot manager but the arch kernel is compiled with EFI_STUB - so it is a valid efi binary all by itself and can either gets its parameters directly from the systems uefi boot entry - or be combined with a command line and initrd into an UKI

topcat01 · 2025-01-01 22:12:36

progandy wrote:

If you use windows, then the microcode updates will be supplied by microsoft through windows update. As far as I know it will load microcode from a file called “C:\Windows\System32\mcupdate_GenuineIntel.dll, but this has to be signed by MS.

I stand corrected! Thanks for the info. So, Windows can do it too. The dll mentioned seems to be the Win equivalent to intel-ucode.img, and hence already taken care of by Windows. So, no need to bother with that. Simply chainload Win.

Last edited by topcat01 (2025-01-01 22:15:14)

scot · 2025-01-02 13:08:03

This is crystal clear, and I thank you all for your patience and clarity.

In fact, I set things up so that I could boot the same Windows boot partition (that's the C:\ disk) either from systemd-boot OR as a virtualbox VM (in which that Windows boot partition is configured to be a virtualbox "raw disk."). But it took a bit of struggle to make a separate, DIFFERENT /boot2 partition that is the Windows system partition for the VM. I do this because the default of the real, host, /boot partition of course boots the host Linux, and I never want to be in the situation where I boot the VM and don't/forget to choose Windows -- thereby booting up my Linux as a guest inside itself as the host.
But now I see that's stupid. For example, I can just have the VM boot windows from the VM's EFI bootloader.

BTW: I certainly don't know why, but I always assumed that the reason basic reason that loading microcode has to happen first is twofold: first, that the microcode provides security patches for the CPU instruction set, so anything that runs before those patches are applied is a potential security risk; second, the microcode also patches other bugs in the instruction set, so anything that runs before those patches are applied is a potential bug victim or activator. Are these reasons/assumptions flawed?

Again, thx
I'll mark this thread SOLVED

Arch Linux

#1 2024-12-31 18:06:27

[SOLVED] Load intel-ucode.img via systemd-boot when booting Windows?

#2 2024-12-31 19:47:05

Re: [SOLVED] Load intel-ucode.img via systemd-boot when booting Windows?

#3 2024-12-31 20:57:52

Re: [SOLVED] Load intel-ucode.img via systemd-boot when booting Windows?

#4 2025-01-01 08:53:08

Re: [SOLVED] Load intel-ucode.img via systemd-boot when booting Windows?

#5 2025-01-01 10:34:44

Re: [SOLVED] Load intel-ucode.img via systemd-boot when booting Windows?

#6 2025-01-01 11:52:09

Re: [SOLVED] Load intel-ucode.img via systemd-boot when booting Windows?

#7 2025-01-01 15:46:08

Re: [SOLVED] Load intel-ucode.img via systemd-boot when booting Windows?

#8 2025-01-01 17:10:10

Re: [SOLVED] Load intel-ucode.img via systemd-boot when booting Windows?

#9 2025-01-01 17:12:00

Re: [SOLVED] Load intel-ucode.img via systemd-boot when booting Windows?

#10 2025-01-01 21:36:45

Re: [SOLVED] Load intel-ucode.img via systemd-boot when booting Windows?

#11 2025-01-01 22:12:36

Re: [SOLVED] Load intel-ucode.img via systemd-boot when booting Windows?

#12 2025-01-02 13:08:03

Re: [SOLVED] Load intel-ucode.img via systemd-boot when booting Windows?

Board footer