lkml.org 
[lkml]   [2021]   [Apr]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH v1 0/3] KEYS: trusted: Introduce support for NXP CAAM-based trusted keys
Date
Richard Weinberger <richard.weinberger@gmail.com> wrote:

> On Wed, Mar 17, 2021 at 3:08 PM Ahmad Fatoum <a.fatoum@pengutronix.de> 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

\
 
 \ /
  Last update: 2021-04-01 13:14    [W:0.456 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site