From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: Sean Christopherson <sean.j.christopherson@intel.com>,
Andy Lutomirski <luto@amacapital.net>
Cc: Topi Miettinen <toiwoton@gmail.com>,
Jethro Beekman <jethro@fortanix.com>,
Casey Schaufler <casey@schaufler-ca.com>,
Andy Lutomirski <luto@kernel.org>,
casey.schaufler@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: Thu, 9 Apr 2020 21:39:16 +0300 [thread overview]
Message-ID: <20200409183904.GA28876@linux.intel.com> (raw)
In-Reply-To: <20200408145636.GD10686@linux.intel.com>
On Wed, Apr 08, 2020 at 07:56:36AM -0700, Sean Christopherson wrote:
> On Wed, Apr 08, 2020 at 04:40:49PM +0300, Jarkko Sakkinen wrote:
> > What starts to be obvious is that we don't do anything in code level
> > in SGX particular but instead workaround something around /dev.
>
> Can you summarize the plan going forward? Thanks!
Sure.
The summary is that the permission problem should be solved outside of
SGX. Doing an FS is somewhat big hammer to sort out the permission
problem. It will also make configuration more clunky i.e. kernel
defines some static permissions and then let say the systemd unit file
will overwrite them with some other. It is somewhat more sound to have
the udev db to contain the permissions.
Admitting that we don't have exact solutions I think we have enough
knowledge to say that things can be refined to work for SGX outside of
SGX.
I've been playing with the idea to add something like SB_I_DEVMMAPEXEC [1]
to superblock flags. This would be set by devtmpfs
(drivers/base/devtmpfs.c) initialization code. Then do_mmap_pgoff should
check this flag from superblock and that we are mapping a device node.
If these premises are fulfilled, then it would allow mmap().
This will make exec work when mapping device nodes but does not allow
attacker to put executable to /dev and run them in the threat scenario
described by Topi [2].
Andy also mentioned that he was going mail to udev ML but have not
checked that at this point.
[1] For explicit control of this new behavior also mnt flag is needed.
[2] https://patchwork.kernel.org/patch/11467637/#23269417
/Jarkko
next prev parent reply other threads:[~2020-04-09 18:39 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
2020-04-08 14:56 ` Sean Christopherson
2020-04-09 18:39 ` Jarkko Sakkinen [this message]
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=20200409183904.GA28876@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).