From: Jarkko Sakkinen <jarkko@kernel.org>
To: Haitao Huang <haitao.huang@linux.intel.com>
Cc: Reinette Chatre <reinette.chatre@intel.com>,
"Dhanraj, Vijay" <vijay.dhanraj@intel.com>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"tglx@linutronix.de" <tglx@linutronix.de>,
"bp@alien8.de" <bp@alien8.de>,
"Lutomirski, Andy" <luto@kernel.org>,
"mingo@redhat.com" <mingo@redhat.com>,
"linux-sgx@vger.kernel.org" <linux-sgx@vger.kernel.org>,
"x86@kernel.org" <x86@kernel.org>, "Christopherson,,
Sean" <seanjc@google.com>, "Huang, Kai" <kai.huang@intel.com>,
"Zhang, Cathy" <cathy.zhang@intel.com>,
"Xing, Cedric" <cedric.xing@intel.com>,
"Huang, Haitao" <haitao.huang@intel.com>,
"Shanahan, Mark" <mark.shanahan@intel.com>,
"hpa@zytor.com" <hpa@zytor.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
nathaniel@profian.com
Subject: Re: [PATCH V2 16/32] x86/sgx: Support restricting of enclave page permissions
Date: Fri, 18 Mar 2022 00:00:17 +0200 [thread overview]
Message-ID: <YjOvcbdM+YmYw37c@iki.fi> (raw)
In-Reply-To: <YjOtLp4f4nu18Fzx@iki.fi>
On Thu, Mar 17, 2022 at 11:50:41PM +0200, Jarkko Sakkinen wrote:
> On Thu, Mar 17, 2022 at 09:28:45AM -0500, Haitao Huang wrote:
> > Hi
> >
> > On Thu, 17 Mar 2022 02:11:28 -0500, Jarkko Sakkinen <jarkko@kernel.org>
> > wrote:
> >
> > > On Thu, Mar 17, 2022 at 09:01:07AM +0200, Jarkko Sakkinen wrote:
> > > > On Mon, Mar 14, 2022 at 10:39:36AM -0500, Haitao Huang wrote:
> > > > > Hi Jarkko
> > > > >
> > > > > On Sun, 13 Mar 2022 21:58:51 -0500, Jarkko Sakkinen
> > > > <jarkko@kernel.org>
> > > > > wrote:
> > > > >
> > > > > > On Mon, Mar 14, 2022 at 04:50:56AM +0200, Jarkko Sakkinen wrote:
> > > > > > > On Mon, Mar 14, 2022 at 04:49:37AM +0200, Jarkko Sakkinen wrote:
> > > > > > > > On Fri, Mar 11, 2022 at 09:53:29AM -0800, Reinette Chatre wrote:
> > > > > > > >
> > > > > > > > > I saw Haitao's note that EMODPE requires "Read access
> > > > permitted
> > > > > > > by enclave".
> > > > > > > > > This motivates that EMODPR->PROT_NONE should not be allowed
> > > > > > > since it would
> > > > > > > > > not be possible to relax permissions (run EMODPE) after that.
> > > > > > > Even so, I
> > > > > > > > > also found in the SDM that EACCEPT has the note "Read access
> > > > > > > permitted
> > > > > > > > > by enclave". That seems to indicate that EMODPR->PROT_NONE is
> > > > > > > not practical
> > > > > > > > > from that perspective either since the enclave will not be
> > > > able to
> > > > > > > > > EACCEPT the change. Does that match your understanding?
> > > > > > > >
> > > > > > > > Yes, PROT_NONE should not be allowed.
> > > > > > > >
> > > > > > > > This is however the real problem.
> > > > > > > >
> > > > > > > > The current kernel patch set has inconsistent API and EMODPR
> > > > ioctl is
> > > > > > > > simply unacceptable. It also requires more concurrency
> > > > management
> > > > > > > from
> > > > > > > > user space run-time, which would be heck a lot easier to do
> > > > in the
> > > > > > > kernel.
> > > > > > > >
> > > > > > > > If you really want EMODPR as ioctl, then for consistencys sake,
> > > > > > > then EAUG
> > > > > > > > should be too. Like this when things go opposite directions,
> > > > this
> > > > > > > patch set
> > > > > > > > plain and simply will not work out.
> > > > > > > >
> > > > > > > > I would pick EAUG's strategy from these two as it requires half
> > > > > > > the back
> > > > > > > > calls to host from an enclave. I.e. please combine
> > > > mprotect() and
> > > > > > > EMODPR,
> > > > > > > > either in the #PF handler or as part of mprotect(), which ever
> > > > > > > suits you
> > > > > > > > best.
> > > > > > > >
> > > > > > > > I'll try demonstrate this with two examples.
> > > > > > > >
> > > > > > > > mmap() could go something like this() (simplified):
> > > > > > > > 1. Execution #UD's to SYSCALL.
> > > > > > > > 2. Host calls enclave's mmap() handler with mmap() parameters.
> > > > > > > > 3. Enclave up-calls host's mmap().
> > > > > > > > 4. Loops the range with EACCEPTCOPY.
> > > > > > > >
> > > > > > > > mprotect() has to be done like this:
> > > > > > > > 1. Execution #UD's to SYSCALL.
> > > > > > > > 2. Host calls enclave's mprotect() handler.
> > > > > > > > 3. Enclave up-calls host's mprotect().
> > > > > > > > 4. Enclave up-calls host's ioctl() to
> > > > SGX_IOC_ENCLAVE_PERMISSIONS.
> > > > >
> > > > > I assume up-calls here are ocalls as we call them in our
> > > > implementation,
> > > > > which are the calls enclave make to untrusted side via EEXIT.
> > > > >ar
> > > > > If so, can your implementation combine this two up-calls into one,
> > > > then host
> > > > > side just do ioctl() and mprotect to kernel? If so, would that
> > > > address your
> > > > > concern about extra up-calls?
> > > > >
> > > > >
> > > > > > > > 3. Loops the range with EACCEPT.
> > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > > > > > > 5. Loops the range with EACCEPT + EMODPE.
> > > > > > >
> > > > > > > > This is just terrible IMHO. I hope these examples bring some
> > > > insight.
> > > > > >
> > > > > > E.g. in Enarx we have to add a special up-call (so called
> > > > enarxcall in
> > > > > > intermediate that we call sallyport, which provides shared buffer to
> > > > > > communicate with the enclave) just for reseting the range with
> > > > PROT_READ.
> > > > > > Feel very redundant, adds ugly cruft and is completely opposite
> > > > strategy
> > > > > > to
> > > > > > what you've chosen to do with EAUG, which is I think correct
> > > > choice as
> > > > > > far
> > > > > > as API is concerned.
> > > > >
> > > > > The problem with EMODPR on #PF is that kernel needs to know what
> > > > permissions
> > > > > requested from enclave at the time of #PF. So enclave has to make
> > > > at least
> > > > > one call to kernel (again via ocall in our case, I assume up-call
> > > > in your
> > > > > case) to make the change.
> > > >
> > > > The #PF handler should do unconditionally EMODPR with PROT_READ.
> > >
> > > Or mprotect(), as long as secinfo contains PROT_READ. I don't care about
> > > this detail hugely anymore because it does not affect uapi.
> > >
> > > Using EMODPR as a permission control mechanism is a ridiculous idea, and
> > > I cannot commit to maintain a broken uapi.
> > >
> >
> > Jarkko, how would automatically forcing PROT_READ on #PF work for this
> > sequence?
> >
> > 1) EAUG a page (has to be RW)
> > 2) EACCEPT(RW)
> > 3) enclave copies some data to page
> > 4) enclave wants to change permission to R
> >
> > If you are proposing mprotect, then as I indicated earlier, please address
> > concerns raised by Reinette:
> > https://lore.kernel.org/linux-sgx/e1c04077-0165-c5ec-53be-7fd732965e80@intel.com/
>
> For EAUG you can choose between #PF handler and having it as part of
> mmap() with the same uapi.
>
> For EMODPR clearly #PF handler would be tricky but nothing prevents
> resetting the permissions as part of mprotect() flow, which is trivial.
>
> One good reason to have a fixed EMODPR is that e.g. emulating properly
> mprotect() is almost undoable if you don't do it otherwise. Specifically
s/don't//g
> the scenario where your address range spans through multiple adjacent
> VMAs. It's even without EMODPR complex enough scenario that you really
> don't want to ask yourself for more trouble than use EMODPR in a super
> conservative manner.
>
> Having EMODPR fully exposed will only make more difficult API to do with
> extra round-trips. If you want to use ring-0 instructions fully exposed,
> please don't use a kernel. There's a bunch of hardware features in Intel
> CPUs for which Linux does not provide 1:1 all wide open interfaces.
>
> BR, Jarkko
next prev parent reply other threads:[~2022-03-17 22:01 UTC|newest]
Thread overview: 130+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-08 0:45 [PATCH V2 00/32] x86/sgx and selftests/sgx: Support SGX2 Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 01/32] x86/sgx: Add short descriptions to ENCLS wrappers Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 02/32] x86/sgx: Add wrapper for SGX2 EMODPR function Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 03/32] x86/sgx: Add wrapper for SGX2 EMODT function Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 04/32] x86/sgx: Add wrapper for SGX2 EAUG function Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 05/32] Documentation/x86: Document SGX permission details Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 06/32] x86/sgx: Support VMA permissions more relaxed than enclave permissions Reinette Chatre
2022-03-07 17:10 ` Jarkko Sakkinen
2022-03-07 17:36 ` Reinette Chatre
2022-03-08 8:14 ` Jarkko Sakkinen
2022-03-08 9:06 ` Jarkko Sakkinen
2022-03-08 9:12 ` Jarkko Sakkinen
2022-03-08 16:04 ` Reinette Chatre
2022-03-08 17:00 ` Jarkko Sakkinen
2022-03-08 17:49 ` Reinette Chatre
2022-03-08 18:46 ` Jarkko Sakkinen
2022-03-11 11:06 ` Dr. Greg
2022-02-08 0:45 ` [PATCH V2 07/32] x86/sgx: Add pfn_mkwrite() handler for present PTEs Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 08/32] x86/sgx: x86/sgx: Add sgx_encl_page->vm_run_prot_bits for dynamic permission changes Reinette Chatre
2022-03-04 8:55 ` Jarkko Sakkinen
2022-03-04 19:19 ` Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 09/32] x86/sgx: Export sgx_encl_ewb_cpumask() Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 10/32] x86/sgx: Rename sgx_encl_ewb_cpumask() as sgx_encl_cpumask() Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 11/32] x86/sgx: Move PTE zap code to new sgx_zap_enclave_ptes() Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 12/32] x86/sgx: Make sgx_ipi_cb() available internally Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 13/32] x86/sgx: Create utility to validate user provided offset and length Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 14/32] x86/sgx: Keep record of SGX page type Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 15/32] x86/sgx: Support relaxing of enclave page permissions Reinette Chatre
2022-03-04 8:59 ` Jarkko Sakkinen
2022-02-08 0:45 ` [PATCH V2 16/32] x86/sgx: Support restricting " Reinette Chatre
2022-02-21 0:49 ` Jarkko Sakkinen
2022-02-22 18:35 ` Reinette Chatre
2022-02-23 15:46 ` Jarkko Sakkinen
2022-02-23 19:55 ` Reinette Chatre
2022-02-28 12:27 ` Jarkko Sakkinen
2022-02-23 19:21 ` Dhanraj, Vijay
2022-02-23 22:42 ` Reinette Chatre
2022-02-28 12:24 ` Jarkko Sakkinen
2022-02-28 13:19 ` Jarkko Sakkinen
2022-02-28 15:16 ` Dave Hansen
2022-02-28 17:44 ` Dhanraj, Vijay
2022-03-01 13:26 ` Jarkko Sakkinen
2022-03-01 13:42 ` Jarkko Sakkinen
2022-03-01 17:48 ` Reinette Chatre
2022-03-02 2:05 ` Jarkko Sakkinen
2022-03-02 2:11 ` Jarkko Sakkinen
2022-03-02 4:03 ` Jarkko Sakkinen
2022-03-02 22:57 ` Reinette Chatre
2022-03-03 16:08 ` Haitao Huang
2022-03-03 21:23 ` Reinette Chatre
2022-03-03 21:44 ` Dave Hansen
2022-03-05 3:19 ` Jarkko Sakkinen
2022-03-06 0:15 ` Jarkko Sakkinen
2022-03-06 0:25 ` Jarkko Sakkinen
2022-03-10 5:43 ` Jarkko Sakkinen
2022-03-10 5:59 ` Jarkko Sakkinen
2022-03-03 23:18 ` Jarkko Sakkinen
2022-03-04 4:03 ` Haitao Huang
2022-03-04 8:30 ` Jarkko Sakkinen
2022-03-04 15:51 ` Haitao Huang
2022-03-05 1:02 ` Jarkko Sakkinen
2022-03-06 14:24 ` Haitao Huang
2022-03-03 23:12 ` Jarkko Sakkinen
2022-03-04 0:48 ` Reinette Chatre
2022-03-10 6:10 ` Jarkko Sakkinen
2022-03-10 18:33 ` Haitao Huang
2022-03-11 12:10 ` Jarkko Sakkinen
2022-03-11 12:16 ` Jarkko Sakkinen
2022-03-11 12:33 ` Jarkko Sakkinen
2022-03-11 17:53 ` Reinette Chatre
2022-03-11 18:11 ` Jarkko Sakkinen
2022-03-11 19:28 ` Reinette Chatre
2022-03-14 3:42 ` Jarkko Sakkinen
2022-03-14 3:45 ` Jarkko Sakkinen
2022-03-14 3:54 ` Jarkko Sakkinen
2022-03-14 15:32 ` Reinette Chatre
2022-03-17 4:30 ` Jarkko Sakkinen
2022-03-17 22:08 ` Reinette Chatre
2022-03-17 22:51 ` Jarkko Sakkinen
2022-03-18 0:11 ` Reinette Chatre
2022-03-20 0:24 ` Jarkko Sakkinen
2022-03-28 23:22 ` Reinette Chatre
2022-03-30 15:00 ` Jarkko Sakkinen
2022-03-30 15:02 ` Jarkko Sakkinen
2022-03-14 2:49 ` Jarkko Sakkinen
2022-03-14 2:50 ` Jarkko Sakkinen
2022-03-14 2:58 ` Jarkko Sakkinen
2022-03-14 15:39 ` Haitao Huang
2022-03-17 4:34 ` Jarkko Sakkinen
2022-03-17 14:42 ` Haitao Huang
2022-03-17 4:37 ` Jarkko Sakkinen
2022-03-17 14:47 ` Haitao Huang
2022-03-17 7:01 ` Jarkko Sakkinen
2022-03-17 7:11 ` Jarkko Sakkinen
2022-03-17 14:28 ` Haitao Huang
2022-03-17 21:50 ` Jarkko Sakkinen
2022-03-17 22:00 ` Jarkko Sakkinen [this message]
2022-03-17 22:23 ` Jarkko Sakkinen
2022-02-08 0:45 ` [PATCH V2 17/32] selftests/sgx: Add test for EPCM permission changes Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 18/32] selftests/sgx: Add test for TCS page " Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 19/32] x86/sgx: Support adding of pages to an initialized enclave Reinette Chatre
2022-02-19 11:57 ` Jarkko Sakkinen
2022-02-19 12:01 ` Jarkko Sakkinen
2022-02-20 18:40 ` Jarkko Sakkinen
2022-02-22 19:19 ` Reinette Chatre
2022-02-23 15:46 ` Jarkko Sakkinen
2022-03-07 16:16 ` Jarkko Sakkinen
2022-02-08 0:45 ` [PATCH V2 20/32] x86/sgx: Tighten accessible memory range after enclave initialization Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 21/32] selftests/sgx: Test two different SGX2 EAUG flows Reinette Chatre
2022-03-07 16:39 ` Jarkko Sakkinen
2022-02-08 0:45 ` [PATCH V2 22/32] x86/sgx: Support modifying SGX page type Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 23/32] x86/sgx: Support complete page removal Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 24/32] Documentation/x86: Introduce enclave runtime management section Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 25/32] selftests/sgx: Introduce dynamic entry point Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 26/32] selftests/sgx: Introduce TCS initialization enclave operation Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 27/32] selftests/sgx: Test complete changing of page type flow Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 28/32] selftests/sgx: Test faulty enclave behavior Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 29/32] selftests/sgx: Test invalid access to removed enclave page Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 30/32] selftests/sgx: Test reclaiming of untouched page Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 31/32] x86/sgx: Free up EPC pages directly to support large page ranges Reinette Chatre
2022-02-08 0:45 ` [PATCH V2 32/32] selftests/sgx: Page removal stress test Reinette Chatre
2022-02-22 20:27 ` [PATCH V2 00/32] x86/sgx and selftests/sgx: Support SGX2 Nathaniel McCallum
2022-02-22 22:39 ` Reinette Chatre
2022-02-23 13:24 ` Nathaniel McCallum
2022-02-23 18:25 ` Reinette Chatre
2022-03-02 16:57 ` Nathaniel McCallum
2022-03-02 21:20 ` Reinette Chatre
2022-03-03 1:13 ` Nathaniel McCallum
2022-03-03 17:49 ` Reinette Chatre
2022-03-04 0:57 ` Jarkko Sakkinen
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=YjOvcbdM+YmYw37c@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=vijay.dhanraj@intel.com \
--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).