Messages in this thread | | | Date | Fri, 4 Aug 2023 19:37:38 -0700 | From | Dan Williams <> | 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.
| |