Hacker News new | ask | show | jobs
by ongy 1033 days ago
For the claim of GGP (stealing out of memory) it's worse, as that's still possible, and there's a bus the key travels over.

The PCRs attest system state to the OS, yes. Though the verified boot (PSB/Secure Guard + Secure Boot) chain is supposed to provide the same security there. Provided we assume security features aren't broken by design...

1 comments

At least TME-MK and its AMD equivalent are supposed to address in memory key stealing/memory bus snooping (even if it's still unclear to me how the key are generated/stored). There is still decapping and probing the CPU itself but given the size of features is that even remotely doable?
Yes and no. Mostly no IMO

The memory encryption features are a solution to very specific problems.

If the CPU is able to access the memory, then any exploit that gains the execution context of the legitimate user can also access the memory. If it doesn't, the normal memory access control should be enough.

I'm iffy on how well they protect against the various side channels. Mostly because I haven't looked far enough into it.

IME it protects against cold boot attacks, a theoretic attack of a logic analyzer on the memory bus, and potentially to some degree unbounded reads. But the latter only with very limited gadgets.

Should protect against warm boot attacks since the key is supposed to be reset on CPU reboot.
Yeah I was unclear, it's supposed to address the physical attacks part. If no key leaves the CPU unwrapped, it's down to software exploits and decapping the CPU...
Gotcha. Yes

There's also this project https://www.cs1.tf.fau.de/research/system-security-group/tre... which reserves some CPU registers (iirc. A hardware aes accelerator on one core) to prevent key leakage.