linux-sgx.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andy Lutomirski <luto@kernel.org>
To: Sean Christopherson <sean.j.christopherson@intel.com>
Cc: Borislav Petkov <bp@alien8.de>,
	Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>,
	X86 ML <x86@kernel.org>,
	linux-sgx@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	LSM List <linux-security-module@vger.kernel.org>,
	Jethro Beekman <jethro@fortanix.com>,
	Andy Lutomirski <luto@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	asapek@google.com, "Xing, Cedric" <cedric.xing@intel.com>,
	chenalexchen@google.com, conradparker@google.com,
	cyhanish@google.com, Dave Hansen <dave.hansen@intel.com>,
	"Huang, Haitao" <haitao.huang@intel.com>,
	Josh Triplett <josh@joshtriplett.org>,
	"Huang, Kai" <kai.huang@intel.com>,
	"Svahn, Kai" <kai.svahn@intel.com>,
	kmoy@google.com, Christian Ludloff <ludloff@google.com>,
	Neil Horman <nhorman@redhat.com>,
	npmccallum@redhat.com, puiterwijk@redhat.com,
	David Rientjes <rientjes@google.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	yaozhangx@google.com
Subject: Re: [PATCH v33 12/21] x86/sgx: Allow a limited use of ATTRIBUTE.PROVISIONKEY for attestation
Date: Tue, 30 Jun 2020 10:13:00 -0700	[thread overview]
Message-ID: <CALCETrVD2suWEx7ysJCpOE39Ds7-TpBaGo6KjEbq=EenaHkQ_g@mail.gmail.com> (raw)
In-Reply-To: <20200630142027.GA7733@linux.intel.com>

On Tue, Jun 30, 2020 at 7:20 AM Sean Christopherson
<sean.j.christopherson@intel.com> wrote:
>
> On Tue, Jun 30, 2020 at 10:49:56AM +0200, Borislav Petkov wrote:
> > On Mon, Jun 29, 2020 at 03:04:00PM -0700, Sean Christopherson wrote:
> > > /dev/sgx/provision is root-only by default, the expectation is that the admin
> > > will configure the system to grant only specific enclaves access to the
> > > PROVISION_KEY.
> >
> > Uuh, I don't like "the expectation is" - the reality happens to turn
> > differently, more often than not.
>
> Would it help if I worded it as "only root should ever be able to run an
> enclave with access to PROVISION_KEY"?  We obviously can't control what
> admins actually do, hence my wording of it as the expected behavior.
>
> > > In this series, access is fairly binary, i.e. there's no additional kernel
> > > infrastructure to help userspace make per-enclave decisions.  There have been
> > > more than a few proposals on how to extend the kernel to help provide better
> > > granularity, e.g. LSM hooks, but it was generally agreed to punt that stuff
> > > to post-upstreaming to keep things "simple" once we went far enough down
> > > various paths to ensure we weren't painting ourselves into a corner.
> >
> > So this all sounds to me like we should not upstream /dev/sgx/provision
> > now but delay it until the infrastructure for that has been made more
> > concrete. We can always add it then. Changing it after the fact -
> > if we have to and for whatever reason - would be a lot harder for a
> > user-visible interface which someone has started using already.
>
> The userspace and attestation infrastructure is very concrete, i.e. the
> need for userspace to be able to access PROVISION_KEY is there, as is the
> desire to be able to restrict access to PROVISION_KEY, e.g. I believe Andy
> Lutomirski originally requested the ability to restrict access.
>
> The additional infrastructure for per-enclave decisions is somewhat
> orthogonal to the PROVISION_KEY, e.g. they won't necessarily be employed
> by everyone running enclaves, and environments that do have per-enclave
> policies would still likely want the extra layer of restriction for
> PROVISION_KEY.  I only brought the additional policy crud to call out that
> we've done enough path-finding on additional restrictions to have strong
> confidence that adding /dev/sgx/provision won't prevent us from adding more
> fine grained control in the future.

I agree.

I anticipate that most of the nasty fine-grained stuff will end up in
userspace down the road.  Systems can be configured such that
provisioning is done as root, or systems can end up with fancy SELinux
rules or daemons that pass around fds or whatever, but all of this can
be done with the kernel code in this patchset.

  reply	other threads:[~2020-06-30 17:13 UTC|newest]

