OpenBSD: AMD processor microcode support added to -current(undeadly.org)
undeadly.org
OpenBSD: AMD processor microcode support added to -current
https://undeadly.org/cgi?action=article;sid=20230723185853
22 comments
If boot firmware implemented it, I wouldn't count on it being updated very often.
Every OS these days has a pretty good update process that patches things frequently. Doing it there means most users actually have a chance of seeing the patches.
Every OS these days has a pretty good update process that patches things frequently. Doing it there means most users actually have a chance of seeing the patches.
AGESA is updated every few months and a number of motherboard vendors track those changes with BIOS updates. The updates can often contain pretty substantial changes, like resizable BAR support.
Further: I'm typing this on a Macbook Pro which is running right now only because I was able to pull the bootrom (which is UEFI), add a NVME driver from a newer Macbook Pro, package it back up, and flash it back to the older Macbook Pro.
This let me use an NVME drive in a machine released before they added NVME support to that system's bootrom. The only side effect was that the OS didn't fully support NVME standby modes so power consumption was slightly higher, but even that was fixed in a later OS update which was released after NVME drives were in several models.
Further: I'm typing this on a Macbook Pro which is running right now only because I was able to pull the bootrom (which is UEFI), add a NVME driver from a newer Macbook Pro, package it back up, and flash it back to the older Macbook Pro.
This let me use an NVME drive in a machine released before they added NVME support to that system's bootrom. The only side effect was that the OS didn't fully support NVME standby modes so power consumption was slightly higher, but even that was fixed in a later OS update which was released after NVME drives were in several models.
> AGESA is updated every few months and a number of motherboard vendors track those changes with BIOS updates.
And very few people update their BIOS with any frequency. But most people update their OS.
And very few people update their BIOS with any frequency. But most people update their OS.
> If boot firmware implemented it, I wouldn't count on it being updated very often. Every OS these days has a pretty good update process that patches things frequently.
Not only that, but updating firmware is always riskier than updating the OS. If an OS update is broken, you can easily use the firmware to recover (booting from the OS install media and working from there); recovering from a failed firmware update can be much harder and/or obscure.
Not only that, but updating firmware is always riskier than updating the OS. If an OS update is broken, you can easily use the firmware to recover (booting from the OS install media and working from there); recovering from a failed firmware update can be much harder and/or obscure.
In some cases nearly impossible for the owner of the hardware.
Supermicro BIOS updates advise that in case of failed updates, it may be necessary to send the board back to be reflashed, presumably via some sort of direct hardware connection.
Supermicro BIOS updates advise that in case of failed updates, it may be necessary to send the board back to be reflashed, presumably via some sort of direct hardware connection.
>If boot firmware implemented it, I wouldn't count on it being updated very often.
That's precisely the problem when it's not possible to upgrade that boot firmware without the vendor's help.
Or why x86 firmware contains microcode, yet we still have to update it later.
That's precisely the problem when it's not possible to upgrade that boot firmware without the vendor's help.
Or why x86 firmware contains microcode, yet we still have to update it later.
No thanks. Early boot software should only do the bare minimum required to hand over control to the real operating system.
If this means some code duplication between operating systems, that’s OK.
If this means some code duplication between operating systems, that’s OK.
In contrast, I prefer starting the kernel on a cpu that doesn't have known microcode bugs, which implies doing the upgrade earlier, be it in firmware or bootloader.
Fortunately, fwupd, together with UEFI capsule, can make upgrading firmware very easy and safe.
Ideally, a CPU wouldn't have to get that many microcode updates anyway.
Fortunately, fwupd, together with UEFI capsule, can make upgrading firmware very easy and safe.
Ideally, a CPU wouldn't have to get that many microcode updates anyway.
RISC V will end at the same fate when implemented by the same vendors
I don't know to what extent but I believe that's what AMD's openSIL project aims to do.
https://github.com/openSIL/openSIL
https://github.com/openSIL/openSIL
I totally agree, BUT (there is always a but) a fully open boot process is also fully open for maliciousness.
e.g. With full access to all hardware you could tell the PMIC (Power Management IC) to output the maximum voltage for some pins to permanently damage/destroy the SoC or other hardware on the board. This would also require that the hardware being damaged is also under-clocked for maximum effectiveness.
I love that I have full access to all the hardware, but I always keep in mind that the second that I run other peoples software on my hardware it always opens the possibility that it is no longer my hardware.
e.g. With full access to all hardware you could tell the PMIC (Power Management IC) to output the maximum voltage for some pins to permanently damage/destroy the SoC or other hardware on the board. This would also require that the hardware being damaged is also under-clocked for maximum effectiveness.
I love that I have full access to all the hardware, but I always keep in mind that the second that I run other peoples software on my hardware it always opens the possibility that it is no longer my hardware.
I haven’t checked the changes here, but even if your FW carries a recent ucode at boot, you may find yourself wanting to update the ucode at runtime without a reboot. This is certainly possible on Linux.
This is an area where AMD has typically been better than Intel. With the longevity of the AMD4 platform, even ancient motherboards have had recent BIOS updates to bring in newer AGESA versions, so most motherboards have gotten lots of updates for very long periods of time. I wonder how many Kaby Lake motherboards are still getting updates.
OTOH, no matter the history of updates, it's better to have this under the OS's control, particularly when running OSes more suitable for servers. The thought of sending someone to update a BIOS in a colo facility is just... frightening.
OTOH, no matter the history of updates, it's better to have this under the OS's control, particularly when running OSes more suitable for servers. The thought of sending someone to update a BIOS in a colo facility is just... frightening.
> The thought of sending someone to update a BIOS in a colo facility is just... frightening.
That's not something you do. BMC can update itself and system BIOS out of band for quite some time. Also, if the BIOS update fails, it generally rolls-back itself.
Last but not least, BMC is a completely independent "computer", so system BIOS is foreign to it, so faiing to update the BIOS doesn't brick the box.
Implications of this "independent computer" is subject to another comment, tho.
That's not something you do. BMC can update itself and system BIOS out of band for quite some time. Also, if the BIOS update fails, it generally rolls-back itself.
Last but not least, BMC is a completely independent "computer", so system BIOS is foreign to it, so faiing to update the BIOS doesn't brick the box.
Implications of this "independent computer" is subject to another comment, tho.
> The thought of sending someone to update a BIOS in a colo facility is just... frightening.
Happens a lot more than you’d think.. and for more than just servers (switch gear, routers, appliances etc..)
Happens a lot more than you’d think.. and for more than just servers (switch gear, routers, appliances etc..)
Most decent rack servers will have some out of band management to allow this. If that fails then some dude at Equinix rolls over some stone age KVM trolley for you for a few hundred dollars..
Don’t most modern server motherboards come with a BMC controller that allows KVM over IP? That’s my experience at least for colos.
Plugging those things into the public Internet is a recipe for disaster, and not at all worth it if you just want to use the remote console. They are a lot more than just "KVM over IP", they own the machine totally and completely. BMCs can generally load firmware into CPUs (and NICs, storage controllers, etc.), they can read/write arbitrary locations in host memory, etc.
Those are for plugging into an air-gapped management LAN; their utility is pretty much nil in a shared datacenter. (Which is implied by colocation.) - I would not even connect IPMI unless I "owned" enough of the rack to justify having my own router and switch. If you just have one or a handful of machines, cabled into whatever top of rack switch the DC provisioned, your security posture is way better off just using their crash cart. (Which is roughly the same magnitude of risk as having a keylogger installed; many many magnitudes less than every secret on your machine being compromised.)
Those are for plugging into an air-gapped management LAN; their utility is pretty much nil in a shared datacenter. (Which is implied by colocation.) - I would not even connect IPMI unless I "owned" enough of the rack to justify having my own router and switch. If you just have one or a handful of machines, cabled into whatever top of rack switch the DC provisioned, your security posture is way better off just using their crash cart. (Which is roughly the same magnitude of risk as having a keylogger installed; many many magnitudes less than every secret on your machine being compromised.)
This!
This is why I have a problem with Supermicro. They used to have IMPI that automatically shared the motherboard's primary ethernet when nothing was plugged in to the IPMI port.
You can't disable that in the BIOS. You can't disable IPMI in general, and you can't modify any of the IPMI's settings aside from IP, nor any credentials. They expect you to have an old Windows installation with Java installed in an old version of Internet Explorer to configure the IPMI so that you won't get owned.
Ok. That's bad, but it gets worse. There's no way to disable it via jumper or in hardware in general. In essence, if the battery dies or the BIOS gets reset and nothing is plugged in to IPMI, your machine is basically completely insecure to anyone on the same network.
They said this wasn't a security issue and they wouldn't fix this. Their reaction really turned me off to Supermicro. I ended up buying loopback plugs and installed them in every server I administer to avoid this.
So what do I do now? I run serial consoles on my servers and connect a small SBC, like a Nano Pi or Raspberry Pi that's only configured with ssh keys on IPv6. Since most UEFI implementations support serial consoles, you can do almost as much as we could do with real Unix servers of the past.
This is why I have a problem with Supermicro. They used to have IMPI that automatically shared the motherboard's primary ethernet when nothing was plugged in to the IPMI port.
You can't disable that in the BIOS. You can't disable IPMI in general, and you can't modify any of the IPMI's settings aside from IP, nor any credentials. They expect you to have an old Windows installation with Java installed in an old version of Internet Explorer to configure the IPMI so that you won't get owned.
Ok. That's bad, but it gets worse. There's no way to disable it via jumper or in hardware in general. In essence, if the battery dies or the BIOS gets reset and nothing is plugged in to IPMI, your machine is basically completely insecure to anyone on the same network.
They said this wasn't a security issue and they wouldn't fix this. Their reaction really turned me off to Supermicro. I ended up buying loopback plugs and installed them in every server I administer to avoid this.
So what do I do now? I run serial consoles on my servers and connect a small SBC, like a Nano Pi or Raspberry Pi that's only configured with ssh keys on IPv6. Since most UEFI implementations support serial consoles, you can do almost as much as we could do with real Unix servers of the past.
In any given OS that has the capability to update microcode -- it should be an easy-to-find and easy-to-set option for the end user...
Your computer, your preference... whatever that may be...
Also, somewhat related -- has anyone heard of microcode updates for RISC-V CPU's?
To date, I have not...
(...but then again, I'm not at the cutting edge of RISC-V development in Silicon Valley...)
Your computer, your preference... whatever that may be...
Also, somewhat related -- has anyone heard of microcode updates for RISC-V CPU's?
To date, I have not...
(...but then again, I'm not at the cutting edge of RISC-V development in Silicon Valley...)
Probably because of this?
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-2059...
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-2059...
But we have to work with the poor state some motherboard vendor's UEFI BIOS leaves the computer in, as control is passed to Openbsd's bootloader.
We should prevent ever getting to this situation on RISC-V. So far, implementations have done well in this regard, with TH1520 and JH7110 following u-boot spl to opensbi to u-boot flow, with UEFI on the works on the latter chip.