From: Reinette Chatre <reinette.chatre@intel.com>
To: Andy Lutomirski <luto@kernel.org>, <dave.hansen@linux.intel.com>,
<jarkko@kernel.org>, <tglx@linutronix.de>, <bp@alien8.de>,
<mingo@redhat.com>, <linux-sgx@vger.kernel.org>, <x86@kernel.org>
Cc: <seanjc@google.com>, <kai.huang@intel.com>,
<cathy.zhang@intel.com>, <cedric.xing@intel.com>,
<haitao.huang@intel.com>, <mark.shanahan@intel.com>,
<hpa@zytor.com>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 05/25] x86/sgx: Introduce runtime protection bits
Date: Mon, 13 Dec 2021 14:34:05 -0800 [thread overview]
Message-ID: <c091ee8b-04a8-9165-00c1-835bb520e240@intel.com> (raw)
In-Reply-To: <855ab0ac-1e9b-dd3b-63ec-d15d0f0fda77@intel.com>
Hi Andy,
I would like to check in if you had some time to digest my responses
with a few high level questions below ...
On 12/4/2021 3:55 PM, Reinette Chatre wrote:
> On 12/4/2021 9:56 AM, Andy Lutomirski wrote:
>> On 12/3/21 17:14, Reinette Chatre wrote:
>>> On 12/3/2021 4:38 PM, Andy Lutomirski wrote:
>>>> On 12/3/21 14:12, Reinette Chatre wrote:
>>>>> On 12/3/2021 11:28 AM, Andy Lutomirski wrote:
>>>>>> On 12/1/21 11:23, Reinette Chatre wrote:
>>>>>>> Enclave creators declare their paging permission intent at the time
>>>>>>> the pages are added to the enclave. These paging permissions are
>>>>>>> vetted when pages are added to the enclave and stashed off
>>>>>>> (in sgx_encl_page->vm_max_prot_bits) for later comparison with
>>>>>>> enclave PTEs.
>>>>>>>
>>>>>>
>>>>>> I'm a bit confused here. ENCLU[EMODPE] allows the enclave to
>>>>>> change the EPCM permission bits however it likes with no oversight
>>>>>> from the kernel. So we end up with a whole bunch of permission
>>>>>> masks:
>>>>>
>>>>> Before jumping to the permission masks I would like to step back
>>>>> and just confirm the context. We need to consider the following
>>>>> three permissions:
>>>>>
>>>>> EPCM permissions: the enclave page permissions maintained in the
>>>>> SGX hardware. The OS is constrained here in that it cannot query
>>>>> the current EPCM permissions. Even so, the OS needs to ensure PTEs
>>>>> are installed appropriately (we do not want a RW PTE for a
>>>>> read-only enclave page)
>>>>
>>>> Why not? What's wrong with an RW PTE for a read-only enclave page?
>>>>
>>>> If you convince me that this is actually important, then I'll read
>>>> all the stuff below.
>>>
>>> Perhaps it is my misunderstanding/misinterpretation of the current
>>> implementation? From what I understand the current requirement, as
>>> enforced in the current mmap(), mprotect() as well as fault() hooks,
>>> is that mappings are required to have identical or weaker permission
>>> than the enclave permission.
>>
>> The current implementation does require that, but for a perhaps
>> counterintuitive reason. If a SELinux-restricted (or similarly
>> restricted) process that is *not* permitted to do JIT-like things
>> loads an enclave, it's entirely okay for it to initialize RW enclave
>> pages however it likes and it's entirely okay for it to initialize RX
>> (or XO if that ever becomes a thing) enclave pages from appropriately
>> files on disk. But it's not okay for it to create RWX enclave pages
>> or to initialize RX enclave pages from untrusted application memory. [0]
>>
>> So we have a half-baked implementation right now: the permission to
>> execute a page is decided based on secinfo (max permissions) when the
>> enclave is set up, and it's enforced at the PTE level. The PTE
>> enforcement is because, on SGX2 hardware, the enclave can do EMODPE
>> and bypass any supposed restrictions in the EPCM.
>>
>> The only coupling between EPCM and PTE here is that the max_perm is
>> initialized together with EPCM, but it didn't have to be that way.
>>
>> An SGX2 implementation needs to be more fully baked, because in a
>> dynamic environment enclaves need to be able to use EMODPE and
>> actually end up with permissions that exceed the initial secinfo
>> permissions. So
>
> Could you please elaborate why this is a requirement? In this
> implementation the secinfo of a page added before enclave initialization
> (via SGX_IOC_ENCLAVE_ADD_PAGES) would indicate the maximum permissions
> it may have during its lifetime. Pages needing to be writable and
> executable during their lifetime can be created with RWX secinfo and
> during the enclave runtime the pages could obtain all combinations of
> permissions: RWX, R, RW, RX. A page added with RW secinfo may have R or
> RW permissions during its lifetime but never RX or RWX.
>
> So far our inquiries on whether this is acceptable has been positive and
> is also what Dave attempted to put a spotlight on in:
> https://lore.kernel.org/lkml/94d8d631-5345-66c4-52a3-941e52500f84@intel.com/
>
>
> This above is specific to pages added before enclave initialization. In
> this implementation pages added after enclave initialization, those
> needing the ENCLS[EAUG] SGX2 instruction, are added with max permissions
> of RW so could only have R or RW permissions during their lifetime. This
> is an understood limitation and it is understood that integration with
> user policy is required to support these pages obtaining executable
> permission. The plan is to handle user policy integration in a series
> that follows this core SGX2 enabling.
Are you ok with the strategy to support modification of enclave page
permissions?
>
>> it needs to be possible to make a page that starts out R (or RW or
>> whatever) but nonetheless has max_perm=RWX so that the enclave can use
>> a combination of EMODPE and (ioctl-based) EMODPR to do JIT. So I
>> think you should make it possible to set up pages like this, but I see
>> no reason to couple the PTE and the EPCM permissions.
>>
>>>
>>> Could you please elaborate how you envision PTEs should be managed in
>>> this implementation?
>>
>> As above: PTE permissions may not exceed max_perm, and EPCM is
>> entirely separate except to the extent needed for ABI compatibility
>> with SGX1 runtimes.
>
> ok, so if I understand correctly you, since PTE permissions may not
> exceed max_perm and EPCM are separate, this seems to get back to your
> previous question of "What's wrong with an RW PTE for a read-only
> enclave page?"
>
> This is indeed something that we could allow but not doing so (that is
> PTEs not exceeding EPCM permissions) would better support the SGX
> runtime. That is why I separated out the addition of the pfn_mkwrite()
> callback in the previous patch (04/25). Like in your example, there is a
> RW mapping of a read-only enclave page that first results in a RW PTE
> for the read-only enclave page. That would result in a #PF with the SGX
> flag set (0x8007). If the PTE matches the enclave permissions the page
> fault would have familiar 0x7 error code.
>
> In either case user space would encounter a #PF so technically there is
> nothing "wrong" with allowing this - even so, as motivated in the
> previous patch: 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.
Are you ok with managing PTEs in this way? It matches your requirement
that PTE permissions may not exceed max_perm and ABI is compatible with
SGX1. Additionally, PTEs are not allowed to exceed EPCM permissions,
which is not an ABI change since it was not a consideration during SGX1
where EPCM permissions could not change.
>> [0] I'm not sure anyone actually has a system set up like this or that
>> the necessary LSM support is in the kernel. But it's supposed to be
>> possible without changing the ABI.
>>
Thank you very much
Reinette
next prev parent reply other threads:[~2021-12-13 22:34 UTC|newest]
Thread overview: 155+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-01 19:22 [PATCH 00/25] x86/sgx and selftests/sgx: Support SGX2 Reinette Chatre
2021-12-01 19:22 ` [PATCH 01/25] x86/sgx: Add shortlog descriptions to ENCLS wrappers Reinette Chatre
2021-12-04 18:30 ` Jarkko Sakkinen
2021-12-06 21:13 ` Reinette Chatre
2021-12-11 5:28 ` Jarkko Sakkinen
2021-12-13 22:06 ` Reinette Chatre
2021-12-01 19:23 ` [PATCH 02/25] x86/sgx: Add wrappers for SGX2 functions Reinette Chatre
2021-12-04 22:04 ` Jarkko Sakkinen
2021-12-06 21:15 ` Reinette Chatre
2021-12-01 19:23 ` [PATCH 03/25] x86/sgx: Support VMA permissions exceeding enclave permissions Reinette Chatre
2021-12-04 22:25 ` Jarkko Sakkinen
2021-12-04 22:27 ` Jarkko Sakkinen
2021-12-06 21:16 ` Reinette Chatre
2021-12-11 5:39 ` Jarkko Sakkinen
2021-12-13 22:08 ` Reinette Chatre
2021-12-01 19:23 ` [PATCH 04/25] x86/sgx: Add pfn_mkwrite() handler for present PTEs Reinette Chatre
2021-12-04 22:43 ` Jarkko Sakkinen
2021-12-06 21:18 ` Reinette Chatre
2021-12-11 7:37 ` Jarkko Sakkinen
2021-12-13 22:09 ` Reinette Chatre
2021-12-28 14:51 ` Jarkko Sakkinen
2021-12-01 19:23 ` [PATCH 05/25] x86/sgx: Introduce runtime protection bits Reinette Chatre
2021-12-03 19:28 ` Andy Lutomirski
2021-12-03 22:12 ` Reinette Chatre
2021-12-04 0:38 ` Andy Lutomirski
2021-12-04 1:14 ` Reinette Chatre
2021-12-04 17:56 ` Andy Lutomirski
2021-12-04 23:55 ` Reinette Chatre
2021-12-13 22:34 ` Reinette Chatre [this message]
2021-12-04 23:57 ` Jarkko Sakkinen
2021-12-06 21:20 ` Reinette Chatre
2021-12-11 7:42 ` Jarkko Sakkinen
2021-12-13 22:10 ` Reinette Chatre
2021-12-28 14:52 ` Jarkko Sakkinen
2022-01-06 17:46 ` Reinette Chatre
2022-01-07 12:16 ` Jarkko Sakkinen
2022-01-07 16:14 ` Haitao Huang
2022-01-08 15:45 ` Jarkko Sakkinen
2022-01-08 15:51 ` Jarkko Sakkinen
2022-01-08 16:22 ` Jarkko Sakkinen
2022-01-10 22:05 ` Haitao Huang
2022-01-11 1:53 ` Jarkko Sakkinen
2022-01-11 1:55 ` Jarkko Sakkinen
2022-01-11 2:03 ` Jarkko Sakkinen
2022-01-11 2:15 ` Jarkko Sakkinen
2022-01-11 3:48 ` Haitao Huang
2022-01-12 23:48 ` Jarkko Sakkinen
2022-01-13 2:41 ` Haitao Huang
2022-01-14 21:36 ` Jarkko Sakkinen
2022-01-11 17:13 ` Reinette Chatre
2022-01-12 23:50 ` Jarkko Sakkinen
2022-01-12 23:56 ` Jarkko Sakkinen
2022-01-13 20:09 ` Nathaniel McCallum
2022-01-13 21:42 ` Reinette Chatre
2022-01-14 21:53 ` Jarkko Sakkinen
2022-01-14 21:57 ` Jarkko Sakkinen
2022-01-14 22:00 ` Jarkko Sakkinen
2022-01-14 22:17 ` Jarkko Sakkinen
2022-01-14 22:23 ` Jarkko Sakkinen
2022-01-14 22:34 ` Jarkko Sakkinen
2022-01-14 23:05 ` Reinette Chatre
2022-01-14 23:15 ` Jarkko Sakkinen
2022-01-15 0:01 ` Reinette Chatre
2022-01-15 0:27 ` Jarkko Sakkinen
2022-01-15 0:41 ` Reinette Chatre
2022-01-15 1:18 ` Jarkko Sakkinen
2022-01-15 11:56 ` Jarkko Sakkinen
2022-01-15 11:59 ` Jarkko Sakkinen
2022-01-17 13:13 ` Nathaniel McCallum
2022-01-18 1:59 ` Jarkko Sakkinen
2022-01-18 2:22 ` Jarkko Sakkinen
2022-01-18 3:31 ` Jarkko Sakkinen
2022-01-18 20:59 ` Reinette Chatre
2022-01-20 12:53 ` Jarkko Sakkinen
2022-01-20 16:52 ` Reinette Chatre
2022-01-26 14:41 ` Jarkko Sakkinen
2022-01-15 16:49 ` Jarkko Sakkinen
2022-01-18 21:18 ` Reinette Chatre
2022-01-17 13:27 ` Nathaniel McCallum
2022-01-18 21:11 ` Reinette Chatre
2021-12-04 22:50 ` Jarkko Sakkinen
2021-12-06 21:28 ` Reinette Chatre
2021-12-01 19:23 ` [PATCH 06/25] x86/sgx: Use more generic name for enclave cpumask function Reinette Chatre
2021-12-04 22:56 ` Jarkko Sakkinen
2021-12-06 21:29 ` Reinette Chatre
2021-12-01 19:23 ` [PATCH 07/25] x86/sgx: Move PTE zap code to separate function Reinette Chatre
2021-12-04 22:59 ` Jarkko Sakkinen
2021-12-06 21:30 ` Reinette Chatre
2021-12-11 7:52 ` Jarkko Sakkinen
2021-12-13 22:11 ` Reinette Chatre
2021-12-28 14:55 ` Jarkko Sakkinen
2022-01-06 17:46 ` Reinette Chatre
2022-01-07 12:26 ` Jarkko Sakkinen
2021-12-01 19:23 ` [PATCH 08/25] x86/sgx: Make SGX IPI callback available internally Reinette Chatre
2021-12-04 23:00 ` Jarkko Sakkinen
2021-12-06 21:36 ` Reinette Chatre
2021-12-11 7:53 ` Jarkko Sakkinen
2021-12-01 19:23 ` [PATCH 09/25] x86/sgx: Keep record of SGX page type Reinette Chatre
2021-12-04 23:03 ` Jarkko Sakkinen
2021-12-01 19:23 ` [PATCH 10/25] x86/sgx: Support enclave page permission changes Reinette Chatre
2021-12-02 23:48 ` Dave Hansen
2021-12-03 18:18 ` Reinette Chatre
2021-12-03 0:32 ` Dave Hansen
2021-12-03 18:18 ` Reinette Chatre
2021-12-03 18:14 ` Dave Hansen
2021-12-03 18:49 ` Reinette Chatre
2021-12-03 19:38 ` Andy Lutomirski
2021-12-03 22:34 ` Reinette Chatre
2021-12-04 0:42 ` Andy Lutomirski
2021-12-04 1:35 ` Reinette Chatre
2021-12-04 23:08 ` Jarkko Sakkinen
2021-12-06 20:19 ` Dave Hansen
2021-12-11 5:17 ` Jarkko Sakkinen
2021-12-06 21:42 ` Reinette Chatre
2021-12-11 7:57 ` Jarkko Sakkinen
2021-12-13 22:12 ` Reinette Chatre
2021-12-28 14:56 ` Jarkko Sakkinen
2021-12-01 19:23 ` [PATCH 11/25] selftests/sgx: Add test for EPCM " Reinette Chatre
2021-12-01 19:23 ` [PATCH 12/25] selftests/sgx: Add test for TCS page " Reinette Chatre
2021-12-01 19:23 ` [PATCH 13/25] x86/sgx: Support adding of pages to initialized enclave Reinette Chatre
2021-12-03 0:38 ` Dave Hansen
2021-12-03 18:47 ` Reinette Chatre
2021-12-04 23:13 ` Jarkko Sakkinen
2021-12-06 21:44 ` Reinette Chatre
2021-12-11 8:00 ` Jarkko Sakkinen
2021-12-13 22:12 ` Reinette Chatre
2021-12-28 14:57 ` Jarkko Sakkinen
2022-03-01 15:13 ` Jarkko Sakkinen
2022-03-01 17:08 ` Reinette Chatre
2021-12-01 19:23 ` [PATCH 14/25] x86/sgx: Tighten accessible memory range after enclave initialization Reinette Chatre
2021-12-04 23:14 ` Jarkko Sakkinen
2021-12-06 21:45 ` Reinette Chatre
2021-12-11 8:01 ` Jarkko Sakkinen
2021-12-01 19:23 ` [PATCH 15/25] selftests/sgx: Test two different SGX2 EAUG flows Reinette Chatre
2021-12-01 19:23 ` [PATCH 16/25] x86/sgx: Support modifying SGX page type Reinette Chatre
2021-12-04 23:45 ` Jarkko Sakkinen
2021-12-06 21:48 ` Reinette Chatre
2021-12-11 8:02 ` Jarkko Sakkinen
2021-12-13 17:43 ` Dave Hansen
2021-12-21 8:52 ` Jarkko Sakkinen
2021-12-01 19:23 ` [PATCH 17/25] x86/sgx: Support complete page removal Reinette Chatre
2021-12-04 23:45 ` Jarkko Sakkinen
2021-12-06 21:49 ` Reinette Chatre
2021-12-01 19:23 ` [PATCH 18/25] selftests/sgx: Introduce dynamic entry point Reinette Chatre
2021-12-01 19:23 ` [PATCH 19/25] selftests/sgx: Introduce TCS initialization enclave operation Reinette Chatre
2021-12-01 19:23 ` [PATCH 20/25] selftests/sgx: Test complete changing of page type flow Reinette Chatre
2021-12-01 19:23 ` [PATCH 21/25] selftests/sgx: Test faulty enclave behavior Reinette Chatre
2021-12-01 19:23 ` [PATCH 22/25] selftests/sgx: Test invalid access to removed enclave page Reinette Chatre
2021-12-01 19:23 ` [PATCH 23/25] selftests/sgx: Test reclaiming of untouched page Reinette Chatre
2021-12-01 19:23 ` [PATCH 24/25] x86/sgx: Free up EPC pages directly to support large page ranges Reinette Chatre
2021-12-04 23:47 ` Jarkko Sakkinen
2021-12-06 22:07 ` Reinette Chatre
2021-12-01 19:23 ` [PATCH 25/25] selftests/sgx: Page removal stress test Reinette Chatre
2021-12-02 18:30 ` [PATCH 00/25] x86/sgx and selftests/sgx: Support SGX2 Dave Hansen
2021-12-02 20:38 ` Nathaniel McCallum
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c091ee8b-04a8-9165-00c1-835bb520e240@intel.com \
--to=reinette.chatre@intel.com \
--cc=bp@alien8.de \
--cc=cathy.zhang@intel.com \
--cc=cedric.xing@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=haitao.huang@intel.com \
--cc=hpa@zytor.com \
--cc=jarkko@kernel.org \
--cc=kai.huang@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sgx@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mark.shanahan@intel.com \
--cc=mingo@redhat.com \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).