On Fri, Mar 11, 2022 at 09:53:29AM -0800, Reinette Chatre wrote: > I saw Haitao's note that EMODPE requires "Read access permitted by enclave". > This motivates that EMODPR->PROT_NONE should not be allowed since it would > not be possible to relax permissions (run EMODPE) after that. Even so, I > also found in the SDM that EACCEPT has the note "Read access permitted > by enclave". That seems to indicate that EMODPR->PROT_NONE is not practical > from that perspective either since the enclave will not be able to > EACCEPT the change. Does that match your understanding? Yes, PROT_NONE should not be allowed. This is however the real problem. The current kernel patch set has inconsistent API and EMODPR ioctl is simply unacceptable. It also requires more concurrency management from user space run-time, which would be heck a lot easier to do in the kernel. If you really want EMODPR as ioctl, then for consistencys sake, then EAUG should be too. Like this when things go opposite directions, this patch set plain and simply will not work out. I would pick EAUG's strategy from these two as it requires half the back calls to host from an enclave. I.e. please combine mprotect() and EMODPR, either in the #PF handler or as part of mprotect(), which ever suits you best. I'll try demonstrate this with two examples. mmap() could go something like this() (simplified): 1. Execution #UD's to SYSCALL. 2. Host calls enclave's mmap() handler with mmap() parameters. 3. Enclave up-calls host's mmap(). 4. Loops the range with EACCEPTCOPY. mprotect() has to be done like this: 1. Execution #UD's to SYSCALL. 2. Host calls enclave's mprotect() handler. 3. Enclave up-calls host's mprotect(). 4. Enclave up-calls host's ioctl() to SGX_IOC_ENCLAVE_PERMISSIONS. 3. Loops the range with EACCEPT. This is just terrible IMHO. I hope these examples bring some insight. BR, Jarkko
