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

Dragan Simic dsimic at manjaro.org
Mon Oct 14 14:15:08 CEST 2024


On 2024-10-14 14:10, Marek Vasut wrote:
> On 10/14/24 12:57 PM, Dragan Simic wrote:
>> On 2024-10-14 12:52, Marek Vasut wrote:
>>> On 10/14/24 12:37 PM, Dragan Simic wrote:
>>>> On 2024-10-14 12:35, Marek Vasut wrote:
>>>>> On 10/14/24 12:32 PM, Dragan Simic wrote:
>>>>>> On 2024-10-14 12:26, Alex ThreeD wrote:
>>>>>>> On Mon, Oct 14, 2024 at 12:10 AM Marek Vasut <marex at denx.de> 
>>>>>>> wrote:
>>>>>>>> Let's make this override-able via environment variable, because 
>>>>>>>> this
>>>>>>>> might be growing in the future again. Does this work ?
>>>>>>>> 
>>>>>>>> size_t len = env_get_ulong("kaslrseed_size", 10, 32);
>>>>>>> 
>>>>>>> Maybe `env_get_hex("rng_seed_size", 32)` would be better? As most 
>>>>>>> other env are
>>>>>>> hexadecimal.
>>>>>>> 
>>>>>>> Actually it seems that entropy required to init pool early has 
>>>>>>> decreased in
>>>>>>> Linux 5.19 from 64 bytes (2 * CHACHA_KEY_SIZE) to 32 bytes
>>>>>>> (BLAKE2S_HASH_SIZE)
>>>>>>> https://elixir.bootlin.com/linux/v5.18/source/drivers/char/ 
>>>>>>> random.c#L236
>>>>>>> https://elixir.bootlin.com/linux/v5.19/source/drivers/char/ 
>>>>>>> random.c#L551
>>>>>>> Anyway config knob should not harm.
>>>>>> 
>>>>>> I think that the value received from the new environment variable
>>>>>> should be accepted only if it's greater than some hardcoded value,
>>>>>> in this case 32.  That way, someone won't be able to misconfigure
>>>>>> their board environment and cause the early random pool 
>>>>>> initialization
>>>>>> to be postponed.
>>>>> 
>>>>> Using low number could be useful for testing. Print a WARNING if 
>>>>> the
>>>>> number is too low perhaps?
>>>> 
>>>> Yes, testing with low values has also crossed my mind.  Priting such
>>>> warnings would be a viable option.
>>> 
>>> Sounds good then, thanks!
>> 
>> Thank you. :)  My early thoughts were like "wow, someone can break
>> their early random pool initialization this way", but right after
>> that something like "well, breaking many other things is already
>> possible in the same way" crossed my mind. :)
> 
> That crossed my mind too, but ...
> 
>> So, yes, just printing such warnings is perfectly fine.
> 
> ... right. U-Boot is a debug tool and boot monitor, so it gives user
> the freedom to do whatever they want/need/..., which includes the
> obligatory footgun .

Haha, foot gun, that brought a smile to my face! :)  Well said.

> If the concern is lockdown of U-Boot env so it cannot induce negative
> side effects, there is CONFIG_ENV_WRITEABLE_LIST and others for those
> purposes.

Yes, while in the default configuration, U-Boot gives virtually full
freedom to its users, which is good.


More information about the U-Boot mailing list