Hacker News Reader

Comment by bri3d | Hacker News Reader

It leverages Google Asylo as the enclave abstraction layer which currently supports Intel SGX. SGX is (to the dismay of HN readers everywhere) available in Intel server/workstation CPUs since Skylake, so I don't think there's a really "specialized" CPU hardware requirement.

View on HN

Linux will soon support SGX on FLC-enabled (Flexible Launchh Control) hardware. Upstream SGX for non-FLC hardware is not on the roadmap. I have no idea which CPUs support FLC.

Also, I consider SGX to be only barely adequate, if at all, for this type of use case. It’s missing a critical feature to protect enclaves from instances of the same enclave.

But it's not widely available from cloud providers at the moment, particularly if you want meaningful remote attestation to work.

Great, except for the part where SGX is completely broken:

https://www.usenix.org/conference/usenixsecurity18/presentat...

Right, except for the part where it's been patched by a microcode update [0]. You can always choose not to provision enclaves with secrets unless the CPU has SMT disabled.

[0] https://www.intel.com/content/www/us/en/security-center/advi...

If SGX is broken, how can you trust the CPU not to lie about whether it has applied the microcode update and/or disabled SMT?

SGX is "broken" in that it allows exfiltrating data via side channels; AFAICT no one has broken the attestation process by which the CPU effectively signs a statement of its internal state (including SMT) with a key fused into the CPU by Intel at manufacturing time, and which is used as a building block for remote attestation.

If you look at the Usenix paper on the FORESHADOW attack, they did break attestation as well by applying their attack to the quoting enclave to extract attestation keys.

Reply on news.ycombinator.com