From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: linux-sgx@vger.kernel.org, Dave Hansen <dave.hansen@intel.com>,
Cedric Xing <cedric.xing@intel.com>,
Andy Lutomirski <luto@kernel.org>,
Jethro Beekman <jethro@fortanix.com>,
"Dr . Greg Wettstein" <greg@enjellic.com>,
Stephen Smalley <sds@tycho.nsa.gov>
Subject: Re: [RFC PATCH v3 04/12] x86/sgx: Require userspace to define enclave pages' protection bits
Date: Mon, 08 Jul 2019 18:23:46 +0300 [thread overview]
Message-ID: <1b7369a08e98dd08a4f8bb19b16479f12bee130f.camel@linux.intel.com> (raw)
In-Reply-To: <20190707190809.GE19593@linux.intel.com>
On Sun, 2019-07-07 at 12:08 -0700, Sean Christopherson wrote:
> LGTM but why it isn't like:
> >
> > __u16 mrmask;
> > __u8 prot;
> > __u8 reserved[5];
>
> Because math is hard :-) Though I think we'd want
>
> __u16 mrmask
> __u8 prot
> __u8 pad[5];
>
> with an optional
>
> __u64 reserved[?];
>
> "pad" can be ignored, e.g. doesn't need to be explicitly zeroed by
> userspace, whereas "reserved" requires explicit zeroing and probably an
> associated kernel check.
OK, cool with the change itself. Still need to get a better idea
how these make sense in architectural sense.
Things that would help with overall picture:
1. We have to figure out how this can be useful when LSM's are not used.
That gives at least some evidence that the security model is overally
good if it makes sense with and without LSM. Right now this looks like
dead functionality if not coupled with an LSM.
2. Probably some "user story" type of examples would help with the
discussion overall [1] i.e. how one would use this for
her own good.
[1] Probably many of the folks who work x86 tree have ignored major
part of the discussion. Somehow these should be brought to
nutshell so that anyone can get whatever the model is. Anyone
should get it basically.
/Jarkko
next prev parent reply other threads:[~2019-07-08 15:43 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-17 22:24 [RFC PATCH v3 00/12] security: x86/sgx: SGX vs. LSM, round 3 Sean Christopherson
2019-06-17 22:24 ` [RFC PATCH v3 01/12] x86/sgx: Add mm to enclave at mmap() Sean Christopherson
2019-06-17 22:32 ` Dave Hansen
2019-06-17 23:42 ` Andy Lutomirski
2019-06-18 14:11 ` Sean Christopherson
2019-06-18 16:06 ` Sean Christopherson
2019-06-19 12:56 ` Jarkko Sakkinen
2019-06-19 13:00 ` Jarkko Sakkinen
2019-06-20 20:09 ` Jarkko Sakkinen
2019-06-17 22:24 ` [RFC PATCH v3 02/12] x86/sgx: Do not naturally align MAP_FIXED address Sean Christopherson
2019-06-19 13:24 ` Jarkko Sakkinen
2019-06-19 14:08 ` Sean Christopherson
2019-06-20 22:07 ` Jarkko Sakkinen
2019-06-17 22:24 ` [RFC PATCH v3 03/12] selftests: x86/sgx: Mark the enclave loader as not needing an exec stack Sean Christopherson
2019-06-17 22:24 ` [RFC PATCH v3 04/12] x86/sgx: Require userspace to define enclave pages' protection bits Sean Christopherson
2019-06-19 14:43 ` Jarkko Sakkinen
2019-06-19 15:20 ` Sean Christopherson
2019-06-20 22:17 ` Jarkko Sakkinen
2019-07-07 19:08 ` Sean Christopherson
2019-07-08 15:23 ` Jarkko Sakkinen [this message]
2019-07-08 16:19 ` Sean Christopherson
2019-07-09 16:06 ` Jarkko Sakkinen
2019-07-10 17:25 ` Sean Christopherson
2019-07-15 22:29 ` Andy Lutomirski
2019-08-01 16:38 ` Jarkko Sakkinen
2019-08-04 22:20 ` Andy Lutomirski
2019-08-05 20:51 ` Jarkko Sakkinen
2019-08-05 21:30 ` Andy Lutomirski
2019-08-07 18:51 ` Jarkko Sakkinen
2019-06-17 22:24 ` [RFC PATCH v3 05/12] x86/sgx: Enforce noexec filesystem restriction for enclaves Sean Christopherson
2019-06-19 14:46 ` Jarkko Sakkinen
2019-06-17 22:24 ` [RFC PATCH v3 06/12] mm: Introduce vm_ops->may_mprotect() Sean Christopherson
2019-06-17 22:24 ` [RFC PATCH v3 07/12] LSM: x86/sgx: Introduce ->enclave_map() hook for Intel SGX Sean Christopherson
2019-06-17 22:24 ` [RFC PATCH v3 08/12] security/selinux: Require SGX_EXECMEM to map enclave page WX Sean Christopherson
2019-06-17 22:24 ` [RFC PATCH v3 09/12] LSM: x86/sgx: Introduce ->enclave_load() hook for Intel SGX Sean Christopherson
2019-06-19 14:56 ` Jarkko Sakkinen
2019-06-19 21:13 ` James Morris
2019-06-20 9:28 ` Dr. Greg
2019-06-20 22:22 ` Jarkko Sakkinen
2019-06-23 17:16 ` Dr. Greg
2019-06-26 20:39 ` James Morris
2019-06-17 22:24 ` [RFC PATCH v3 10/12] security/selinux: Add enclave_load() implementation Sean Christopherson
2019-06-18 14:49 ` Stephen Smalley
2019-06-19 20:59 ` Sean Christopherson
2019-06-17 22:24 ` [RFC PATCH v3 11/12] security/apparmor: " Sean Christopherson
2019-06-17 22:24 ` [RFC PATCH v3 12/12] LSM: x86/sgx: Show line of sight to LSM support SGX2's EAUG Sean Christopherson
2019-06-18 13:38 ` [RFC PATCH v3 00/12] security: x86/sgx: SGX vs. LSM, round 3 Stephen Smalley
2019-06-18 13:55 ` Sean Christopherson
2019-06-18 15:13 ` Stephen Smalley
2019-06-25 16:29 ` 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=1b7369a08e98dd08a4f8bb19b16479f12bee130f.camel@linux.intel.com \
--to=jarkko.sakkinen@linux.intel.com \
--cc=cedric.xing@intel.com \
--cc=dave.hansen@intel.com \
--cc=greg@enjellic.com \
--cc=jethro@fortanix.com \
--cc=linux-sgx@vger.kernel.org \
--cc=luto@kernel.org \
--cc=sds@tycho.nsa.gov \
--cc=sean.j.christopherson@intel.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.