New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
Um it would sort of defeat the purpose since the vps host could control it. Plus SGX seems more and more bogus in the face of attacks like Spectre. SGX only makes even minimal sense on a dedi, and even then it is questionable. You really want secrets management on separate hardware, like AWS KMS/Parameter Store.
AMD Epyc cpus have something similar to SGX with probably the same issues, if that's of any interest.
Well, not exactly. That's the whole point of SGX: nothing but your enclave has access to your data. Not ring0, nor bios, etc. But, if by "could control it" you mean it can DoS your enclave; yup, it can.
No. Virtual servers are virtualized (that's why they call them virtual) and all the hardware is emulated (thus the EMU in QEMU) as far as you can tell. That includes the SGX. There is no way to know that the host doesn't control the enclave contents. With hardware SGX, it's possible that Intel (the hardware manufacturer that controls the chip design) has some way to access your enclave. With virtual SGX, replace "Intel" with the server host.
(Hmm maybe there's some remote attestation feature using Intel-controlled private keys in the chip, but that sounds hard to virtualize).
Remote attestation is exactly the way to know that the host doesn't control the enclave contents.
¯\_(ツ)_/¯
Hmm ok I better check the SGX docs, but I thought it usually involved a certificate from the individual unit (something like an HSM serial number). So there wouldn't be a way for a host to make 1000s of virtual ones, if the certificate had to be signed by Intel. Therefore you have something more like a dedi than a VM.