Messages in this thread | | | Subject | Re: [PATCH 1/2] x86: sgx_vepc: extract sgx_vepc_remove_page | From | Paolo Bonzini <> | Date | Thu, 23 Sep 2021 14:08:56 +0200 |
| |
On 21/09/21 21:44, Jarkko Sakkinen wrote: > "On bare-metal SGX, start of a power cycle zeros all of its reserved > memory. This happens after every reboot, but in addition to that > happens after waking up from any of the sleep states." > > I can speculate and imagine where this might useful, but no matter > how trivial or complex it is, this patch needs to nail a concrete > usage example. I'd presume you know well the exact changes needed for > QEMU, so from that knowledge it should be easy to write the > motivational part.
Assuming that it's obvious that QEMU knows how to reset a machine (which includes writes to the ACPI reset register, or wakeup from sleep states), the question of "why does userspace reuse vEPC" should be answered by this paragraph:
"One way to do this is to simply close and reopen the /dev/sgx_vepc file descriptor and re-mmap the virtual EPC. However, this is problematic because it prevents sandboxing the userspace (for example forbidding open() after the guest starts, or running in a mount namespace that does not have access to /dev; both are doable with pre-opened file descriptors and/or SCM_RIGHTS file descriptor passing)."
> Even to a Linux guest, since EPC should stil be represented in the > state that matches the hardware. It'd be essentially a corrupted > state, even if there was measures to resist this. Windows guests > failing is essentially a side-effect of an issue, not an issue in the > Windows guests.
Right, Linux is more liberal than it needs to be and ksgxd does the EREMOVE itself at the beginning (__sgx_sanitize_pages). Windows has stronger expectations of what can and cannot happen before it boots, which are entirely justified.
Paolo
| |