linux-sgx.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
To: Andy Lutomirski <luto@kernel.org>
Cc: Topi Miettinen <toiwoton@gmail.com>,
	Jethro Beekman <jethro@fortanix.com>,
	Casey Schaufler <casey@schaufler-ca.com>,
	"Schaufler, Casey" <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 Hutchings <ben@decadent.org.uk>
Subject: Re: [PATCH 2/4] x86/sgx: Put enclaves into anonymous files
Date: Tue, 7 Apr 2020 02:48:20 +0300	[thread overview]
Message-ID: <20200406234820.GA3956@linux.intel.com> (raw)
In-Reply-To: <CALCETrWkaUS2RU61_4KoNhn3RkW-J+SWiCQTZ623wu4b7snJ0w@mail.gmail.com>

On Mon, Apr 06, 2020 at 04:18:20PM -0700, Andy Lutomirski wrote:
> On Mon, Apr 6, 2020 at 2:24 PM Jarkko Sakkinen
> <jarkko.sakkinen@linux.intel.com> wrote:
> >
> > On Mon, Apr 06, 2020 at 12:53:41PM -0700, Andy Lutomirski wrote:
> > > > sgxfs is somewhat trivial to implement and has one stakeholder less to
> > > > worry about. It is not really a huge stretch.
> > > >
> > > > Overally, I think it is something that we could live with. At least it
> > > > is something that does not step on others toes.
> > > >
> > > > Haitao: If we go with sgxfs route, then you can for the moment do what
> > > > Andy suggested: bind mount it to /dev/sgx.
> > >
> > > That also needs userspace support.
> > >
> > > I’ll start a thread on the udev list.
> >
> > Haven't written any code yet but just by drafting the idea I already
> > pinpointed something.
> >
> > You would add roughly this to the existing codebase:
> >
> > * struct file_system_type sgxfs
> > * struct fs_context_operations sgxfs_ctx_ops
> > * int sgxfs_get_tree()
> > * int sgxfs_fill_super()
> > * const struct tree_descr sgxfs_files[]
> >
> > The files would be defined as like this:
> >
> > static const struct tree_descr sgxfs_files[] {
> >         [SGXFS_ENCLAVE] = { "enclave", &sgxfs_encl_ops, /* ? */ },
> >         [SGXFS_PROVISION] = { "provision", &sgxfs_encl_ops, /* ? */ },
> > };
> >
> > The permissions would need to be completely static, which feels nasty
> > from maintainability viewpoint :-( And I see no gain anywhere.
> >
> > In my opinion udev defining the whole /dev as noexec has zero technical
> > merits. It is same as they would say that "we don't trust our own
> > database". There are no real security benefits as long as dev nodes are
> > configured correctly.
> 
> I tend to agree, but it could be seen as a sort-of-valid hardening measure.

Bets are not great anyway to revert it so lets just consider it as a
constraint then.

> I think the best bet is for you to ignore this and let userspace figure it out.

Yeah. You could put statically 0700 permissions and then let systemd to
set the legit ones but it just feels a way too big hammer to do a new fs
just to sort out a simple permission issue.

/Jarkko

  reply	other threads:[~2020-04-06 23:48 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 [this message]
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
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=20200406234820.GA3956@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@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).