Message-ID: <64cdb5f25c56_2138e294f1@dwillia2-xfh.jf.intel.com.notmuch>
Date:   Fri, 4 Aug 2023 19:37:38 -0700
From:   Dan Williams <dan.j.williams@...el.com>
To:     James Bottomley <James.Bottomley@...senpartnership.com>,
        Dan Williams <dan.j.williams@...el.com>, <dhowells@...hat.com>
CC:     Brijesh Singh <brijesh.singh@....com>,
        Kuppuswamy Sathyanarayanan 
        <sathyanarayanan.kuppuswamy@...ux.intel.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Tom Lendacky <thomas.lendacky@....com>,
        "Dionna Amalie Glaze" <dionnaglaze@...gle.com>,
        Borislav Petkov <bp@...en8.de>,
        Jarkko Sakkinen <jarkko@...nel.org>,
        Samuel Ortiz <sameo@...osinc.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        <linux-coco@...ts.linux.dev>, <keyrings@...r.kernel.org>,
        <x86@...nel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 0/4] keys: Introduce a keys frontend for attestation
 reports

James Bottomley wrote:
[..]
> > This report interface on the other hand just needs a single ABI to
> > retrieve all these vendor formats (until industry standardization
> > steps in) and it needs to be flexible (within reason) for all the
> > TSM-specific options to be conveyed. I do not trust my ioctl ABI
> > minefield avoidance skills to get that right. Key blob instantiation
> > feels up to the task.
> 
> To repeat: there's nothing keylike about it.

>From that perspective there's nothing keylike about user-keys either.
Those are just blobs that userspace gets to define how they are used and
the keyring is just a transport. I also think that this interface *is*
key-like in that it is used in the flow of requesting other key
material. The ability to set policy on who can request and instantiate
these pre-requisite reports can be controlled by request-key policy.

If there was vendor standardization I would be open to /dev/tsmX
interface, but I do not think this deserves brand new ABI from scratch.

> If you think that the keyctl mechanism for transporting information
> across the kernel boundary should be generalised and presented as an
> alternative to our fashion of the year interface for this, then that's
> what you should do (and, I'm afraid to add, cc all the other
> opinionated people who've also produced the flavour of the year
> interfaces). 

So I am coming back to this after seeing the thrash that the sysfs
proposal is already causing [1]. sysfs is simply not the right interface
for a transactional interface. My assumption that this interface would
be something that happens once is contraindicated by Peter and Dionna.
So sysfs would require a userspace agent to arbitrate multiple
requesters reconfiguring this all the time.

[1]: http://lore.kernel.org/r/ZM0lEvYJ+5IgybLT@redhat.com 

> Sneaking it in as a one-off is the wrong way to proceed
> on something like this.

Where is the sneaking in cc'ing all the relevant maintainers of the
keyring subsystem and their mailing list? Yes, please add others to the
cc. 

The question for me at this point is whether a new:

	/dev/tsmX

...ABI is worth inventing, or if a key-type is sufficient. To Peter's
concern, this key-type imposes no restrictions over what sevguest
already allows. New options are easy to add to the key instantiation
interface and I expect different vendors are likely to develop workalike
functionality to keep option proliferation to a minimum. Unlike ioctl()
there does not need to be as careful planning about the binary format of
the input payload for per vendor options. Just add more tokens to the
instantiation command-line.

The keyring is also sysfs-like in that it is amenable to manipulation
with command line tools that all systems have available, or by
libkeyctl. 

To the concern about where do we draw the line for other use cases that
want to use this as a precedent is to point out that this usage is
demonstrably part of a key material provisioning flow.

Powered by blists - more mailing lists