Newer versions of SGX include the "Flexible Launch Control" feature, which allows you to control the SGXLEPUBKEYHASH setting on the CPU. This contains the hash of the public key that the "launch enclave" for SGX must be signed with, which further grants tokens that can be used to launch subsequent enclaves (AFAIU). Control of the launch enclave key has been the main source of contention over SGX, as far as I can tell, since you currently have to enter into negotiations with Intel to get your enclave signed by their key.
Based on some posts from Andy Lutomirski on LKML, it seems highly unlikely that any SGX support will go upstream in Linux until Flexible Launch Control is available in consumer SKUs, at least.[1] In fact, I looked up the latest patches posted just a few days ago, which "Removed in-kernel LE i.e. this version of the SGX software stack only supports unlocked IA32_SGXLEPUBKEYHASHx MSRs."[2]
"SGXv2" with FLC is allegedly available in some SKUs right now (based on some googling[3]), but Intel hasn't been very forthcoming on exactly which ones those are, or even what the major differences between v2 and v1 are, besides FLC...
And that horrible situation was only done because the purchasers never got the owner TPM key.
This could have been solved if the "computer purchaser" == "computer owner". Instead, you buy hardware but Intel and who else the fuck other owns the rights to functionality.
I went with AMD for my recent computer. The TPM is a separate module that you have to purchase and slot on the motherboard. I didn't get one.
If you are using Ryzen, then the PSP contains a firmware implementation of a TPM 2.0 chip anyway. All Ryzen chips are equipped with this. On certain BIOSes, you can turn off the PSP functionality that enables the fTPM, from my understanding (this also disables other functionality, such as encryption offload).
But you can also just ignore a TPM anyway, there's nothing mandating you use it, even if it's there. SGX is somewhat similar, since some cooperation is needed by the operating system to launch enclaves anyway (AFAIU), even if the enclaves are intel-signed, and the user has to authorize that (unless just random unprivileged users can install enclaves willy-nilly, but that seems like a bad idea).
SGX doesn't really seem to add much to any realistic threat model where "Intel is your enemy", given that threat model presumably already includes the Management engine (or AMD PSP) anyway, if it was really your worry. So you were already getting screwed long before this, really -- in such a scenario, they were able to launch undetectable code long before this.
SGX-enabled boot-based malware seems like a much more problematic case that's possible, but given how effective the most basic Ransomware, etc seems to be already without these features, I'm not sure most malware authors need significantly more advanced techniques than this. You're probably screwed anyway.
If I understood it well, the main security concerns are moved to the KMS, that you must refer is not susceptible to the same kind of attacks that they describe (untrusted environments, potentially with unknown database administrators, server administrators, OS and hypervisors). I have not a vast experience with KMSs, what would be your approach to deploy one you can trust in a cloud environment, deploying it on bare metal?
https://www.theregister.co.uk/2017/09/27/signal_turns_to_int...
HN thread: https://news.ycombinator.com/item?id=15935955