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 |
