4 ms·

SEV attestation does delegate to the PSP, no? I think it _might_ be reasonable to attest that upgraded microcode is both present and valid using SEV, without th

by bri3d 2y ago

SEV attestation does delegate to the PSP, no? I think it _might_ be reasonable to attest that upgraded microcode is both present and valid using SEV, without the risk of malicious microcode blinding the attestation, but I’m not positive yet - need to think on it a bit more.

amluto 2y ago
This probably depends on a lot of non-public info: how does the PSP validate CPU state? where does PSP firmware come from? can the PSP distinguish between a CPU state as reported by honest ucode and that state as reported by the CPU running malicious ucode? I think that, at least on Intel, the “microcode” package includes all kinds of stuff beyond just the actual CPU microcode, and I think it’s all signed together. If AMD is like this, than an unpatched CPU can be made to load all kinds of goodies. Also, at least in Intel (and I think also on AMD), most of the SPI flash security mechanism is controlled by SMM code. So any ranges that the CPU can write, unless locked by a mechanism outside of the control of whatever this bug compromises, can be written. This seems pretty likely to include the entire SPI chip, which includes parts controlling code that will run early after the next power cycle, which can compromise the system again.
- mjg59 2y ago
  PSP firmware is in system flash, but is verified by the PSP with its own signing key. PSP firmware is loaded before x86 comes up, and as long as the SEV firmware measures itself and as long as it patches the microcode loader before allowing x86 to run (which the description of the patch claims it does) I think SEV is rescuable.
- sirdarckcat 2y ago
  > This probably depends on a lot of non-public info: how does the PSP validate CPU state? https://github.com/amd/AMD-ASPFW/blob/3ca6650dd35d878b3fcbe5c7f58b145eed042bbf/fw/psp_bl_uapps/sev_uapp/src/sev_hal_interface.c#L746 https://github.com/amd/AMD-ASPFW/blob/3ca6650dd35d878b3fcbe5...
  - amluto 2y ago
    That seems to be reading a memory mapped register per core. I wonder what backs that register.
    - sirdarckcat 2y ago
      It's just written by the CPU during a ucode update

by bri3d 2y ago

amluto 2y ago

This probably depends on a lot of non-public info: how does the PSP validate CPU state? where does PSP firmware come from? can the PSP distinguish between a CPU state as reported by honest ucode and that state as reported by the CPU running malicious ucode? I think that, at least on Intel, the “microcode” package includes all kinds of stuff beyond just the actual CPU microcode, and I think it’s all signed together. If AMD is like this, than an unpatched CPU can be made to load all kinds of goodies. Also, at least in Intel (and I think also on AMD), most of the SPI flash security mechanism is controlled by SMM code. So any ranges that the CPU can write, unless locked by a mechanism outside of the control of whatever this bug compromises, can be written. This seems pretty likely to include the entire SPI chip, which includes parts controlling code that will run early after the next power cycle, which can compromise the system again.

mjg59 2y ago
PSP firmware is in system flash, but is verified by the PSP with its own signing key. PSP firmware is loaded before x86 comes up, and as long as the SEV firmware measures itself and as long as it patches the microcode loader before allowing x86 to run (which the description of the patch claims it does) I think SEV is rescuable.
sirdarckcat 2y ago
> This probably depends on a lot of non-public info: how does the PSP validate CPU state? https://github.com/amd/AMD-ASPFW/blob/3ca6650dd35d878b3fcbe5c7f58b145eed042bbf/fw/psp_bl_uapps/sev_uapp/src/sev_hal_interface.c#L746 https://github.com/amd/AMD-ASPFW/blob/3ca6650dd35d878b3fcbe5...
- amluto 2y ago
  That seems to be reading a memory mapped register per core. I wonder what backs that register.
  - sirdarckcat 2y ago
    It's just written by the CPU during a ucode update