This is email is me being kinda lazy. Does anyone know how challenging this would actually be to pull off? I'm interested in looking into it, but can't for a while. I feel like it makes sense to bootload some little stub that sets up seL4 as the only enclave in the system. I don't see any reason to have multiple enclaves when using seL4. But, from this, it should be possible to get a good static root of trust remote attestation on Google Cloud. (And also, can finally implement https://www.blackhat.com/docs/us-17/thursday/us-17-Swami-SGX-Remote-Attestat...) -- cmr http://octayn.net/ +16038524272
On 27 Feb 2018, at 20:47, Corey Richardson
This is email is me being kinda lazy. Does anyone know how challenging this would actually be to pull off? I'm interested in looking into it, but can't for a while.
I feel like it makes sense to bootload some little stub that sets up seL4 as the only enclave in the system. I don't see any reason to have multiple enclaves when using seL4. But, from this, it should be possible to get a good static root of trust remote attestation on Google Cloud.
Running seL4 as the trusted base on SGX would be nice. Unfortunately, SGX has a major shortcoming (which I told the Intel folks as soon as I saw it first): SG enclaves run in Ring 3. Which means there is no protection inside an enclave, you have to trust everything in there, and consequently seL4 is of no help at all. Gernot
On Tue, Feb 27, 2018 at 2:02 AM,
Running seL4 as the trusted base on SGX would be nice. Unfortunately, SGX has a major shortcoming (which I told the Intel folks as soon as I saw it first): SG enclaves run in Ring 3. Which means there is no protection inside an enclave, you have to trust everything in there, and consequently seL4 is of no help at all.
I think it'd be fantastic to use seL4 as a sort of "enclave hypervisor", where enclave(s) can make OCALLs to seL4 to access (from the enclave's perspective) untrusted services, e.g. speaking to networks or interacting with filesystems. If an enclave can OCALL out to communicate to the network, trust can be established by terminating a cryptographically secure channel protocol (e.g. TLS, Noise) inside of the enclave. Filesystem access can be similarly secured by only storing cryptographically authenticated data, e.g. files encrypted with an AEAD scheme with keys held inside the enclave. I think it'd be very neat to use seL4 in this way: running one or more enclaves, and potentially some (untrusted from SGX's perspective) userspace services that e.g. provide a web UI or other functionality that doesn't need access to enclave facilities/secrets. You'd need to effectively reimplement the whole SGX RTS to accomplish this, but I know at least one person who has already done that (in Rust, as it were): https://github.com/jethrogb/sgx-utils -- Tony Arcieri
On Tue, Feb 27, 2018, at 05:02, Gernot.Heiser@data61.csiro.au wrote:
Running seL4 as the trusted base on SGX would be nice. Unfortunately, SGX has a major shortcoming (which I told the Intel folks as soon as I saw it first): SG enclaves run in Ring 3. Which means there is no protection inside an enclave, you have to trust everything in there, and consequently seL4 is of no help at all.
That's obnoxious and kinda shitty. Hopefully RISC-V can get it right. -- cmr http://octayn.net/ +16038524272
Hi! As Gernot mentioned, enclaves run in ring 3. There's currently no possibility to implement something like kernel enclaves with SGX. To be slightly off-topic: Instead of trying to run seL4 inside SGX, one can think the other way round and use seL4 to augment SGX enclaves with trusted platform services (e.g. http://arxiv.org/abs/1701.01061). Best, Sammey On 2018-02-27 10:47, Corey Richardson wrote:
This is email is me being kinda lazy. Does anyone know how challenging this would actually be to pull off? I'm interested in looking into it, but can't for a while.
I feel like it makes sense to bootload some little stub that sets up seL4 as the only enclave in the system. I don't see any reason to have multiple enclaves when using seL4. But, from this, it should be possible to get a good static root of trust remote attestation on Google Cloud.
(And also, can finally implement https://www.blackhat.com/docs/us-17/thursday/us-17-Swami-SGX-Remote-Attestat...)
participants (4)
-
Corey Richardson -
Gernot.Heiser＠data61.csiro.au -
Samuel Weiser -
Tony Arcieri