[PATCH v33 12/21] x86/sgx: Allow a limited use of ATTRIBUTE.PROVISIONKEY for attestation
Jarkko Sakkinen
jarkko.sakkinen at linux.intel.com
Fri Jul 3 02:43:06 UTC 2020
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:
> > > I don't see this acronym resolved anywhere in the whole patchset.
> >
> > Quoting Enclave.
>
> Yah, pls add it somewhere.
>
> > /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.
>
> > 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.
>
> So I'd leave that out from the initial patchset.
I'm trying to understand what is meant by "more concrete". Attestation
is needed for most enclave applications.
If this patch is dropped, should we also allow PROVISION_KEY attribute
to all enclaves? Dropping this patch and keeping that check in the
driver patch is not very coherent behaviour.
/Jarkko
More information about the Linux-security-module-archive
mailing list