11–20 of 138 posts
Good riddance. (For those unaware, basically the only use-case of SGX was hardware-enforced DRM.)
Good riddance. (For those unaware, basically the only use-case of SGX was hardware-enforced DRM.)
On consumer CPUs DRM may have been the only use case, and indeed good riddance. But on the server side it's possible for tenants to use these hardware features to run workloads that the hosts verifiably cannot modify or inspect. In other words, this lets you use AWS/GCP/Azure etc. while keeping both your data and your code competely opaque to Amazon/Google/Microsoft etc. Disclaimer: my job is to write the software th…
[0] - https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthen...
[1] - https://www.intel.com/content/www/us/en/developer/articles/t...
[2] - https://azure.microsoft.com/en-us/blog/azure-and-amd-enable-...
Good riddance. (For those unaware, basically the only use-case of SGX was hardware-enforced DRM.)
On consumer CPUs DRM may have been the only use case, and indeed good riddance. But on the server side it's possible for tenants to use these hardware features to run workloads that the hosts verifiably cannot modify or inspect. In other words, this lets you use AWS/GCP/Azure etc. while keeping both your data and your code competely opaque to Amazon/Google/Microsoft etc. Disclaimer: my job is to write the software th…
As a security researcher and given past showings from Intel, I wouldn't put much faith in SGX, even if they try to fix past flaws. SGX as a concept for tenant-provider isolation requires strong local attacker security, which is something off the shelf x86 has never had (not up to contemporary standards, ever) and certainly not in anything Intel has put out. They've demonstrated they don't have the culture nor security chops to actually engineer a system that could be trusted, IMO. Plus then there's all the microarchitectural leak vectors with a shared-CPU approach like that, and we know Intel have utterly failed there (not just Spectre; there was absolutely no excuse for L1TF and some of the others, and those really showed us just how security-oblivious Intel's design teams are).
Right now, the x86 world would probably do well to listen to Microsoft, since their Xbox division managed to coax AMD into actually putting out secure silicon (they're one of the two big companies doing proper silicon security at the consumer level, the other being Apple and Google trying to catch up as a distant third). But given the muted response to Pluton from the industry, and the poor way in which this is all being marketed and explained, I'm not sure I have much hope right now...
Good riddance. (For those unaware, basically the only use-case of SGX was hardware-enforced DRM.)
Earlier quoted context omitted.
I thought you could use it for HSM-type workloads too
Like a third party’s HSM running locally on your computer, heh
They claim SGX support on Xeon is still “full steam ahead” https://community.intel.com/t5/Blogs/Products-and-Solutions/...
They claim SGX support on Xeon is still “full steam ahead” https://community.intel.com/t5/Blogs/Products-and-Solutions/...
Curious how there is no CSAM scare mongering when it's companies that need private storage of information.
edit: as for why this is bad, federal law enforcement have a lot more pull when seeking change in laws in congress. Maybe Apple would've had to implement a government backdoor into iPhone itself if they didn't pull the CSAM scanning stunt (and I imagine they knew the backlash was inevitable, which allowed them to use that backlash as reason to push back on either scanning or a backdoor).
Earlier quoted context omitted.
On consumer CPUs DRM may have been the only use case, and indeed good riddance. But on the server side it's possible for tenants to use these hardware features to run workloads that the hosts verifiably cannot modify or inspect. In other words, this lets you use AWS/GCP/Azure etc. while keeping both your data and your code competely opaque to Amazon/Google/Microsoft etc. Disclaimer: my job is to write the software th…
Of course, that requires tenants trust Intel's security. As a security researcher and given past showings from Intel, I wouldn't put much faith in SGX, even if they try to fix past flaws. SGX as a concept for tenant-provider isolation requires strong local attacker security, which is something off the shelf x86 has never had (not up to contemporary standards, ever) and certainly not in anything Intel has put out. The…
I generally agree with you. But I recently realized there might be one usecase, and it's pretty much what signal is doing. They're processing address books in SGX so that they can't see them. I don't have much faith in the system because I don't trust SGX, of course.
But there is one interesting aspect to this. If anyone comes knocking and tells them to start logging all address books and hand them over, they can say that it's not possible for them to do so.
Anyone wanting to do that covertly would at least need to bring their own SGX exploits, meaning it probably offers SOME level of protection. Certainly not if the NSA wants the data or some LEA is chasing something high-profile enough that they're willing to buy exploits and get a court order allowing them to use them. But it does allow them to respond with "we don't have this kind of data".
Good riddance. (For those unaware, basically the only use-case of SGX was hardware-enforced DRM.)
On consumer CPUs DRM may have been the only use case, and indeed good riddance. But on the server side it's possible for tenants to use these hardware features to run workloads that the hosts verifiably cannot modify or inspect. In other words, this lets you use AWS/GCP/Azure etc. while keeping both your data and your code competely opaque to Amazon/Google/Microsoft etc. Disclaimer: my job is to write the software th…