Live data from Hacker News

OpenBSD: AMD processor microcode support added to -current

undeadly.org

21–23 of 23 posts

Re: OpenBSD: AMD processor microcode support added to -current

#21
post #20

Earlier quoted context omitted.

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 mana…

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.

Re: OpenBSD: AMD processor microcode support added to -current

#23
post #2

An example of something that wouldn't be needed at all with an open boot process, as earlier firmware would take care of it. 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…

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.

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.

Post reply on HN