[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2f608e5a-5a12-6db1-b9bd-a2cd9e3e3671@pengutronix.de>
Date: Fri, 2 Jul 2021 10:00:05 +0200
From: Ahmad Fatoum <a.fatoum@...gutronix.de>
To: Richard Weinberger <richard@....at>
Cc: Jonathan Corbet <corbet@....net>,
David Howells <dhowells@...hat.com>,
Jarkko Sakkinen <jarkko@...nel.org>,
James Bottomley <jejb@...ux.ibm.com>,
Mimi Zohar <zohar@...ux.ibm.com>,
kernel <kernel@...gutronix.de>, James Morris <jmorris@...ei.org>,
"Serge E. Hallyn" <serge@...lyn.com>,
horia geanta <horia.geanta@....com>,
aymen sghaier <aymen.sghaier@....com>,
Herbert Xu <herbert@...dor.apana.org.au>,
davem <davem@...emloft.net>, Udit Agarwal <udit.agarwal@....com>,
Eric Biggers <ebiggers@...nel.org>,
Jan Luebbe <j.luebbe@...gutronix.de>,
david <david@...ma-star.at>,
Franck Lenormand <franck.lenormand@....com>,
Sumit Garg <sumit.garg@...aro.org>,
"open list, ASYMMETRIC KEYS" <keyrings@...r.kernel.org>,
Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
Linux Doc Mailing List <linux-doc@...r.kernel.org>,
linux-integrity <linux-integrity@...r.kernel.org>,
linux-kernel <linux-kernel@...r.kernel.org>,
LSM <linux-security-module@...r.kernel.org>
Subject: Re: [PATCH v2 6/6] KEYS: trusted: Introduce support for NXP
CAAM-based trusted keys
Hello Richard,
On 01.07.21 22:42, Richard Weinberger wrote:
> Ahmad,
>
> ----- Ursprüngliche Mail -----
>> Von: "Ahmad Fatoum" <a.fatoum@...gutronix.de>
>> +static struct caam_blob_priv *blobifier;
>> +
>> +#define KEYMOD "kernel:trusted"
>
> I'm still think that hard coding the key modifier is not wise.
> As I said[0], there are folks out there that want to provide their own modifier,
> so it is not only about being binary compatible with other CAAM blob patches in the wild.
I don't think the characterization as a salt is accurate. AFAIU it's more
of a namespace, so blobs being loaded are "type-checked" against the modifier.
> I'll happily implement that feature after your patches got merged but IMHO we should first agree on an interface.
> How about allowing another optional parameter to Opt_new and Opt_load
Sound good to me. pcrlock for TPM trusted keys has the same interface.
I'd prefer the new option to accept strings, not hex though.
> and having a key modifier per struct trusted_key_payload instance?
Ye, possibly a void *backend_data, which other trust sources could leverage
as well. But that should be separate discussion.
Cheers,
Ahmad
>
> Thanks,
> //richard
>
> [0]
> https://patchwork.kernel.org/project/linux-crypto/patch/319e558e1bd19b80ad6447c167a2c3942bdafea2.1615914058.git-series.a.fatoum@pengutronix.de/#24085397
>
>
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Powered by blists - more mailing lists