[PATCH v4] fdt: automatically add /chosen/kaslr-seed if DM_RNG is enabled

[Marek Vasut]

On 5/29/24 7:05 PM, Simon Glass wrote:

[...]

>>>> that is not yet implemented as DM_RNG. We also skip this if
>>>> MEASURED_BOOT is enabled as in that case any modifications to the
>>>> dt will cause measured boot to fail (although there are many other
>>>> places the dt is altered).
>>>>
>>>> As this fdt node is added elsewhere create a library function and
>>>> use it to deduplicate code. We will provide a parameter to specify the
>>>> index of the rng device as well as a boolean to overwrite if present.
>>>>
>>>> For our automatic injection, we will use the first rng device and
>>>> not overwrite if already present with a non-zero value (which may
>>>> have been populated by an earlier boot stage). This way if a board
>>>> specific ft_board_setup() function wants to customize this behavior
>>>> it can call fdt_kaslrseed with a rng device index of its choosing and
>>>> set overwrite true.
>>>
>>> I suggest creating a sysinfo driver which can provide the RNG device.
>>
>> I'm not really clear what you mean but that seems out of scope for
>> this patch. If/when someone needs to extend the functionality of
>> specifying one of many RNG's perhaps they can follow that approach.
> 
> The thing is, you are creating a way to specify the RNG which will
> presumably lead to different vendors all doing it a different way.
> 
> Specifically, fdt_kaslrseed() takes a device number (would be better
> to take a struct udevice, BTW).
> 
> Instead, I think you should define the standard way that the chosen
> RNG should be specified by the board. The sysinfo driver can provide a
> way to do this. Then boards can handle this themselves, using sysinfo,
> rather than directly calling a function in the fixup. After all, we
> want the fixup flow to be as generic as possible.

I think this patch simply picks up the first RNG that is available, 
pulls a number out of it, and uses that as the KASLR seed in DT. That's 
what the implementation(s) seems to be doing so far, this patch is a 
deduplication only, so maybe we should retain the original behavior 
first, and do architectural changes in follow up patch(es) ?