Hacker News Reader

Comment by maltalex | Hacker News Reader

Yeah, well, let's not break out the champagne yet. According to your link:

> The BIOS (or UEFI) updates the CPU microcode during boot, however most of the time either the motherboard vendor won't issue frequent BIOS/UEFI updates, or the user won't install such updates. For these reasons, the system processor is likely to be running with outdated microcode on a vast number of systems.

We still need the various manufacturers to release a BIOS version for a bunch of hardware they manufactured years ago. I'm not sure that's going to happen, at least not quickly.

View on HN

Microcode is updated by OSes as well as BIOSes. I explained this in a previous thread: https://news.ycombinator.com/item?id=16075376

Microsoft is still saying that users need firmware/BIOS updates to be protected. Their messaging is at best confusing on this if they're going to apply microcode updates themselves.

In the early days after disclosure at least, a BIOS/firmware update for my machine (from Dell) was required to provide the necessary hardware support for their branch target injection mitigation. As far as I can tell, that's still the case today.

Perhaps they're waiting for the updates to be available for more processors before pushing an update?

I think that claim is incorrect. I'd be surprised if Windows Update didn't download and load updated vendor microcode, and most Linux distributions do (or can), too. At least, I know Fedora does it by default.

I'm sure they would if that's possible. But if microcode can only be updated by the BIOS, you'd need a BIOS update.

Microcode can definitely be loaded by the OS.

Like others have said typically the microcode update is applied by both the BIOS and kernel. Typically the kernel has the latest microcode.

However, there could be an issue where updating the microcode at kernel time can cause an issue due to a microcode version (or lack of) from the BIOS.

Only other thing I could think of is the microcode update that disables TSX, I believe, could only disable it if TSX wasn't used yet.

So I suppose it's also possible that the microcode has to be updated by the BIOS because some boot process prevents the kernel from being effective with its microcode update step.

OS vendors can update the microcode when first booting the OS.

Yes, I was having a poke through dmesg after today's patch to see what my venerable i7 from ~2005 said relating to KPTI. The first line of output is:

[ 0.000000] microcode: CPU0 microcode updated early to revision 0x19, date = 2013-06-21

I think the rest of the cores get updated a bit later in the process.

Reply on news.ycombinator.com