https://wiki.debian.org/Microcode
The real news here is that Intel thinks they can fix this via microcode. This is surprising because initially there were some strong arguments that this wouldn't be possible.
The real news here is that Intel thinks they can fix this via microcode. This is surprising because initially there were some strong arguments that this wouldn't be possible.
> 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.
[ 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.
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?
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.