On 10/13/22 07:40, Zhiquan Li wrote: >>>> What happens if a hypervisor *DOES* fork()? What's the fallout? >>> This part originates from below discussion: >>> >>> https://lore.kernel.org/linux-sgx/52dc7f50b68c99cecb9e1c3383d9c6d88734cd67.camel@xxxxxxxxx/#t >>> >>> It intents to answer the question: >>> >>> Do you think the processes sharing the same enclave need to be >>> killed, even they had not touched the EPC page with hardware error? >>> >>> Dave, do you mean it's not appropriate to be put here? >> It's actually a pretty important point, but it's still out of the blue. >> >> You also didn't answer my question. > Oh, sorry, I focused on answering "Why is this here?" but forgot to > answer "What's the fallout?" > > It's a very good question. > > Looks like Kai had answered it before: > > For instance, an application can open /dev/sgx_vepc, mmap(), and > fork(). Then if the child does mmap() against the fd opened by > the parent, the child will share the same vepc with the parent. > > ... > > Sharing virtual EPC instance will very likely unexpectedly break > enclaves in all VMs. How, though? This basically says, "I think things will break." I want to know a few more specifics than that before we merge this. There are ABI implications. > https://lore.kernel.org/linux-sgx/52dc7f50b68c99cecb9e1c3383d9c6d88734cd67.camel@xxxxxxxxx/#t > > Moreover, I checked the code in below scenario while child sharing the > virtual EPC instance with parent: > - child closes /dev/sgx_vepc earlier than parent. > - child re-mmap() /dev/sgx_vepc to the same memory region as parent. > - child mmap() /dev/sgx_vepc to different memory region. > - child accesses the memory region of mmap() inherited from parent. > > It's just that the app messes itself up, the vepc instance is protected > very well. > Maybe there are other corner cases I've not considered? ... and what happens when *THIS* patch is in play? What if there is a machine check in SGX memory?
