On 13/09/21 17:29, Dave Hansen wrote:
On 9/13/21 8:14 AM, Paolo Bonzini wrote:
On 13/09/21 16:55, Dave Hansen wrote:
By "Windows startup" I mean even after guest reboot. Because another
process could sneak in and steal your EPC pages between a close() and an
open(), I'd like to have a way to EREMOVE the pages while keeping them
assigned to the specific vEPC instance, i.e.*without* going through
sgx_vepc_free_page().
Oh, so you want fresh EPC state for the guest, but you're concerned that
the previous guest might have left them in a bad state. The current
method of getting a new vepc instance (which guarantees fresh state) has
some other downsides.
Can't another process steal pages via sgxd and reclaim at any time?
vEPC pages never call sgx_mark_page_reclaimable, don't they?
Oh, I was just looking that they were on the SGX LRU. You might be right.
But, we certainly don't want the fact that they are unreclaimable today
to be part of the ABI. It's more of a bug than a feature.
Sure, that's fine.
What's the extra concern here about going through a close()/open()
cycle? Performance?
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.
Paolo
