On Fri, Mar 04, 2022 at 11:09:36AM -0800, Reinette Chatre wrote: > 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. The only permissions kernel has real control is PTE permissions when the enclave has been initialized. You are introducing an artificial limitation with vm_run_prot_bits that makes e.g. EMODPE more costly for no good reason, and in-kernel variable has nothing to do with the permissions. They are located in EPCM. > Supporting the modification of permissions after initialization enables > the security conscious enclave owner to support the security > principle of least privilege. 1. Kernel has the control of PTE permissions. 2. Enclave has the control of EPCM permissions. vm_run_prot_bits does not help making anything more secure. BR, Jarkko
