lkml.org 
[lkml]   [2021]   [Dec]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH 04/25] x86/sgx: Add pfn_mkwrite() handler for present PTEs
From
Hi Jarkko,

On 12/10/2021 11:37 PM, Jarkko Sakkinen wrote:
> 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.

Could you please elaborate why you expect "mktme" to show up in the
commit message?

Reinette

\
 
 \ /
  Last update: 2021-12-13 23:10    [W:0.207 / U:0.304 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site