Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenBSD: AMD processor microcode support added to -current

undeadly.org

Post reply on HN
Print view View original

11–20 of 23 posts

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

#11

Post by nazgulsenpai »

snvzz wrote: 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…

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

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

#12

Post by booi »

johnklos wrote: post #7

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

> 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..)

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

#13

Post by SoftTalker »

cesarb wrote: post #10
asveikau wrote: post #4

Earlier quoted context omitted.

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.

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

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.

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

#14

Post by yes29922 »

booi wrote: post #12
johnklos wrote: post #7

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

> 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..)

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..

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

#15

Post by asveikau »

KennyBlanken wrote: post #8
asveikau wrote: post #4

Earlier quoted context omitted.

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.

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…

> 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.

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

#16

Post by stingraycharles »

yes29922 wrote: post #14
booi wrote: post #12

Earlier quoted context omitted.

> 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..)

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.

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

#17

Post by bayindirh »

johnklos wrote: post #7

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

> 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.

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

#18

Post by m_z_s »

snvzz wrote: 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…

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.

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

#19

Post by peter_d_sherman »

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...)

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

#20

Post by drbawb »

stingraycharles wrote: post #16
yes29922 wrote: post #14

Earlier quoted context omitted.

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.)

Post reply on HN