[PATCH v4] rockchip: board: Increase rng-seed size to make it sufficient for modern Linux

Quentin Schulz quentin.schulz at cherry.de
Tue Oct 15 15:49:06 CEST 2024


Hi Alex,

On 10/15/24 2:42 PM, Alex Shumsky wrote:
> On Tue, Oct 15, 2024 at 12:34 PM Quentin Schulz
> <quentin.schulz at cherry.de> wrote:
>> I'm wondering if we have somewhere some documentation on the environment
>> variables that exist and what they used for because this would be a nice
>> addition. At the very least, we can mention this variable in:
>> - include/fdt_support.h for the function
>> - common/Kconfig for the symbol
> 
> I'm not sure if we can expect that all boards can implement the rng_seed_size
> config knob? Currently rockchip is the only board that implements
> board_rng_seed.
> 

That;s the neat part, we're the only implementation so far, so we kinda 
get to say what's supposed to be "standard". I think allowing to get a 
specific size makes sense generally.

Basically, I would like to avoid 1) people not knowing how to change 
this value 2) avoid having different implementations using a different 
environment variable.

Tom has just told me on IRC that we have doc/usage/environment.rst for 
environment variables' documentation, so that would be a good place to 
put some documentation for this new variable :)

> common/Kconfig BOARD_RNG_SEED description looks rather generic:
> 
> It is up to the board code (and more generally the whole
> BSP) where and how to store (or generate) such a seed, how
> to ensure a given seed is only used once, how to create a
> new seed for use on subsequent boots, and whether or not the
> kernel should account any entropy from the given seed.
> 
>> I'm also a bit torn on the base though, I think the assumed base is
>> generally hex and not dec, so maybe we should rather have that?
> 
> We need a poll here )
> Marek Vasut prefers decimal.

Hehe, I think this "debate" will never end, I already had it with Simon 
and Tom a few weeks ago. The "issue" is that once that's decided, we 
cannot really change it as that would basically break compatibility (new 
env with old U-Boot or vice-versa). Not a blocker as such, but needs to 
make sure it's aligned with expectations.

https://docs.u-boot.org/en/latest/usage/cmdline.html#representing-numbers

Cheers,
Quentin


More information about the U-Boot mailing list