Re: [PATCH 0/4] keys: Introduce a keys frontend for attestation reports

[James Bottomley]

On Fri, 2023-08-04 at 19:37 -0700, Dan Williams wrote:
> 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.

Whataboutism may be popular in politics at the moment, but it shouldn't
be a justification for API abuse: Just because you might be able to
argue something else is an abuse of an API doesn't give you the right
to abuse it further.

> 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.

I thought we agreed back here:

https://lore.kernel.org/linux-coco/64c5ed6eb4ca1_a88b2942a@xxxxxxxxxxxxxxxxxxxxxxxxx.notmuch/

That it ended up as "just a transport interface".  Has something
changed that?

[...]
> > 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. 

I was thinking more using the term pubkey in the text about something
that is more like a nonce:

https://lore.kernel.org/linux-coco/169057265801.180586.10867293237672839356.stgit@xxxxxxxxxxxxxxxxxxxxxxxxx/

That looked to me designed to convince the casual observer that keys
were involved.

> 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.

I still think this is pretty much an arbitrary transport interface. 
The question of how frequently it is used and how transactional it has
to be depend on the use cases (which I think would bear further
examination).  What you mostly want to do is create a transaction by
adding parameters individually, kick it off and then read a set of
results back.  Because the format of the inputs and outputs is highly
specific to the architecture, the kernel shouldn't really be doing any
inspection or modification.  For low volume single threaded use, this
can easily be done by sysfs.  For high volume multi-threaded use,
something like configfs or a generic keyctl like object transport
interface would be more appropriate.  However, if you think the latter,
it should still be proposed as a new generic kernel to userspace
transactional transport mechanism.


James