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

[Dan Williams]

James Bottomley wrote:
> 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.

That appears to be the disagreement, that the "user" key type is an
abuse of the keyctl subsystem. Is that the general consensus that it was
added as a mistake that is not be repeated?

Otherwise there is significant amount of thought that has gone into
keyctl including quotas, permissions, and instantiation flows.


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

This feedback cast doubt on the assumption that attestation reports are
infrequently generated:

http://lore.kernel.org/r/CAAH4kHbsFbzL=0gn71qq1-1kL398jiS2rd3as1qUFnLTCB5mHQ@xxxxxxxxxxxxxx

Now, the kernel is within its rights to weigh in on that question with
an ABI that is awkward for that use case, or it can decide up front that
sysfs is not built for transactions.

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

Ok, I see where you were going, at the same time I was trusting
keyrings@ community to ask about that detail and was unaware of any
advocacy against new key types.

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

Perhaps we can get more detail about the proposed high-volume use case:
Dionna, Peter?

I think the minimum bar for ABI success here is that options are not
added without touching a common file that everyone can agree what the
option is, no more drivers/virt/coco/$vendor ABI isolation. If concepts
like VMPL and RTMR are going to have cross-vendor workalike
functionality one day then the kernel community picks one name for
shared concepts. The other criteria for success is that the frontend
needs no change when standardization arrives, assuming all vendors get
their optionality into that spec definition.

keyring lessened my workload with how it can accept ascii token options
whereas ioctl() needs more upfront thought.