Windows Client Guidance against speculative execution vulnerabilities

fdegrove said:

Hi,



MC is a software interpretation layer that sits between the cpu's firmware and the computer system as a whole and resides in the cpu's non-volatile memory. Once it's updated it stays that way untill the next update etc.
In a way it can be viewed as a piece of software that talks to the cpu telling it how to "read" and "execute" instructions coming from the system.

Cheers,

It was my understanding that while the CPU's permanent microcode resides in non-volatile CPU memory, the BIOS/UEFI loads the microcode update into volatile CPU memory on boot.

Hi,

That non-volatile memory can be written to. IOW, it can be flashed just like a BIOS/UEFI, RAID ROM, MEI/AMT management blocks and such.
It suffices to put the CPU with the latest MCU in a different system board to read out the current MC status. It will be the most current one, i.e. the flashed one.

Cheers,

Then the information on the Debian Wiki must be wrong.

Processor microcode is akin to processor firmware. The kernel is able to update the processor's firmware without the need to update it via a BIOS update. A microcode update is kept in volatile memory, thus the BIOS/UEFI or kernel updates the microcode during every boot.

Microcode - Debian Wiki


And according to Mozilla.org,

Microcode updates can be loaded onto the CPU by firmware (usually called BIOS even on computers that technically have UEFI firmware instead of old-style BIOS) or by the operating system. Microcode updates do not persist across reboot, so in the case of a dual-boot system, if the microcode update isn't delivered via BIOS, both operating systems have to provide the update.

Updating processor microcode | Firefox Help

Hi,

No, both are correct and act in a similar way as MS does when no bios/uefi MCU is available.
Note also that these methods are not persistent so these updates needs to be loaded every time the machine starts/restarts.

So, the only way to make it persistent all the time is to flash the CPU's MC.

Cheers,

Hi,

For info:

Title: Microsoft Security Advisory Notification
Issued: April 10, 2018
********************************************************************

Security Advisories Released or Updated on April 10
===================================================================

* Microsoft Security Advisory ADV180002

- Title: Guidance to mitigate speculative execution side-channel
vulnerabilities
- [https:https://portal.msrc.microsoft.com/en...rity-guidance/
advisory/ADV180002
- Reason for Revision:
The following updates have been made: 1. Updated FAQ#10 to
provide additional links for more information about updating
an AMD-based device. 2. Added FAQ #15 to announce that security
update 4093112 for Windows 10 Version 1709 provides addtional
mitigations for AMD processors for CVE-2017-5715, and to provide
further information about these mitigations. 3. Added FAQ #16 to
announce that AMD has started to release microcode updates around
Spectre variant 2 (CVE 2017-5715 Branch Target Injection) for
newer CPU platforms.

- Originally posted: January 3, 2018
- Updated: April 10, 2018
- Version: 16.0

Source: MS e-mail


Cheers,

Hi,

Microcode updates do not persist across reboot, so in the case of a dual-boot system, if the microcode update isn't delivered via BIOS, both operating systems have to provide the update.

Cheers,

I have to respectfully disagree with your interpretation of that sentence.

In any case, the Debian wiki article is more clear about the BIOS/UEFI needing to update the microcode every time the computer is rebooted.

I also found the following comment from a moderator on SuperUser.com:

Microcode updates are not permanent and vanish when the CPU is reset. The microcode updates are usually supplied via motherboard firmware updates. The firmware updates the CPU microcode when your system boots and so the way to roll back an update is to roll back your motherboard firmware.

cpu - Can Intel microcode updates be rolled back? - Super User

Hi,

Sorry but I'm 100% certain I am correct.
It appears you seem to be stuck on how Debian (Linux) updates MC through the OS.
And of course if you reflash the CPU's MC with a previous version of it then you effectively rolled it back.

As said before, flash update a CPU's MC on system one, move that CPU to system two and you'll find the MC of the chip is exactly the same on both boards. Permanently and persistently so.

Cheers,

Ground Sloth said:

I have to respectfully disagree with your interpretation of that sentence.

In any case, the Debian wiki article is more clear about the BIOS/UEFI needing to update the microcode every time the computer is rebooted.

I also found the following comment from a moderator on SuperUser.com:




cpu - Can Intel microcode updates be rolled back? - Super User

The Debian Wiki article is 100% correct. Intel Microcode modifications are volatile and do not permanently alter original Microcode versions baked into the silicon. This is why ideally any update is deployed early after system boot. The BIOS is a good candidate for this purpose as its code is executed traditionally before any OS gets its turn.