From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: Topi Miettinen <toiwoton@gmail.com>
Cc: Andy Lutomirski <luto@amacapital.net>,
Jethro Beekman <jethro@fortanix.com>,
Casey Schaufler <casey@schaufler-ca.com>,
Andy Lutomirski <luto@kernel.org>,
casey.schaufler@intel.com,
Sean Christopherson <sean.j.christopherson@intel.com>,
linux-sgx@vger.kernel.org, "Svahn, Kai" <kai.svahn@intel.com>,
"Schlobohm, Bruce" <bruce.schlobohm@intel.com>,
Stephen Smalley <sds@tycho.nsa.gov>,
Haitao Huang <haitao.huang@linux.intel.com>,
ben@decadent.org.uk
Subject: Re: [PATCH 2/4] x86/sgx: Put enclaves into anonymous files
Date: Wed, 8 Apr 2020 16:40:49 +0300 [thread overview]
Message-ID: <20200408134049.GB4097@linux.intel.com> (raw)
In-Reply-To: <7009f0e2-cdfc-1703-2b73-bb683a89c8d1@gmail.com>
On Tue, Apr 07, 2020 at 10:54:46PM +0300, Topi Miettinen wrote:
> On 7.4.2020 21.04, Jarkko Sakkinen wrote:
> > On Tue, Apr 07, 2020 at 07:59:00PM +0300, Jarkko Sakkinen wrote:
> > > On Tue, Apr 07, 2020 at 07:57:08PM +0300, Jarkko Sakkinen wrote:
> > > > On Tue, Apr 07, 2020 at 12:04:58PM +0300, Topi Miettinen wrote:
> > > > > Please correct me if I'm wrong, but isn't it the goal of SGX to let a
> > > > > (suitably privileged) process designate some of its memory areas as part of
> > > > > SGX enclave? If so, why don't you simply add a system call to do so, such as
> > > > >
> > > > > int sgx_mprotect(void *start, size_t length, int prot, u64 sgx_flags);
> > > > >
> > > > > like existing pkey_mprotect()? Or add a flag PROT_SGX to mprotect() like
> > > > > existing PROT_SAO/PROT_SEM?
> > > > >
> > > > > -Topi
> > > >
> > > > New syscalls is always the last resort path, especially if they are
> > > > associated with an arch.
> > > >
> > > > PROT_SGX sounds something worth of consideration.
> > > >
> > > > Another idea to throw would be noexec_dev mount option that would allow
> > > > exec *only* for the device nodes (zero analysis done on feasibility).
> > >
> > > The 2nd proposal has the merit that it would scale above SGX and
> > > does not give additional strengths to the adversary in the context
> > > of the threat scenario.
> >
> > Or.
> >
> > Why couldn't kernel just disallow anything but device files to be
> > created to devtmpfs unconditionally?
>
> It seems to be just a regular tmpfs but with direct access to add device
> nodes when drivers are loaded. Nice idea, maybe something like that could be
> done with SELinux policy.
Anyway, thank you for all the feedback.
What starts to be obvious is that we don't do anything in code level
in SGX particular but instead workaround something around /dev.
/Jarkko
next prev parent reply other threads:[~2020-04-08 13:40 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-31 11:44 [PATCH 0/4] Migrate enclave mapping to an anonymous inode Jarkko Sakkinen
2020-03-31 11:44 ` [PATCH 1/4] x86/sgx: Remove PROT_NONE branch from sgx_encl_may_map() Jarkko Sakkinen
2020-03-31 11:44 ` [PATCH 2/4] x86/sgx: Put enclaves into anonymous files Jarkko Sakkinen
2020-03-31 17:39 ` Andy Lutomirski
2020-04-01 0:24 ` Sean Christopherson
2020-04-02 21:41 ` Andy Lutomirski
2020-04-03 6:56 ` Jarkko Sakkinen
2020-04-03 6:59 ` Jarkko Sakkinen
2020-04-03 14:35 ` Casey Schaufler
2020-04-03 15:30 ` Jarkko Sakkinen
2020-04-03 15:50 ` Casey Schaufler
2020-04-03 22:08 ` Jarkko Sakkinen
2020-04-04 3:54 ` Andy Lutomirski
2020-04-04 5:46 ` Jethro Beekman
2020-04-04 7:27 ` Topi Miettinen
2020-04-04 9:20 ` Jarkko Sakkinen
2020-04-06 6:42 ` Jethro Beekman
2020-04-06 11:01 ` Topi Miettinen
2020-04-06 16:44 ` Andy Lutomirski
2020-04-06 17:17 ` Jethro Beekman
2020-04-06 18:55 ` Jarkko Sakkinen
2020-04-06 19:01 ` Jarkko Sakkinen
2020-04-06 19:53 ` Andy Lutomirski
2020-04-06 21:24 ` Jarkko Sakkinen
2020-04-06 23:18 ` Andy Lutomirski
2020-04-06 23:48 ` Jarkko Sakkinen
2020-04-07 7:15 ` Jethro Beekman
2020-04-07 8:48 ` Topi Miettinen
2020-04-07 16:52 ` Jarkko Sakkinen
2020-04-07 9:04 ` Topi Miettinen
2020-04-07 16:57 ` Jarkko Sakkinen
2020-04-07 16:59 ` Jarkko Sakkinen
2020-04-07 18:04 ` Jarkko Sakkinen
2020-04-07 19:54 ` Topi Miettinen
2020-04-08 13:40 ` Jarkko Sakkinen [this message]
2020-04-08 14:56 ` Sean Christopherson
2020-04-09 18:39 ` Jarkko Sakkinen
2020-04-08 21:15 ` Topi Miettinen
2020-04-08 21:29 ` Sean Christopherson
2020-11-19 7:23 ` Jethro Beekman
2020-11-19 16:09 ` Andy Lutomirski
2020-04-06 18:47 ` Jarkko Sakkinen
2020-04-04 9:22 ` Jarkko Sakkinen
2020-04-01 8:45 ` Jarkko Sakkinen
2020-03-31 11:44 ` [PATCH 3/4] x86/sgx: Move mmap() to the anonymous enclave file Jarkko Sakkinen
2020-03-31 11:44 ` [PATCH 4/4] x86/sgx: Hand over the enclave file to the user space 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=20200408134049.GB4097@linux.intel.com \
--to=jarkko.sakkinen@linux.intel.com \
--cc=ben@decadent.org.uk \
--cc=bruce.schlobohm@intel.com \
--cc=casey.schaufler@intel.com \
--cc=casey@schaufler-ca.com \
--cc=haitao.huang@linux.intel.com \
--cc=jethro@fortanix.com \
--cc=kai.svahn@intel.com \
--cc=linux-sgx@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=luto@kernel.org \
--cc=sds@tycho.nsa.gov \
--cc=sean.j.christopherson@intel.com \
--cc=toiwoton@gmail.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 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).