On Mon, 2021-09-13 at 12:25 -0700, Dave Hansen wrote: > 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. So you maintain your systems in a way that this does not happen? /Jarkko
