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 i

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.