On 9/13/21 11:35 AM, Paolo Bonzini wrote: >>> Apart from reclaiming, /dev/sgx_vepc might disappear between the first >>> open() and subsequent ones. >> >> Aside from it being rm'd, I don't think that's possible. >> > > Being rm'd would be a possibility in principle, and it would be ugly for > it to cause issues on running VMs. Also I'd like for it to be able to > pass /dev/sgx_vepc in via a file descriptor, and run QEMU in a chroot or > a mount namespace. Alternatively, with seccomp it may be possible to > sandbox a running QEMU process in such a way that open() is forbidden at > runtime (all hotplug is done via file descriptor passing); it is not yet > possible, but it is a goal. OK, so maybe another way of saying this: For bare-metal SGX on real hardware, the hardware provides guarantees SGX state at reboot. For instance, all pages start out uninitialized. The vepc driver provides a similar guarantee today for freshly-opened vepc instances. But, vepc users have a problem: they might want to run an OS that expects to be booted with clean, fully uninitialized SGX state, just as it would be on bare-metal. Right now, the only way to get that is to create a new vepc instance. That might not be possible in all configurations, like if the permission to open(/dev/sgx_vepc) has been lost since the VM was first booted. Windows has these expectations about booting with fully uninitialized state. There are also a number of environments where QEMU is sandboxed or drops permissions in a way that prevent free and open access to /dev/sgx_vepc. So good so far?
