On 10/13/22 14:49, Huang, Kai wrote: >> ... and what happens when *THIS* patch is in play? What if there is a >> machine check in SGX memory? > With this patch, when #MC happens on one virtual EPC page, it will be send to > the VM, and the behaviour inside a VM depends on guest's implementation. But > anyway based on Tony's reply, the enclave will be marked as "bad" by hardware > and it will eventually be killed: > > https://lore.kernel.org/linux-sgx/55ffd9475f5d46f68dd06c4323bec871@xxxxxxxxx/ > https://lore.kernel.org/linux-sgx/5b6ad3e2af614caf9b41092797ffcd86@xxxxxxxxx/ > > If the virtual EPC is shared by other VMs, the worst case is when other VMs use > this bad EPC page (as we cannot take the bad EPC page out of VM for now), some > SGX error (ENCLS/ENCLU error) or #MC could happen again. But this doesn't make > things worse, as when sharing virtual EPC page among VMs you are likely to break > enclaves in VMs anyway (as mentioned above). Guys, maybe I'm just not being specific enough. But, Kai, you're off on a tangent here that I didn't intend to ask about. You're actually adding confusion and delay here, not helping answer the question. This was specifically a question about fork() plus VEPC plus machine checks. I'm still trying to get to the bottom of: What happens if a hypervisor *DOES* fork()? What's the fallout? Specifically, with this machine check SIGBUS implementation, one EPC page can only have on host virtual address. But, it's possible to mmap() a single VEPC page in multiple processes at multiple host virtual addresses. So, the implementation only allows one host virtual address. But, we can imagine a scenario where there are *TWO* valid virtual addresses where the VEPC is mapped. What might happen in this case? What's the fallout?
