Hi Jarkko, On 1/14/2022 3:15 PM, Jarkko Sakkinen wrote: > On Fri, Jan 14, 2022 at 03:05:21PM -0800, Reinette Chatre wrote: >> Hi Jarkko, > > How enclave can check a page range that EPCM has the expected permissions? Only way to change EPCM permissions from outside enclave is to run ENCLS[EMODPR] that needs to be accepted from within the enclave via ENCLU[EACCEPT]. At that time the enclave provides the expected permissions and that will fail if there is a mismatch with the EPCM permissions (SGX_PAGE_ATTRIBUTES_MISMATCH). > > I'd expect OS mistrusting enclave to do such check at the start of TCS. > > Otherwise, it cannot be sure whether EMODPR was ever requested, and thus > it plays zero part in the game. The EPCM would always have a PR bit set after EMODPR was requested. > > You would get equivalent level of security by just modifying the xarray, > and not doing EMODPR. The xarray is an internal SGX driver structure that can guide how the OS manages page permissions (via VMA permissions or PTEs). This brings us back to the fact that the OS is not trusted and a malicious OS may install PTEs that allow full access to enclave pages and that is why the enclave needs/wants to control its own permissions via the EPCM permissions that are managed with the ENCLS[EMODPR] and ENCLU[EMODPE] instructions. >>> It's really hard to ACK or NAK EMODPR patch without knowing how EMODPE is >>> or will be supported. >> >> EMODPE is currently supported and you can see an example of its use >> in the testing code that forms part of this series. Please see >> "[PATCH 11/25] selftests/sgx: Add test for EPCM permission changes" where you >> will find support for calling ENCLU[EMODPE] added to the test enclave and the >> "epcm_permissions" test making use of it. >> >> After running ENCLU[EMODPE] user space uses SGX_IOC_ENCLAVE_MOD_PROTECTIONS > > OK, great. > > A minor nit: please call it SGX_IOC_ENCLAVE_MODIFY_PROTECTIONS. Sure. (btw ... I was following guidance from: https://lore.kernel.org/lkml/Yav0%2F3jeJsuT3yEq@xxxxxx/ ). Reinette
