# 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 
- List: linux-security-module
- Page: https://ratatoskr.run/linux-security-module/2021/04/6323855
- Thread: https://ratatoskr.run/linux-integrity/2021/03/6303556/t.md

```text
Richard Weinberger [ref] wrote:

> On Wed, Mar 17, 2021 at 3:08 PM Ahmad Fatoum [ref] wrote:
> >     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

```