Thread overview: 93+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-17 22:08 [PATCH v33 00/21] Intel SGX foundations Jarkko Sakkinen
2020-06-17 22:08 ` [PATCH v33 01/21] x86/cpufeatures: x86/msr: Add Intel SGX hardware bits Jarkko Sakkinen
2020-06-22 17:37   ` Borislav Petkov
2020-06-25  1:25     ` Jarkko Sakkinen
2020-06-17 22:08 ` [PATCH v33 02/21] x86/cpufeatures: x86/msr: Add Intel SGX Launch Control " Jarkko Sakkinen
2020-06-24 13:04   ` Borislav Petkov
2020-06-24 14:34     ` Sean Christopherson
2020-06-25  1:28       ` Jarkko Sakkinen
2020-06-17 22:08 ` [PATCH v33 03/21] x86/mm: x86/sgx: Signal SIGSEGV with PF_SGX Jarkko Sakkinen
2020-06-25  8:59   ` Borislav Petkov
2020-06-25 15:34     ` Sean Christopherson
2020-06-25 16:49       ` Borislav Petkov
2020-06-25 20:52     ` Jarkko Sakkinen
2020-06-25 21:11       ` Borislav Petkov
2020-06-26 13:34         ` Jarkko Sakkinen
2020-06-17 22:08 ` [PATCH v33 04/21] x86/sgx: Add SGX microarchitectural data structures Jarkko Sakkinen
2020-06-17 22:08 ` [PATCH v33 05/21] x86/sgx: Add wrappers for ENCLS leaf functions Jarkko Sakkinen
2020-06-17 22:08 ` [PATCH v33 06/21] x86/cpu/intel: Detect SGX support Jarkko Sakkinen
2020-06-17 22:08 ` [PATCH v33 07/21] x86/cpu/intel: Add nosgx kernel parameter Jarkko Sakkinen
2020-06-17 22:08 ` [PATCH v33 08/21] x86/sgx: Initialize metadata for Enclave Page Cache (EPC) sections Jarkko Sakkinen
2020-06-25 10:14   ` Borislav Petkov
2020-06-25 20:11     ` Jarkko Sakkinen
2020-06-17 22:08 ` [PATCH v33 09/21] x86/sgx: Add __sgx_alloc_epc_page() and sgx_free_epc_page() Jarkko Sakkinen
2020-06-25 17:06   ` Borislav Petkov
2020-06-25 20:55     ` Jarkko Sakkinen
2020-06-17 22:08 ` [PATCH v33 10/21] mm: Introduce vm_ops->may_mprotect() Jarkko Sakkinen
2020-06-25 17:14   ` Borislav Petkov
2020-06-25 17:30     ` Matthew Wilcox
2020-06-25 18:06       ` Sean Christopherson
2020-06-25 22:40         ` Jarkko Sakkinen
2020-06-25 22:26     ` Jarkko Sakkinen
2020-06-17 22:08 ` [PATCH v33 11/21] x86/sgx: Linux Enclave Driver Jarkko Sakkinen
2020-06-25 17:23   ` Borislav Petkov
2020-06-25 18:34     ` Sean Christopherson
2020-06-25 18:45       ` Borislav Petkov
2020-06-26 14:19       ` Jarkko Sakkinen
2020-06-25 20:21     ` Jarkko Sakkinen
2020-06-25 20:25       ` Borislav Petkov
2020-06-26 13:40         ` Jarkko Sakkinen
2020-06-25 18:53   ` Borislav Petkov
2020-06-26 14:17     ` Jarkko Sakkinen
2020-06-26  9:14   ` Borislav Petkov
2020-06-26 14:16     ` Sean Christopherson
2020-06-26 14:20       ` Borislav Petkov
2020-07-03 23:04         ` Jarkko Sakkinen
2020-07-03  3:09     ` Jarkko Sakkinen
2020-06-26 15:34   ` Borislav Petkov
2020-07-04  0:13     ` Jarkko Sakkinen
2020-10-26 21:26     ` Dave Hansen
2020-10-27  1:52       ` Jarkko Sakkinen
2020-10-27 10:05       ` Borislav Petkov
2020-10-27 15:20         ` Dave Hansen
2020-10-27 15:37           ` Borislav Petkov
2020-06-27 17:43   ` Borislav Petkov
2020-06-29 15:27     ` Sean Christopherson
2020-06-29 15:37       ` Borislav Petkov
2020-07-04  1:43       ` Jarkko Sakkinen
2020-07-07  1:38         ` Sean Christopherson
2020-07-07  3:29           ` Jarkko Sakkinen
2020-07-04  1:42     ` Jarkko Sakkinen
2020-07-02  3:59   ` Sean Christopherson
2020-07-04  3:31     ` Jarkko Sakkinen
2020-09-02  3:06       ` Haitao Huang
2020-09-02 16:10         ` Sean Christopherson
2020-09-02 18:40           ` Haitao Huang
2020-09-04 12:01         ` Jarkko Sakkinen
2020-06-17 22:08 ` [PATCH v33 12/21] x86/sgx: Allow a limited use of ATTRIBUTE.PROVISIONKEY for attestation Jarkko Sakkinen
2020-06-29 16:02   ` Borislav Petkov
2020-06-29 22:04     ` Sean Christopherson
2020-06-30  8:49       ` Borislav Petkov
2020-06-30 14:20         ` Sean Christopherson
2020-06-30 17:13           ` Andy Lutomirski [this message]
2020-07-02 20:47         ` Dr. Greg
2020-07-03  2:43         ` Jarkko Sakkinen
2020-07-03  2:38       ` Jarkko Sakkinen
2020-07-03  2:32     ` Jarkko Sakkinen
2020-07-03  2:55       ` Jarkko Sakkinen
2020-06-17 22:08 ` [PATCH v33 13/21] x86/sgx: Add a page reclaimer Jarkko Sakkinen
2020-06-17 22:08 ` [PATCH v33 14/21] x86/sgx: ptrace() support for the SGX driver Jarkko Sakkinen
2020-06-17 22:08 ` [PATCH v33 15/21] x86/vdso: Add support for exception fixup in vDSO functions Jarkko Sakkinen
2020-06-29 17:10   ` Borislav Petkov
2020-06-30  6:00     ` Sean Christopherson
2020-06-30  8:41       ` Borislav Petkov
2020-06-30 14:55         ` Sean Christopherson
2020-06-30 16:48         ` Andy Lutomirski
2020-06-30 17:23           ` Sean Christopherson
2020-07-02 12:52           ` Thomas Gleixner
2020-06-17 22:08 ` [PATCH v33 16/21] x86/fault: Add helper function to sanitize error code Jarkko Sakkinen
2020-06-17 22:08 ` [PATCH v33 17/21] x86/traps: Attempt to fixup exceptions in vDSO before signaling Jarkko Sakkinen
2020-06-17 22:08 ` [PATCH v33 18/21] x86/vdso: Implement a vDSO for Intel SGX enclave call Jarkko Sakkinen
2020-06-17 22:08 ` [PATCH v33 19/21] selftests/x86: Add a selftest for SGX Jarkko Sakkinen
2020-06-17 22:08 ` [PATCH v33 20/21] docs: x86/sgx: Document SGX micro architecture and kernel internals Jarkko Sakkinen
2020-06-17 22:08 ` [PATCH v33 21/21] x86/sgx: Update MAINTAINERS 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='CALCETrVD2suWEx7ysJCpOE39Ds7-TpBaGo6KjEbq=EenaHkQ_g@mail.gmail.com' \
    --to=luto@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=asapek@google.com \
    --cc=bp@alien8.de \
    --cc=cedric.xing@intel.com \
    --cc=chenalexchen@google.com \
    --cc=conradparker@google.com \
    --cc=cyhanish@google.com \
    --cc=dave.hansen@intel.com \
    --cc=haitao.huang@intel.com \
    --cc=jarkko.sakkinen@linux.intel.com \
    --cc=jethro@fortanix.com \
    --cc=josh@joshtriplett.org \
    --cc=kai.huang@intel.com \
    --cc=kai.svahn@intel.com \
    --cc=kmoy@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=linux-sgx@vger.kernel.org \
    --cc=ludloff@google.com \
    --cc=nhorman@redhat.com \
    --cc=npmccallum@redhat.com \
    --cc=puiterwijk@redhat.com \
    --cc=rientjes@google.com \
    --cc=sean.j.christopherson@intel.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=yaozhangx@google.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).