3 ms·

I fully agree with all of what you said. There's a big difference between "hey can you dump this VM for me please" and "hey please implement this paper to dump

by lima 6y ago

I fully agree with all of what you said. There's a big difference between "hey can you dump this VM for me please" and "hey please implement this paper to dump this customer's VM" and it provides cloud providers with plausible deniability when law enforcement comes knocking. It's certainly useless once your threat model includes grad students with lots of time at their hands. The "trusted hypervisor" approach is actually what my company is working on, with SEV just as a convenient attestation mechanism and nice defense in depth. Yes, with SEV the guest OS has to assume that the emulated hardware is untrusted and I'm quite sure that no OS was built with this threat model in mind. It's not as bad as proxying syscalls from SGX to the host kernel because there's a lot smaller attack surface, but I bet you could find a hundred ways to compromise a stock Linux kernel running in SEV. I'm more optimistic about unikernels written in say, Rust, which would still be a much friendlier API than SGX.

thu2111 6y ago
Ah, my company is working with SGX. Perhaps that explains our difference of view ;) The hypervisor ABI is quite large, perhaps not as large as a kernel's but it doesn't really make sense to expose the same API to secure code anyway. For instance an encrypted VM that then uploads its data somewhere else via raw TCP sockets doesn't make sense conceptually, even though the API allows it. You have to use SSL. Likewise an encrypted VM that downloads software updates from the repositories of a cloud provider, also doesn't make much sense, even though nothing in the tech stops it. The nice thing about an enclave is you can understand completely the data flows in and out by examining the interface. That does mean compiling existing software for it will die with unimplemented functions. But those errors are probably telling you something meaningful - i.e. if the code attempts to call socket() or open() then you can just relay them outside the enclave, but it makes more sense to think about what you're really trying to do. It's a more purist approach with worse compatibility, I agree. It's really focused on finding the minimal TCB of your program and excluding all else, like how Chrome moves the rendering engine out of its TCB. I suspect many apps can be designed in such a way that almost all of the code is untrusted, but it's a bit of a frontier and takes quite a bit of skill.

by lima 6y ago

thu2111 6y ago

Ah, my company is working with SGX. Perhaps that explains our difference of view ;) The hypervisor ABI is quite large, perhaps not as large as a kernel's but it doesn't really make sense to expose the same API to secure code anyway. For instance an encrypted VM that then uploads its data somewhere else via raw TCP sockets doesn't make sense conceptually, even though the API allows it. You have to use SSL. Likewise an encrypted VM that downloads software updates from the repositories of a cloud provider, also doesn't make much sense, even though nothing in the tech stops it. The nice thing about an enclave is you can understand completely the data flows in and out by examining the interface. That does mean compiling existing software for it will die with unimplemented functions. But those errors are probably telling you something meaningful - i.e. if the code attempts to call socket() or open() then you can just relay them outside the enclave, but it makes more sense to think about what you're really trying to do. It's a more purist approach with worse compatibility, I agree. It's really focused on finding the minimal TCB of your program and excluding all else, like how Chrome moves the rendering engine out of its TCB. I suspect many apps can be designed in such a way that almost all of the code is untrusted, but it's a bit of a frontier and takes quite a bit of skill.