On Mon, 2021-12-06 at 13:18 -0800, Reinette Chatre wrote: > Hi Jarkko, > > On 12/4/2021 2:43 PM, Jarkko Sakkinen wrote: > > On Wed, Dec 01, 2021 at 11:23:02AM -0800, Reinette Chatre wrote: > > > By default a write page fault on a present PTE inherits the permissions > > > of the VMA. Enclave page permissions maintained in the hardware's > > > Enclave Page Cache Map (EPCM) may change after a VMA accessing the page > > > is created. A VMA's permissions may thus exceed the enclave page > > > permissions even though the VMA was originally created not to exceed > > > the enclave page permissions. Following the default behavior during > > > a page fault on a present PTE while the VMA permissions exceed the > > > enclave page permissions would result in the PTE for an enclave page > > > to be writable even though the page is not writable according to the > > > enclave's permissions. > > > > > > Consider the following scenario: > > > * An enclave page exists with RW EPCM permissions. > > > * A RW VMA maps the range spanning the enclave page. > > > * The enclave page's EPCM permissions are changed to read-only. > > > > How could this happen in the existing mainline code? > > This is a preparatory patch for SGX2 support. Restricting the > permissions of an enclave page would require OS support that is added in > a later patch. > > > > > > * There is no page table entry for the enclave page. > > > > > > Q. > > > What will user space observe when an attempt is made to write to the > > > enclave page from within the enclave? > > > > > > A. > > > Initially the page table entry is not present so the following is > > > observed: > > > 1) Instruction writing to enclave page is run from within the enclave. > > > 2) A page fault with second and third bits set (0x6) is encountered > > > and handled by the SGX handler sgx_vma_fault() that installs a > > > read-only page table entry following previous patch that installs > > > page table entry with permissions that VMA and enclave agree on > > > (read-only in this case). > > > 3) Instruction writing to enclave page is re-attempted. > > > 4) A page fault with first three bits set (0x7) is encountered and > > > transparently (from SGX and user space perspective) handled by the > > > OS with the page table entry made writable because the VMA is > > > writable. > > > 5) Instruction writing to enclave page is re-attempted. > > > 6) Since the EPCM permissions prevents writing to the page a new page > > > fault is encountered, this time with the SGX flag set in the error > > > code (0x8007). No action is taken by OS for this page fault and > > > execution returns to user space. > > > 7) Typically such a fault will be passed on to an application with a > > > signal but if the enclave is entered with the vDSO function provided > > > by the kernel then user space does not receive a signal but instead > > > the vDSO function returns successfully with exception information > > > (vector=14, error code=0x8007, and address) within the exception > > > fields within the vDSO function's struct sgx_enclave_run. > > > > > > As can be observed it is not possible for user space to write to an > > > enclave page if that page's enclave page permissions do not allow so, > > > no matter what the VMA or PTE allows. > > > > > > Even so, the OS should not allow writing to a page if that page is not > > > writable. Thus the page table entry should accurately reflect the > > > enclave page permissions. > > > > > > Do not blindly accept VMA permissions on a page fault due to a write > > > attempt to a present PTE. Install a pfn_mkwrite() handler that ensures > > > that the VMA permissions agree with the enclave permissions in this > > > regard. > > > > > > Considering the same scenario as above after this change results in > > > the following behavior change: > > > > > > Q. > > > What will user space observe when an attempt is made to write to the > > > enclave page from within the enclave? > > > > > > A. > > > Initially the page table entry is not present so the following is > > > observed: > > > 1) Instruction writing to enclave page is run from within the enclave. > > > 2) A page fault with second and third bits set (0x6) is encountered > > > and handled by the SGX handler sgx_vma_fault() that installs a > > > read-only page table entry following previous patch that installs > > > page table entry with permissions that VMA and enclave agree on > > > (read-only in this case). > > > 3) Instruction writing to enclave page is re-attempted. > > > 4) A page fault with first three bits set (0x7) is encountered and > > > passed to the pfn_mkwrite() handler for consideration. The handler > > > determines that the page should not be writable and returns SIGBUS. > > > 5) Typically such a fault will be passed on to an application with a > > > signal but if the enclave is entered with the vDSO function provided > > > by the kernel then user space does not receive a signal but instead > > > the vDSO function returns successfully with exception information > > > (vector=14, error code=0x7, and address) within the exception fields > > > within the vDSO function's struct sgx_enclave_run. > > > > > > The accurate exception information supports the SGX runtime, which is > > > virtually always implemented inside a shared library, by providing > > > accurate information in support of its management of the SGX enclave. > > > > This QA-format is not a great idea, as it kind of tells what are the legit > > questions to ask. > > I will remove the QA-format and just describe the two (before/after) > scenarios. > > > You should describe what the patch does and what are the > > legit reasons for doing that. Unfortunately, in the current form it is very > > hard to get grip of this patch. > > That was the goal of the summary (the first paragraph) at the start of > the changelog. Could you please elaborate how you would like me to > improve it? If I do a search "mktme" through the commit message, it gives me zero results. /Jarkko
