From: Jarkko Sakkinen <jarkko@kernel.org>
To: Reinette Chatre <reinette.chatre@intel.com>
Cc: Nathaniel McCallum <nathaniel@profian.com>,
Haitao Huang <haitao.huang@linux.intel.com>,
Andy Lutomirski <luto@kernel.org>,
dave.hansen@linux.intel.com, tglx@linutronix.de, bp@alien8.de,
mingo@redhat.com, linux-sgx@vger.kernel.org, x86@kernel.org,
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: Sat, 15 Jan 2022 00:17:03 +0200 [thread overview]
Message-ID: <YeH2Xwn/8RJdicsi@iki.fi> (raw)
In-Reply-To: <YeHwzwnfsUcxiNbw@iki.fi>
On Fri, Jan 14, 2022 at 11:53:22PM +0200, Jarkko Sakkinen wrote:
> On Thu, Jan 13, 2022 at 01:42:50PM -0800, Reinette Chatre wrote:
> > Hi Jarkko and Nathaniel,
> >
> > On 1/13/2022 12:09 PM, Nathaniel McCallum wrote:
> > > On Wed, Jan 12, 2022 at 6:56 PM Jarkko Sakkinen <jarkko@kernel.org> wrote:
> > >>
> > >> On Thu, Jan 13, 2022 at 01:50:13AM +0200, Jarkko Sakkinen wrote:
> > >>> On Tue, Jan 11, 2022 at 09:13:27AM -0800, Reinette Chatre wrote:
> > >>>> Hi Jarkko,
> > >>>>
> > >>>> On 1/10/2022 5:53 PM, Jarkko Sakkinen wrote:
> > >>>>> On Mon, Jan 10, 2022 at 04:05:21PM -0600, Haitao Huang wrote:
> > >>>>>> On Sat, 08 Jan 2022 10:22:30 -0600, Jarkko Sakkinen <jarkko@kernel.org>
> > >>>>>> wrote:
> > >>>>>>
> > >>>>>>> On Sat, Jan 08, 2022 at 05:51:46PM +0200, Jarkko Sakkinen wrote:
> > >>>>>>>> On Sat, Jan 08, 2022 at 05:45:44PM +0200, Jarkko Sakkinen wrote:
> > >>>>>>>>> On Fri, Jan 07, 2022 at 10:14:29AM -0600, Haitao Huang wrote:
> > >>>>>>>>>>>>> OK, so the question is: do we need both or would a
> > >>>>>>>> mechanism just
> > >>>>>>>>>>>> to extend
> > >>>>>>>>>>>>> permissions be sufficient?
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> I do believe that we need both in order to support pages
> > >>>>>>>> having only
> > >>>>>>>>>>>> the permissions required to support their intended use
> > >>>>>>>> during the
> > >>>>>>>>>>>> time the
> > >>>>>>>>>>>> particular access is required. While technically it is
> > >>>>>>>> possible to grant
> > >>>>>>>>>>>> pages all permissions they may need during their lifetime it
> > >>>>>>>> is safer to
> > >>>>>>>>>>>> remove permissions when no longer required.
> > >>>>>>>>>>>
> > >>>>>>>>>>> So if we imagine a run-time: how EMODPR would be useful, and
> > >>>>>>>> how using it
> > >>>>>>>>>>> would make things safer?
> > >>>>>>>>>>>
> > >>>>>>>>>> In scenarios of JIT compilers, once code is generated into RW pages,
> > >>>>>>>>>> modifying both PTE and EPCM permissions to RX would be a good
> > >>>>>>>> defensive
> > >>>>>>>>>> measure. In that case, EMODPR is useful.
> > >>>>>>>>>
> > >>>>>>>>> What is the exact threat we are talking about?
> > >>>>>>>>
> > >>>>>>>> To add: it should be *significantly* critical thread, given that not
> > >>>>>>>> supporting only EAUG would leave us only one complex call pattern with
> > >>>>>>>> EACCEPT involvement.
> > >>>>>>>>
> > >>>>>>>> I'd even go to suggest to leave EMODPR out of the patch set, and
> > >>>>>>>> introduce
> > >>>>>>>> it when there is PoC code for any of the existing run-time that
> > >>>>>>>> demonstrates the demand for it. Right now this way too speculative.
> > >>>>>>>>
> > >>>>>>>> Supporting EMODPE is IMHO by factors more critical.
> > >>>>>>>
> > >>>>>>> At least it does not protected against enclave code because an enclave
> > >>>>>>> can
> > >>>>>>> always choose not to EACCEPT any of the EMODPR requests. I'm not only
> > >>>>>>> confused here about the actual threat but also the potential adversary
> > >>>>>>> and
> > >>>>>>> target.
> > >>>>>>>
> > >>>>>> I'm not sure I follow your thoughts here. The sequence should be for enclave
> > >>>>>> to request EMODPR in the first place through runtime to kernel, then to
> > >>>>>> verify with EACCEPT that the OS indeed has done EMODPR.
> > >>>>>> If enclave does not verify with EACCEPT, then its own code has
> > >>>>>> vulnerability. But this does not justify OS not providing the mechanism to
> > >>>>>> request EMODPR.
> > >>>>>
> > >>>>> The question is really simple: what is the threat scenario? In order to use
> > >>>>> the word "vulnerability", you would need one.
> > >>>>>
> > >>>>> Given the complexity of the whole dance with EMODPR it is mandatory to have
> > >>>>> one, in order to ack it to the mainline.
> > >>>>>
> > >>>>
> > >>>> Which complexity related to EMODPR are you concerned about? In a later message
> > >>>> you mention "This leaves only EAUG and EMODT requiring the EACCEPT handshake"
> > >>>> so it seems that you are perhaps concerned about the flow involving EACCEPT?
> > >>>> The OS does not require nor depend on EACCEPT being called as part of these flows
> > >>>> so a faulty or misbehaving user space omitting an EACCEPT call would not impact
> > >>>> these flows in the OS, but would of course impact the enclave.
> > >>>
> > >>> I'd say *any* complexity because I see no benefit of supporting it. E.g.
> > >>> EMODPR/EACCEPT/EMODPE sequence I mentioned to Haitao concerns me. How is
> > >>> EMODPR going to help with any sort of workload?
> > >>
> > >> I've even started think should we just always allow mmap()?
> > >
> > > I suspect this may be the most ergonomic way forward. Instructions
> > > like EAUG/EMODPR/etc are really irrelevant implementation details to
> > > what the enclave wants, which is a memory mapping in the enclave. Why
> > > make the enclave runner do multiple context switches just to change
> > > the memory map of an enclave?
> >
> > The enclave runner is not forced to make any changes to a memory mapping. To start,
> > this implementation supports and does not change the existing ABI where a new
> > memory mapping can only be created if its permissions are the same or weaker
> > than the EPCM permissions. After the memory mapping is created the EPCM permissions
> > can change (thanks to SGX2) and when they do there are no forced nor required
> > changes to the memory mapping - pages remain accessible where the memory mapping
> > and EPCM permissions agree. It is true that if an enclave chooses to relax permissions
> > to an enclave page (EMODPE) then the memory mapping may need to be changed as
> > should be expected to access a page with permissions that the memory mapping
> > did not previously allow.
> >
> > Are you saying that the permissions of a new memory mapping should now be allowed
> > to exceed EPCM permissions and thus the enclave runner would not need to modify a
> > memory mapping when EPCM permissions are relaxed? As mentioned above this may be
> > considered a change in ABI but something we could support on SGX2 systems.
> >
> > I would also like to highlight Haitao's earlier comment that a foundation of SGX is
> > that the OS is untrusted. The enclave owner does not trust the OS and needs EMODPR
> > and EMODPE to manage enclave page permissions.
>
> Thanks, this was very informative response. I'll try to elaborate why
> EMODPR gives me headaches.
>
> I'm having hard time to connect the dots between OS mistrust and
> restricting enclave by changing EPCM permissions. To make EMODPR actually
> legit, it needs really at least some sort of example of a scenario where
> mistrusted OS is the adversary and enclave is the attack target. Otherwise,
> we are just waving our hands.
>
> Generally speaking a restriction is not a restriction if cannot be enforced.
>
> I see two non-EMODPR options: you could relax this, *or* you could make it
> soft restriction by not doing EMODPR but instead just updating the internal
> xarray. The 2nd option would be fully backwards compatible with the
> existing invariant.
>
> It's really hard to ACK or NAK EMODPR patch without knowing how EMODPE is
> or will be supported.
I think I *might* have a supporting scenario for EMODPR.
Enclave might want to accept EMODPR request because a bug in functionality
triggered with TCS entries might allow otherwise to rewrite enclave data,
i.e. provide a write primitive outside the enclave. With some other way to
exploit you could have a read primitive and thus have a full access to the
internal data of the enclave.
/Jarkko
next prev parent reply other threads:[~2022-01-14 22:17 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
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 [this message]
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=YeH2Xwn/8RJdicsi@iki.fi \
--to=jarkko@kernel.org \
--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=haitao.huang@linux.intel.com \
--cc=hpa@zytor.com \
--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=nathaniel@profian.com \
--cc=reinette.chatre@intel.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).