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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 31 Mar 2021 20:36:07 +0200 (CEST)
From:   Richard Weinberger <richard@....at>
To:     James Bottomley <jejb@...ux.ibm.com>
Cc:     Ahmad Fatoum <a.fatoum@...gutronix.de>,
        Jarkko Sakkinen <jarkko@...nel.org>,
        horia geanta <horia.geanta@....com>,
        Mimi Zohar <zohar@...ux.ibm.com>,
        aymen sghaier <aymen.sghaier@....com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        davem <davem@...emloft.net>, kernel <kernel@...gutronix.de>,
        David Howells <dhowells@...hat.com>,
        James Morris <jmorris@...ei.org>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        Steffen Trumtrar <s.trumtrar@...gutronix.de>,
        Udit Agarwal <udit.agarwal@....com>,
        Jan Luebbe <j.luebbe@...gutronix.de>,
        david <david@...ma-star.at>,
        Franck Lenormand <franck.lenormand@....com>,
        Sumit Garg <sumit.garg@...aro.org>,
        linux-integrity <linux-integrity@...r.kernel.org>,
        "open list, ASYMMETRIC KEYS" <keyrings@...r.kernel.org>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        LSM <linux-security-module@...r.kernel.org>
Subject: Re: [PATCH v1 0/3] KEYS: trusted: Introduce support for NXP
 CAAM-based trusted keys

James,

----- Ursprüngliche Mail -----
> Von: "James Bottomley" <jejb@...ux.ibm.com>
>> On Wed, Mar 17, 2021 at 3:08 PM Ahmad Fatoum <a.fatoum@...gutronix.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
> 
> Why would you want to in the load?  The blob should be type specific,
> so a TPM key shouldn't load as a CAAM key and vice versa ... and if
> they're not they need to be made so before the patches go upstream.

I fear right now there is no good way to detect whether a blob is desired
for CAAM or TPM.

> I could possibly see that you might want to be type specific in the
> create, but once you're simply loading an already created key, the
> trusted key subsystem should be able to figure what to do on its own.

So you have some kind of container format in mind which denotes the
type of the blob?

Thanks,
//richard