OpenBSD: AMD processor microcode support added to -current
undeadly.org
undeadly.org
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.
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.
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.
And very few people update their BIOS with any frequency. But most people update their OS.
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.
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.
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.
If this means some code duplication between operating systems, that’s OK.
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.
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.
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.
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.
Happens a lot more than you’d think.. and for more than just servers (switch gear, routers, appliances 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.)
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.
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...)
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-2059...