3 ms·

The SGX launch has been one of the worst launches of a major CPU feature I've ever seen coming from Intel; it would be really interesting to learn what went wro

by rdl 11y ago

The SGX launch has been one of the worst launches of a major CPU feature I've ever seen coming from Intel; it would be really interesting to learn what went wrong and why. It's years later than people anticipated (and won't be in the E5 xeons for a couple more cycles, so 2017/2018/2019). Not quite NetBurst level, but pretty horrible from a generally execution-excellent company.

userbinator 11y ago
I suspect there was significant opposition to SGX from various groups, even from within Intel.
- costan 11y ago
  SGX serves a good purpose, at least in theory. Many people, myself included, wanted it to turn out to be good. So, I don't think many Intel folks objected to it. Instead, I think that a bunch of MBAs showed up and decided SGX is security, security is an enterprise thing, so SGX must be pay-to-play. For whatever it's worth, I think the SGX designers did a pretty good job of separating the objectionable parts from the rest of the design. For example, the EPID homebrew crypto is all in software, so Intel can change the algorithm without hardware mods or microcode updates. Also, the way they set up the Launch Enclave gives Intel time until the very last minute to not be a douche. They still have the option to release a permissive Launch Enclave that only includes the checks needed to keep attestation secure. The SGX design that doesn't come from MBAs is quite clean, given that it addresses the multi-layered crap pile that is X86. There are some cool tricks in there.
  - nullc 11y ago
    Intel presented on SGX at Real World crypto. If the functionality works as is being described here, I feel they deceived the audience, both in their presentations and in 1:1 discussions. This is especially unfortunate, since I know for a fact their actions have influenced purchasing decisions.
tenfingers 11y ago
It's also a completely useless feature in the chip without the ability to setup arbitrary keys at boot time. This is the worst DRM incantation ever. I expect AMD to clean up Intel's act on this.
- rdl 11y ago
  ARM (well, ARM licensees), more so.
  - userbinator 11y ago
    A lot of ARM SoCs, particularly in the mobile world, have always had features like this. Apple even explicitly advertises it as a security feature on their iDevices. I think the difference here is because x86/PC has traditionally been one of the more open platforms, so attempts at locking it down are more strongly opposed. The PC is one of the few remaining computing devices where you can still inspect, modify, and develop with relative freedom.
    - rdl 11y ago
      There's a lot of new stuff coming in the ARM world which goes way beyond what they have today. (I know about a couple under NDA, and about the current state of the art, so I have to assume there are others). The best "demo" of this in a fairly open way is USB Armory; they exposed the best features currently available in a developer friendly way. But there are some other things coming which are even better. (I care about end users being able to trust remote servers; I don't really care about remote content owners being able to trust local client devices. There are usually no rights issues with the former, and DRM is the obvious (but not only) use case for the latter. I generally believe whoever buys a piece of hardware deserves full rights to it, but there are cases where that's an organization and they have ever right to expect all of their widely-deployed hardware is untampered...for instance, a closed computing environment for processing PII of third parties.)
costan 11y ago
Perhaps it means they're trying to be thorough? A Xeon implementation would have to secure the QPI links between the CPU chips. These run at significantly higher speeds than DRAM, so the current MEE design would likely not be able to keep up. Also, a Xeon implementation would have to somehow have the chips mutually authenticate each other. That being said, I wouldn't be surprised if Intel was trying to see if they can get away with the licensing bs in desktops before committing resources to tackling the challenges that I mentioned above.

by rdl 11y ago

userbinator 11y ago

I suspect there was significant opposition to SGX from various groups, even from within Intel.

costan 11y ago
SGX serves a good purpose, at least in theory. Many people, myself included, wanted it to turn out to be good. So, I don't think many Intel folks objected to it. Instead, I think that a bunch of MBAs showed up and decided SGX is security, security is an enterprise thing, so SGX must be pay-to-play. For whatever it's worth, I think the SGX designers did a pretty good job of separating the objectionable parts from the rest of the design. For example, the EPID homebrew crypto is all in software, so Intel can change the algorithm without hardware mods or microcode updates. Also, the way they set up the Launch Enclave gives Intel time until the very last minute to not be a douche. They still have the option to release a permissive Launch Enclave that only includes the checks needed to keep attestation secure. The SGX design that doesn't come from MBAs is quite clean, given that it addresses the multi-layered crap pile that is X86. There are some cool tricks in there.
- nullc 11y ago
  Intel presented on SGX at Real World crypto. If the functionality works as is being described here, I feel they deceived the audience, both in their presentations and in 1:1 discussions. This is especially unfortunate, since I know for a fact their actions have influenced purchasing decisions.

tenfingers 11y ago

It's also a completely useless feature in the chip without the ability to setup arbitrary keys at boot time. This is the worst DRM incantation ever. I expect AMD to clean up Intel's act on this.

rdl 11y ago
ARM (well, ARM licensees), more so.
- userbinator 11y ago
  A lot of ARM SoCs, particularly in the mobile world, have always had features like this. Apple even explicitly advertises it as a security feature on their iDevices. I think the difference here is because x86/PC has traditionally been one of the more open platforms, so attempts at locking it down are more strongly opposed. The PC is one of the few remaining computing devices where you can still inspect, modify, and develop with relative freedom.
  - rdl 11y ago
    There's a lot of new stuff coming in the ARM world which goes way beyond what they have today. (I know about a couple under NDA, and about the current state of the art, so I have to assume there are others). The best "demo" of this in a fairly open way is USB Armory; they exposed the best features currently available in a developer friendly way. But there are some other things coming which are even better. (I care about end users being able to trust remote servers; I don't really care about remote content owners being able to trust local client devices. There are usually no rights issues with the former, and DRM is the obvious (but not only) use case for the latter. I generally believe whoever buys a piece of hardware deserves full rights to it, but there are cases where that's an organization and they have ever right to expect all of their widely-deployed hardware is untampered...for instance, a closed computing environment for processing PII of third parties.)

costan 11y ago

Perhaps it means they're trying to be thorough? A Xeon implementation would have to secure the QPI links between the CPU chips. These run at significantly higher speeds than DRAM, so the current MEE design would likely not be able to keep up. Also, a Xeon implementation would have to somehow have the chips mutually authenticate each other. That being said, I wouldn't be surprised if Intel was trying to see if they can get away with the licensing bs in desktops before committing resources to tackling the challenges that I mentioned above.