But it supercharges what can be done once you get root, no?

AFAIK you can't usually replace CPU microcode, as it is signed. Seizing it here, in RW memory, really begs to toy with it: add instructions, edit them. Could you teach your CPU to understand RISC-V?

This is just one random idea. But altering PSP code is also interesting, to use it for your own purposes, or extract encryption keys / make it lie to clients (breaking DRM, for instance).

>Could you teach your CPU to understand RISC-V?

The bulk of microcode is still ROM inside the CPU. Also it's mostly used for the more complex instructions, the basic load/store/add/etc. would be decoded and executed more directly.

CPUs have a limited amount of SRAM for holding patches, basically a list of addresses in the microcode ROM, and what their contents should be replaced with. Not enough to totally change the instruction set, but still exciting to potentially get write access to, as indeed the normal update mechanism requires those patches to be cryptographically signed by Intel/AMD.

You can already load your own microcode, and it also works on newer CPUs than the one that the attack described in the OP targets. https://github.com/google/security-research/tree/master/pocs...

By a LOT. It would expose the data Windows keeps isolated using virtualization based security.

Does this mean the exploit can be used in a VM to get access to the host machine?

Not necessarily. A VM doesn't have a "real" DMA controller, and this exploit is specific to a family of real hardware CPUs.

Its not to say that its not impressive, but its fairly isolated to a specific family of processors from 2013.

Oh, right. I forgot that DMA controllers are virtualized on VMs.

Yep.