4 ms·

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 Inte

by bri3d 7y ago

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.

achamayou 7y ago
But it's not widely available from cloud providers at the moment, particularly if you want meaningful remote attestation to work.
amluto 7y ago
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.
betterunix2 7y ago
Great, except for the part where SGX is completely broken: https://www.usenix.org/conference/usenixsecurity18/presentation/bulck https://www.usenix.org/conference/usenixsecurity18/presentat...
- _nhynes 7y ago
  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/advisory/intel-sa-00161.html https://www.intel.com/content/www/us/en/security-center/advi...
  - teraflop 7y ago
    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?
    - tiziano88 7y ago
      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.
      - betterunix2 7y ago
        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.

by bri3d 7y ago

achamayou 7y ago

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

amluto 7y ago

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.

betterunix2 7y ago

Great, except for the part where SGX is completely broken: https://www.usenix.org/conference/usenixsecurity18/presentation/bulck https://www.usenix.org/conference/usenixsecurity18/presentat...

_nhynes 7y ago
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/advisory/intel-sa-00161.html https://www.intel.com/content/www/us/en/security-center/advi...
- teraflop 7y ago
  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?
  - tiziano88 7y ago
    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.
    - betterunix2 7y ago
      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.