5 ms·

There’s a pretty straightforward mitigation to this: only allow enclaves from software authors you trust. The kernel does not have to allow usermode to run encl

by strstr 9y ago

There’s a pretty straightforward mitigation to this: only allow enclaves from software authors you trust. The kernel does not have to allow usermode to run enclaves, which is very much by design.

xyzzyz 9y ago
This solution works, with its own caveats, for end users, but doesn't help cloud providers at all. Then again, with current restrictions on SGX, like having to partition out memory for it at boot time, running SGX workloads from VMs on shared machines seems like plenty difficult already.
- kijiki 9y ago
  Azure claims they can do it, but it is still Early Access, so I've not tried it.
- strstr 9y ago
  Cloud providers should already be concerned about rowhammer related DoS anyway, and be mitigating/preventing rowhammer through other means (e.g. buying ram that doesnt suck).
- nullc 9y ago
  > all. Then again, with current restrictions on SGX, like having to partition out memory for it at boot time, Huh? why is this an issue at all. The most memory SGX can directly use is 128MB. So partition it off-- it's a small cost if it's likely that you'll use it. Enclaves are not limited to 128MB in total, since the OS can page in and out SGX pages...
  - duskwuff 9y ago
    > the OS can page in and out SGX pages... That doesn't seem right. How is the OS supposed to page SGX in/out without being able to read its memory?
    - xyzzyz 9y ago
      There is a special dance the OS has to perform in order to do it. In short, the OS calls EWB instruction, which makes CPU read the page from EPC, encrypt it, and write it to normal memory. To load it back, OS executes the ELDB instruction, which decrypts it and writes to EPC. There is slightly more to it due to version array, which is used to prevent replay attacks, but in general, paging in and out is completely fine in SGX.
  - xyzzyz 9y ago
    >Huh? why is this an issue at all. I think you missed my point. I was talking specifically about providing SGX to VM guests on multi-tenant machines. The difficulty is not insurmountable, but other than some experimental Intel patches, KVM doesn’t support it yet.
- Fnoord 9y ago
  >> There’s a pretty straightforward mitigation to this: only allow enclaves from software authors you trust. > This solution works, with its own caveats Yeah, how does one verify the trust of e.g. all the authors of the Linux kernel? The caveat seems that it isn't realistic.
server_bot 9y ago
Intel does support SGX code signing where vendors/developers have to apply (just like getting Windows Kernel drivers signed by Microsoft): https://software.intel.com/en-us/articles/intel-sgx-product-licensing https://software.intel.com/en-us/articles/intel-sgx-product-... To the best of my knowledge, all SGX attack research papers disable checks and run unsigned SGX code to demonstrate a proof of concept. Not saying vendors won't run horrid things in SGX enclaves, just saying malware authors are gonna need to steal a private key first :P
- deleted 9y ago
  [deleted]
- otp124 9y ago
  > To the best of my knowledge, all SGX attack research papers disable checks and run unsigned SGX code to demonstrate a proof of concept. While interesting, papers like these usually have titles that are disingenuous at best. I’ve seen the media report on papers with scary titles and make it sound like the sky is falling, but the scenario is generally (not always) contrived.

by strstr 9y ago

There’s a pretty straightforward mitigation to this: only allow enclaves from software authors you trust. The kernel does not have to allow usermode to run enclaves, which is very much by design.

xyzzyz 9y ago

This solution works, with its own caveats, for end users, but doesn't help cloud providers at all. Then again, with current restrictions on SGX, like having to partition out memory for it at boot time, running SGX workloads from VMs on shared machines seems like plenty difficult already.

kijiki 9y ago
Azure claims they can do it, but it is still Early Access, so I've not tried it.
strstr 9y ago
Cloud providers should already be concerned about rowhammer related DoS anyway, and be mitigating/preventing rowhammer through other means (e.g. buying ram that doesnt suck).
nullc 9y ago
> all. Then again, with current restrictions on SGX, like having to partition out memory for it at boot time, Huh? why is this an issue at all. The most memory SGX can directly use is 128MB. So partition it off-- it's a small cost if it's likely that you'll use it. Enclaves are not limited to 128MB in total, since the OS can page in and out SGX pages...
- duskwuff 9y ago
  > the OS can page in and out SGX pages... That doesn't seem right. How is the OS supposed to page SGX in/out without being able to read its memory?
  - xyzzyz 9y ago
    There is a special dance the OS has to perform in order to do it. In short, the OS calls EWB instruction, which makes CPU read the page from EPC, encrypt it, and write it to normal memory. To load it back, OS executes the ELDB instruction, which decrypts it and writes to EPC. There is slightly more to it due to version array, which is used to prevent replay attacks, but in general, paging in and out is completely fine in SGX.
- xyzzyz 9y ago
  >Huh? why is this an issue at all. I think you missed my point. I was talking specifically about providing SGX to VM guests on multi-tenant machines. The difficulty is not insurmountable, but other than some experimental Intel patches, KVM doesn’t support it yet.
Fnoord 9y ago
>> There’s a pretty straightforward mitigation to this: only allow enclaves from software authors you trust. > This solution works, with its own caveats Yeah, how does one verify the trust of e.g. all the authors of the Linux kernel? The caveat seems that it isn't realistic.

server_bot 9y ago

Intel does support SGX code signing where vendors/developers have to apply (just like getting Windows Kernel drivers signed by Microsoft): https://software.intel.com/en-us/articles/intel-sgx-product-licensing https://software.intel.com/en-us/articles/intel-sgx-product-... To the best of my knowledge, all SGX attack research papers disable checks and run unsigned SGX code to demonstrate a proof of concept. Not saying vendors won't run horrid things in SGX enclaves, just saying malware authors are gonna need to steal a private key first :P

deleted 9y ago
[deleted]
otp124 9y ago
> To the best of my knowledge, all SGX attack research papers disable checks and run unsigned SGX code to demonstrate a proof of concept. While interesting, papers like these usually have titles that are disingenuous at best. I’ve seen the media report on papers with scary titles and make it sound like the sky is falling, but the scenario is generally (not always) contrived.