6 ms·

The juicy bit: "That being said, perhaps the most troubling finding in our security analysis is that Intel included a licensing mechanism in SGX that prevents

The juicy bit: "That being said, perhaps the most troubling finding in our security analysis is that Intel included a licensing mechanism in SGX that prevents software developers who cannot or will not enter a (yet unspecified) busi- ness agreement with Intel from authoring software that takes advantage of SGX’s protections. All the official documentation carefully sidesteps this issue, and has a minimal amount of hints that lead to the Intel’s patents on SGX. Only these patents disclose the existence of licensing plans."

gleenn 11y ago
What are the ramifications of this exactly?
- jjoonathan 11y ago
  It sounds like SGX is intended as a DRM mechanism and intel wants to get a cut.
  - Angostura 11y ago
    I'm certainly not an expert, but more like they want a cut from people hoping to deploy their software on third-party cloud platforms. I presume Intel is hoping that Amazon et al will use the chips and people will pay a premium to run software in an environment where it is hard to compromise the running code.
- ctz 11y ago
  The SDK documentation does, almost, tell you: > The signing tool supports a single-step signing process, which requires > the access to the signing key pair on the local build system. However, > there is a requirement that any white-listed enclave signing key must > be managed in a hardware security module. Thus, the ISV’s test private > key stored in the build platform will not be white-listed and enclaves > signed with this key can only be launched in debug or prerelease mode. And, indeed, launching an enclave without debug mode set fails with 'SGX_ERROR_SERVICE_INVALID_PRIVILEGE' error. A debuggable SGX enclave enables read-a-word and write-a-word primitives, so loses its confidentiality and integrity.
  - amluto 11y ago
    Interesting question: should Linux enable non-debug enclaves at all as long as this policy remains in place?
    - mike_hearn 11y ago
      That'd be a ridiculous sort of circular-DRM move that helps nobody, so, no. One of the primary use cases for this technology is cloud computing. Amazon, Google, etc are all quite capable of patching such checks out of the kernel if they want to use SGX. All it'd do is annoy a few engineers at these companies. Likewise, for deployments on the client, it's really only the Microsoft and Apple kernel devs that matter given the Linux communities tiny desktop market share, and I don't see why they would do that.
      - chc4 11y ago
        So there's absolutely no reason not to implement DRM, ever, because it doesn't help anybody? Abstaining from implementing a feature you don't agree with, especially from an open source program licensed under the GPL, is certainly a worthwhile move. It at the very least communicates that you don't agree with the feature, and forces others to think about the issue deeper to e.g. apply a patch to use it. SGX is the anti-thesis of the GPL and what Stallman has been warning about for years: software that you are physically incapable of debugging, reading, or modifying. And that's scary. Of course, it's silly if you think the kernel won't accept a patch for SGX on moral grounds. It already has several modules for DRM technologies, along with binary blobs for drivers. But it's nice to think about.
        mike_hearn 11y ago
        Why is it nice to think about? It'd be a move as pointless and self-destructive as GCC refusing to implement a usable IR because of Stallman's belief that it'd hurt free software. End result: LLVM is now replacing GCC as the de-facto compiler toolchain of choice. SGX is an optional feature. It doesn't magically run software against your will and it is not "immoral". Ascribing moral positions to CPU features seems ridiculous to me, sort of like describing a pickaxe as "immoral". If you don't want to use it, then don't execute software that includes SGX instructions. If you do want to use it, then all Linux getting in your way will do is convince you that maybe you should be using a different kernel whilst you wait for Intel's own driver to compile and install.
- costan 11y ago
  If SGX becomes successful, Intel becomes the Verizon+ATT+Tmobile+Sprint of hardware security. No signed enclave, no security.

gleenn 11y ago

What are the ramifications of this exactly?

jjoonathan 11y ago
It sounds like SGX is intended as a DRM mechanism and intel wants to get a cut.
- Angostura 11y ago
  I'm certainly not an expert, but more like they want a cut from people hoping to deploy their software on third-party cloud platforms. I presume Intel is hoping that Amazon et al will use the chips and people will pay a premium to run software in an environment where it is hard to compromise the running code.
ctz 11y ago
The SDK documentation does, almost, tell you: > The signing tool supports a single-step signing process, which requires > the access to the signing key pair on the local build system. However, > there is a requirement that any white-listed enclave signing key must > be managed in a hardware security module. Thus, the ISV’s test private > key stored in the build platform will not be white-listed and enclaves > signed with this key can only be launched in debug or prerelease mode. And, indeed, launching an enclave without debug mode set fails with 'SGX_ERROR_SERVICE_INVALID_PRIVILEGE' error. A debuggable SGX enclave enables read-a-word and write-a-word primitives, so loses its confidentiality and integrity.
- amluto 11y ago
  Interesting question: should Linux enable non-debug enclaves at all as long as this policy remains in place?
  - mike_hearn 11y ago
    That'd be a ridiculous sort of circular-DRM move that helps nobody, so, no. One of the primary use cases for this technology is cloud computing. Amazon, Google, etc are all quite capable of patching such checks out of the kernel if they want to use SGX. All it'd do is annoy a few engineers at these companies. Likewise, for deployments on the client, it's really only the Microsoft and Apple kernel devs that matter given the Linux communities tiny desktop market share, and I don't see why they would do that.
    - chc4 11y ago
      So there's absolutely no reason not to implement DRM, ever, because it doesn't help anybody? Abstaining from implementing a feature you don't agree with, especially from an open source program licensed under the GPL, is certainly a worthwhile move. It at the very least communicates that you don't agree with the feature, and forces others to think about the issue deeper to e.g. apply a patch to use it. SGX is the anti-thesis of the GPL and what Stallman has been warning about for years: software that you are physically incapable of debugging, reading, or modifying. And that's scary. Of course, it's silly if you think the kernel won't accept a patch for SGX on moral grounds. It already has several modules for DRM technologies, along with binary blobs for drivers. But it's nice to think about.
      - mike_hearn 11y ago
        Why is it nice to think about? It'd be a move as pointless and self-destructive as GCC refusing to implement a usable IR because of Stallman's belief that it'd hurt free software. End result: LLVM is now replacing GCC as the de-facto compiler toolchain of choice. SGX is an optional feature. It doesn't magically run software against your will and it is not "immoral". Ascribing moral positions to CPU features seems ridiculous to me, sort of like describing a pickaxe as "immoral". If you don't want to use it, then don't execute software that includes SGX instructions. If you do want to use it, then all Linux getting in your way will do is convince you that maybe you should be using a different kernel whilst you wait for Intel's own driver to compile and install.
costan 11y ago
If SGX becomes successful, Intel becomes the Verizon+ATT+Tmobile+Sprint of hardware security. No signed enclave, no security.