From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Cc: Andy Lutomirski <luto@kernel.org>,
Cedric Xing <cedric.xing@intel.com>,
Stephen Smalley <sds@tycho.nsa.gov>,
James Morris <jmorris@namei.org>,
"Serge E . Hallyn" <serge@hallyn.com>,
LSM List <linux-security-module@vger.kernel.org>,
Paul Moore <paul@paul-moore.com>,
Eric Paris <eparis@parisplace.org>,
selinux@vger.kernel.org, Jethro Beekman <jethro@fortanix.com>,
Dave Hansen <dave.hansen@intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Linus Torvalds <torvalds@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>, X86 ML <x86@kernel.org>,
linux-sgx@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
nhorman@redhat.com, npmccallum@redhat.com,
Serge Ayoun <serge.ayoun@intel.com>,
Shay Katz-zamir <shay.katz-zamir@intel.com>,
Haitao Huang <haitao.huang@intel.com>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Kai Svahn <kai.svahn@intel.com>, Borislav Petkov <bp@alien8.de>,
Josh Triplett <josh@joshtriplett.org>,
Kai Huang <kai.huang@intel.com>,
David Rientjes <rientjes@google.com>,
William Roberts <william.c.roberts@intel.com>,
Philip Tricca <philip.b.tricca@intel.com>
Subject: Re: [RFC PATCH v2 2/5] x86/sgx: Require userspace to define enclave pages' protection bits
Date: Mon, 10 Jun 2019 09:15:33 -0700 [thread overview]
Message-ID: <20190610161532.GC15995@linux.intel.com> (raw)
In-Reply-To: <20190610152717.GB3752@linux.intel.com>
On Mon, Jun 10, 2019 at 06:27:17PM +0300, Jarkko Sakkinen wrote:
> On Wed, Jun 05, 2019 at 07:11:42PM -0700, Sean Christopherson wrote:
> > [SNAP]
>
> Same general criticism as for the previous patch: try to say things as
> they are without anything extra.
>
> > A third alternative would be to pull the protection bits from the page's
> > SECINFO, i.e. make decisions based on the protections enforced by
> > hardware. However, with SGX2, userspace can extend the hardware-
> > enforced protections via ENCLU[EMODPE], e.g. can add a page as RW and
> > later convert it to RX. With SGX2, making a decision based on the
> > initial protections would either create a security hole or force SGX to
> > dynamically track "dirty" pages (see first alternative above).
> >
> > Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com>
>
> 'flags' should would renamed as 'secinfo_flags_mask' even if the name is
> longish. It would use the same values as the SECINFO flags. The field in
> struct sgx_encl_page should have the same name. That would express
> exactly relation between SECINFO and the new field. I would have never
> asked on last iteration why SECINFO is not enough with a better naming.
No, these flags do not impact the EPCM protections in any way. Userspace
can extend the EPCM protections without going through the kernel. The
protection flags for an enclave page impact VMA/PTE protection bits.
IMO, it is best to treat the EPCM as being completely separate from the
kernel's EPC management.
> The same field can be also used to cage page type to a subset of values.
>
> /Jarkko
next prev parent reply other threads:[~2019-06-10 16:15 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-06 2:11 [RFC PATCH v2 0/5] security: x86/sgx: SGX vs. LSM Sean Christopherson
2019-06-06 2:11 ` [RFC PATCH v2 1/5] mm: Introduce vm_ops->may_mprotect() Sean Christopherson
2019-06-10 15:06 ` Jarkko Sakkinen
2019-06-10 15:55 ` Sean Christopherson
2019-06-10 17:47 ` Xing, Cedric
2019-06-10 19:49 ` Sean Christopherson
2019-06-10 22:06 ` Xing, Cedric
2019-06-06 2:11 ` [RFC PATCH v2 2/5] x86/sgx: Require userspace to define enclave pages' protection bits Sean Christopherson
2019-06-10 15:27 ` Jarkko Sakkinen
2019-06-10 16:15 ` Sean Christopherson [this message]
2019-06-10 17:45 ` Jarkko Sakkinen
2019-06-10 18:17 ` Sean Christopherson
2019-06-12 19:26 ` Jarkko Sakkinen
2019-06-10 18:29 ` Xing, Cedric
2019-06-10 19:15 ` Andy Lutomirski
2019-06-10 22:28 ` Xing, Cedric
2019-06-12 0:09 ` Andy Lutomirski
2019-06-12 14:34 ` Sean Christopherson
2019-06-12 18:20 ` Xing, Cedric
2019-06-06 2:11 ` [RFC PATCH v2 3/5] x86/sgx: Enforce noexec filesystem restriction for enclaves Sean Christopherson
2019-06-10 16:00 ` Jarkko Sakkinen
2019-06-10 16:44 ` Andy Lutomirski
2019-06-11 17:21 ` Stephen Smalley
2019-06-06 2:11 ` [RFC PATCH v2 4/5] LSM: x86/sgx: Introduce ->enclave_load() hook for Intel SGX Sean Christopherson
2019-06-07 19:58 ` Stephen Smalley
2019-06-10 16:21 ` Sean Christopherson
2019-06-10 16:05 ` Jarkko Sakkinen
2019-06-06 2:11 ` [RFC PATCH v2 5/5] security/selinux: Add enclave_load() implementation Sean Christopherson
2019-06-07 21:16 ` Stephen Smalley
2019-06-10 16:46 ` Sean Christopherson
2019-06-17 16:38 ` Jarkko Sakkinen
2019-06-10 7:03 ` [RFC PATCH v1 0/3] security/x86/sgx: SGX specific LSM hooks Cedric Xing
2019-06-10 7:03 ` [RFC PATCH v1 1/3] LSM/x86/sgx: Add " Cedric Xing
2019-06-10 7:03 ` [RFC PATCH v1 2/3] LSM/x86/sgx: Implement SGX specific hooks in SELinux Cedric Xing
2019-06-11 13:40 ` Stephen Smalley
2019-06-11 22:02 ` Sean Christopherson
2019-06-12 9:32 ` Dr. Greg
2019-06-12 14:25 ` Sean Christopherson
2019-06-13 7:25 ` Dr. Greg
2019-06-12 19:30 ` Andy Lutomirski
2019-06-12 22:02 ` Sean Christopherson
2019-06-13 0:10 ` Xing, Cedric
2019-06-13 1:02 ` Xing, Cedric
2019-06-13 17:02 ` Stephen Smalley
2019-06-13 23:03 ` Xing, Cedric
2019-06-13 23:17 ` Sean Christopherson
2019-06-14 0:31 ` Xing, Cedric
2019-06-14 0:46 ` Sean Christopherson
2019-06-14 15:38 ` Sean Christopherson
2019-06-16 22:14 ` Andy Lutomirski
2019-06-17 16:49 ` Sean Christopherson
2019-06-17 17:08 ` Andy Lutomirski
2019-06-18 15:40 ` Dr. Greg
2019-06-14 17:16 ` Xing, Cedric
2019-06-14 17:45 ` Sean Christopherson
2019-06-14 17:53 ` Sean Christopherson
2019-06-14 20:01 ` Sean Christopherson
2019-06-16 22:16 ` Andy Lutomirski
2019-06-14 23:19 ` Dr. Greg
2019-06-11 22:55 ` Xing, Cedric
2019-06-13 18:00 ` Stephen Smalley
2019-06-13 19:48 ` Sean Christopherson
2019-06-13 21:09 ` Xing, Cedric
2019-06-13 21:02 ` Xing, Cedric
2019-06-14 0:37 ` Sean Christopherson
2019-06-10 7:03 ` [RFC PATCH v1 3/3] LSM/x86/sgx: Call new LSM hooks from SGX subsystem Cedric Xing
2019-06-10 17:36 ` [RFC PATCH v1 0/3] security/x86/sgx: SGX specific LSM hooks 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=20190610161532.GC15995@linux.intel.com \
--to=sean.j.christopherson@intel.com \
--cc=akpm@linux-foundation.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=bp@alien8.de \
--cc=cedric.xing@intel.com \
--cc=dave.hansen@intel.com \
--cc=eparis@parisplace.org \
--cc=haitao.huang@intel.com \
--cc=jarkko.sakkinen@linux.intel.com \
--cc=jethro@fortanix.com \
--cc=jmorris@namei.org \
--cc=josh@joshtriplett.org \
--cc=kai.huang@intel.com \
--cc=kai.svahn@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=linux-sgx@vger.kernel.org \
--cc=luto@kernel.org \
--cc=nhorman@redhat.com \
--cc=npmccallum@redhat.com \
--cc=paul@paul-moore.com \
--cc=philip.b.tricca@intel.com \
--cc=rientjes@google.com \
--cc=sds@tycho.nsa.gov \
--cc=selinux@vger.kernel.org \
--cc=serge.ayoun@intel.com \
--cc=serge@hallyn.com \
--cc=shay.katz-zamir@intel.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=william.c.roberts@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).