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

Reply via email to