Windows Client Guidance against speculative execution vulnerabilities

fdegrove said:

Hi,



Was wondering about that too. Seems like every new version of W10 is like a new OS all on its own....
After all, this is only a MC emulation, right ?

Cheers,

I don't know. I'm still unable to find a source that states that Windows doesn't copy the microcode update to volatile memory on the CPU and instead runs some sort of emulation.

Microsoft updated article in first post on May 17, 2018.

Ground Sloth said:

I don't know. I'm still unable to find a source that states that Windows doesn't copy the microcode update to volatile memory on the CPU and instead runs some sort of emulation.

This paper makes it clear that the update mechanism and the end result is the same whether delivered by the bios, Windows drivers or Linux. The microcode is written to the cpu.

...Although this microcode was initially implemented on read-only memory, processor manufacturers soon introduced writable patch memory to provide an update mechanism...
...
4.2 Update Mechanism
The microcode update mechanism is very similar across all x86 processor manufacturers, primarily by using processor model-specific register (MSR) registers to read the current microcode revision and write the new microcode update...
...
4.3.2 Windows
Although less well documented, microcode updates are performed by bundled device drivers on Windows XP and later. Unlike the Linux update module, these Windows drivers have binary microcode updates integrated within the segments, and cannot load microcode from manufacturer-supplied update packages...

https://www.dcddcc.com/docs/2014_paper_microcode.pdf

Ground Sloth said:

More specifically, the microcode update is written to volatile memory on the CPU and is thus not persistent across reboots.

I fail to see a problem with that. Once loaded its a permanent part of the cpu until you power down. Then it loads again from (preferably) the bios at next power up.

That's the mechanism all the CPU manufacturers have chosen to use. You'd prefer it to be read-only, as it initially was in the '70s? Or EEPROM/flash (like legacy bios chips) with a limited number of erase/write cycles?

Bree said:

I fail to see a problem with that. Once loaded its a permanent part of the cpu until you power down. Then it loads again from (preferably) the bios at next power up.

That's the mechanism all the CPU manufacturers have chosen to use. You'd prefer it to be read-only, as it initially was in the '70s? Or EEPROM/flash (like legacy bios chips) with a limited number of erase/write cycles?

I never said it was problematic.

I've been saying for a couple months that regardless if the BIOS or Windows updates the CPU microcode, the microcode update is written to volatile memory on the CPU. But some other forum members have told me that I'm wrong.

Ground Sloth said:

I've been saying for a couple months that regardless if the BIOS or Windows updates the CPU microcode, the microcode update is written to volatile memory on the CPU. But some other forum members have told me that I'm wrong.

No argument with you there @Ground Sloth, we are in total agreement. BIOS or Windows, the same microcode gets written to the CPU either way.

Some seem to have got the idea that the update isn't a 'proper' solution, that it is some sort of software 'simulation' or 'emulation' running in conventional memory - they are mistaken.