linux-kernel - Re: [PATCH v4 2/5] KEYS: trusted: allow users to use kernel RNG for key material

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]

Message-ID: <3f58a16d-ae57-bb78-f04e-878dd5408a4f@pengutronix.de>
Date:   Mon, 13 Dec 2021 11:29:07 +0100
From:   Ahmad Fatoum <a.fatoum@...gutronix.de>
To:     Jarkko Sakkinen <jarkko@...nel.org>
Cc:     James Bottomley <jejb@...ux.ibm.com>,
        Mimi Zohar <zohar@...ux.ibm.com>,
        David Howells <dhowells@...hat.com>, kernel@...gutronix.de,
        Sumit Garg <sumit.garg@...aro.org>,
        David Gstir <david@...ma-star.at>,
        Tim Harvey <tharvey@...eworks.com>,
        James Morris <jmorris@...ei.org>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        Horia Geantă <horia.geanta@....com>,
        Aymen Sghaier <aymen.sghaier@....com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "David S. Miller" <davem@...emloft.net>,
        Udit Agarwal <udit.agarwal@....com>,
        Jan Luebbe <j.luebbe@...gutronix.de>,
        Eric Biggers <ebiggers@...nel.org>,
        Richard Weinberger <richard@....at>,
        Franck LENORMAND <franck.lenormand@....com>,
        keyrings@...r.kernel.org, linux-crypto@...r.kernel.org,
        linux-integrity@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-security-module@...r.kernel.org
Subject: Re: [PATCH v4 2/5] KEYS: trusted: allow users to use kernel RNG for
 key material

Hello Jarkko,

On 05.12.21 01:16, Jarkko Sakkinen wrote:
> On Mon, Oct 11, 2021 at 12:02:35PM +0200, Ahmad Fatoum wrote:
>> The two existing trusted key sources don't make use of the kernel RNG,
>> but instead let the hardware doing the sealing/unsealing also
>> generate the random key material. However, Users may want to place
> 
> "Users" -> "users"

Will fix for v5.

>> +static bool trusted_kernel_rng;
>> +module_param_named(kernel_rng, trusted_kernel_rng, bool, 0);
>> +MODULE_PARM_DESC(kernel_rng, "Generate key material from kernel RNG");
> 
> It's not then always kernel RNG, i.e. that is a very misleading name.

trusted.kernel_rng=1 always forces kernel RNG, trusted.kernel_rng=0 will
choose trust source default.

> I'd prefer trusted_rng with string values "kernel", "tee". That makes
> it explicit what you are using.

This is also a bit misleading for trust sources that don't provide their
own RNG, either because the driver doesn't implement it, or because the
IP doesn't have its own RNG (like DCP on NXP's i.MX6UL SoC).

For v5, I'd implement following 'tristate-with-strings' scheme:

 trusted.rng=""
	=> Use trust source default, fall back to kernel RNG if there's none
           (trusted.kernel_rng=0 in current patch)

 trusted.rng=kernel
	=> Always use kernel RNG
           (trusted.kernel_rng=1 in current patch)

 trusted.rng=$trusted.source
	=> Use trust source default, but error out if trust source
           doesn't implement its own RNG to avoid misleading users
           about key randomness source

 trusted.rng="anything-else"
	=> Error out with warning that only valid values are
	   "kernel,${trust.source}" where trust.source is the currently
	   active one.

Sounds good?

Cheers,
Ahmad

> 
> /Jarkko
> 


-- 
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 |