Thread (71 messages) 71 messages, 13 authors, 2021-04-02

Re: [PATCH v1 0/3] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys

From: David Howells <dhowells@redhat.com>
Date: 2021-04-01 11:12:23
Also in: keyrings, linux-crypto, linux-integrity, lkml

Richard Weinberger [off-list ref] wrote:
On Wed, Mar 17, 2021 at 3:08 PM Ahmad Fatoum [off-list ref] wrote:
quoted
    keyctl add trusted $KEYNAME "load $(cat ~/kmk.blob)" @s
Is there a reason why we can't pass the desired backend name in the
trusted key parameters?
e.g.
keyctl add trusted $KEYNAME "backendtype caam load $(cat ~/kmk.blob)" @s
I wonder...  Does it make sense to add a new variant of the add_key() and
keyctl_instantiate() syscalls that takes an additional parameter string,
separate from the payload blob?

       key_serial_t add_key2(const char *type, const char *description,
			     const char *params,
                             const void *payload, size_t plen,
                             key_serial_t keyring);

which could then by used, say:

	keyctl add --payload=~/kmk.blob trusted $KEYNAME "backendtype caam load" @s

This would then appear in

	struct key_preparsed_payload {
		const char	*orig_description;
		char		*description;
		char		*params;	<---
		union key_payload payload;
		const void	*data;
		size_t		datalen;
		size_t		quotalen;
		time64_t	expiry;
	};

params would then be NULL for add_key().

If add_key2() is not available, the --payload param gets concatenated to the
parameters string.

Might be too complicated, I guess.  Though it might make sense just to do the
concatenation inside the keyctl program.

David
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help