Hi Jarkko, On 3/3/2022 7:39 PM, Jarkko Sakkinen wrote: > Pre-initialization policy is meant for EADD'd pages because they are > part of the enclave identity. It's a good practice to not let touch the > permissions after initialization, and does provide guarantees to e.g. > LSM's about the enclave. I disagree. There are scenarios where it is indeed good practice to modify the permissions after initialization. For example, pages that may be used for relocatable code can start with RWX permissions but once the pages have been populated with the code they should be able to restrict permissions to RX only. It is not good practice to require RWX permission over their entire lifetime. Ideally pages should only have the lowest permissions possible. Supporting the modification of permissions after initialization enables the security conscious enclave owner to support the security principle of least privilege. > > For EAUG'd pages it should be sufficient to let mmap(), mprotect() and > SGX opcodes to control the permissions. Thus effectively disable > pre-initialization policy by setting vm_max_prot_bits to RWX. Setting vm_max_prot_bits of EAUG pages to RWX results in dynamically added (RW) pages to allow RWX PTEs! Please correct me if I am wrong but I do not see how mmap() and mprotect() will control permissions here. Will these flows be able to prevent a RWX mapping of dynamically added RW EPCM pages? From what I understand SGX controls the permissions here with sgx_encl_may_map() called during mmap() and mprotect() and it will allow such mappings after this patch. RWX mapping (VMA) with RWX PTEs of RW EPCM memory will be allowed, correct? That means, an enclave using EAUG to expand its heap will have enclave pages with RW EPCM but yet could have RWX PTEs pointing to them after the user creates a RWX mmap().
