u-boot.git/include/fdt_support.h, branch v2025.01

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

2024-10-26T02:46:47+00:00

Increase rng-seed size to make Linux happy and initialize rng pool instantly.
Linux 5.19+ requires 32 bytes of entropy to initialize random pool, but u-boot
currently provides only 8 bytes.
Linux 5.18 and probably some versions before it used to require 64 bytes.
Bump min value to 64 bytes to be on a safe side.

Boot with 8 byte rng-seed (Linux 6.11):
    # dmesg | grep crng
    [   12.089286] random: crng init done
Boot with 32 byte rng-seed (Linux 6.11):
    # dmesg | grep crng
    [    0.000000] random: crng init done

Linux source references:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c?h=v5.19#n551
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random.c?h=v5.18#n236

Signed-off-by: Alex Shumsky 
Fixes: d2048bafae40 ("rockchip: board: Add board_rng_seed() for all Rockchip devices")
Reviewed-by: Dragan Simic 
Reviewed-by: Marek Vasut 
Reviewed-by: Quentin Schulz 
Reviewed-by: Kever Yang

Add fdt_kaslrseed function to add kaslr-seed to chosen node

2024-06-28T23:30:45+00:00

If RANDOMIZE_BASE is enabled in the Linux kernel instructing it to
randomize the virtual address at which the kernel image is loaded, it
expects entropy to be provided by the bootloader by populating
/chosen/kaslr-seed with a 64-bit value from source of entropy at boot.

Add a fdt_kaslrseed function to accommodate this allowing an existing
node to be overwritten if present. For now use the first rng device
but it would be good to enhance this in the future to allow some sort
of selection or policy in choosing the rng device used.

Signed-off-by: Tim Harvey 
Reviewed-by: Simon Glass 
Cc: Michal Simek 
Cc: Andy Yan 
Cc: Akash Gajjar 
Cc: Ilias Apalodimas 
Cc: Simon Glass 
Cc: Patrick Delaunay 
Cc: Patrice Chotard 
Cc: Devarsh Thakkar 
Cc: Heinrich Schuchardt 
Cc: Hugo Villeneuve 
Cc: Marek Vasut 
Cc: Tom Rini 
Cc: Chris Morgan 
Reviewed-by: Caleb Connolly

boot: Move framebuffer reservation to separate helper

2024-04-21T07:07:02+00:00

Create separate helper for just reserving framebuffer region without
creating or enabling simple-framebuffer node.

This is useful for scenarios where user want to preserve the bootloader
splash screen till OS boots up and display server gets started without
displaying anything else in between and thus not requiring
simple-framebuffer.

Signed-off-by: Devarsh Thakkar 
Reviewed-by: Nikhil M Jain

boot: Move adding initrd earlier in image_setup_libfdt()

2023-12-13T23:39:05+00:00

This may as well happen before the general event is emitted, so move it.
This will allow us to use the livetree for the event part, but the
flattree for the earlier part.

Signed-off-by: Simon Glass

fdt: Improve the comment for fdt_shrink_to_minimum()

2023-12-13T23:39:05+00:00

Add a bit more detail about what this function does.

Signed-off-by: Simon Glass

fdt: Allow use of fdt_support inside if() statements

2023-12-13T16:51:24+00:00

Most of the fdt_support.h header file is included only if OF_LIBFDT or
OF_CONTROL are enabled. This means that calling functions defined in
that file must happen inside an #ifdef

This is unnecessary, so reduce the condition to just !USE_HOSTCC

Signed-off-by: Simon Glass 
Reviewed-by: Tom Rini

fdt_support: add fdt_copy_fixed_partitions function

2023-06-16T09:01:15+00:00

Add a new function fdt_copy_fixed_partitions to copy the fixed
partition nodes from U-Boot device tree to Linux kernel
device tree and to dynamically configure the MTD partitions.

This function fdt_copy_fixed_partitions is only based on device tree
with livetree compatible function and replace the function
fdt_fixup_mtdparts based on mtdparts variable.

Signed-off-by: Patrick Delaunay 
Reviewed-by: Patrice Chotard

ofnode: fdt_support definitions needed if OF_CONTROL is enabled

2023-05-10T20:45:42+00:00

With the use of CONFIG_IS_ENABLED in code, instead of at the preprocessor
level, these defines are still needed if OF_CONTROL is enabled.

Signed-off-by: Troy Kisky 
Reviewed-by: Simon Glass

fdt_support: cosmetic: remove fdt_fixup_nor_flash_size prototype

2022-10-29T13:36:33+00:00

Remove prototype for the removed function fdt_fixup_nor_flash_size.
This patch has no impact as the function is never used.

Fixes: 98f705c9cefd ("powerpc: remove 4xx support")
Signed-off-by: Patrick Delaunay 
Reviewed-by: Simon Glass

fdt_support: add optional board_rng_seed() hook

2022-09-12T12:41:14+00:00

A recurring theme on LKML is the boot process deadlocking due to some
process blocking waiting for random numbers, while the kernel's
Cryptographic Random Number Generator (crng) is not initalized yet,
but that very blocking means no activity happens that would generate
the entropy necessary to finalize seeding the crng.

This is not a problem on boards that have a good hwrng (when the
kernel is configured to trust it), whether in the CPU or in a TPM or
elsewhere. However, that's far from all boards out there. Moreover,
there are consumers in the kernel that try to obtain random numbers
very early, before the kernel has had any chance to initialize any
hwrng or other peripherals.

Allow a board to provide a board_rng_seed() function, which is
responsible for providing a value to be put into the rng-seed property
under the /chosen node.

The board code is responsible for how to actually obtain those
bytes.

- One possibility is for the board to load a seed "file" from
  somewhere (it need not be a file in a filesystem of course), and
  then ensure that that the same seed file does not get used on
  subsequent boots.

  * One way to do that is to delete the file, or otherwise mark it as
    invalid, then rely on userspace to create a new one, and living
    with the possibility of not finding a seed file during some boots.

  * Another is to use the scheme used by systemd-boot and create a new
    seed file immediately, but in a way that the seed passed to the
    kernel and the new (i.e. next) seed cannot be deduced from each
    other, see the explanation at
    https://lore.kernel.org/lkml/20190929090512.GB13049@gardel-login/
    and the current code at
    https://github.com/systemd/systemd/blob/main/src/boot/efi/random-seed.c

- The board may have an hwrng from which some bytes can be read; while
  the kernel can also do that, doing it in U-Boot and providing a seed
  ensures that even very early users in the kernel get good random
  numbers.

- If the board has a sensor of some sort (temperature, humidity, GPS,
  RTC, whatever), mixing in a reading of that doesn't hurt.

- etc. etc.

These can of course be combined.

The rng-seed property is mixed into the pool used by the linux
kernel's CRNG very early during boot. Whether it then actually
contributes towards the kernel considering the CRNG initialized
depends on whether the kernel has been configured with
CONFIG_RANDOM_TRUST_BOOTLOADER (nowadays overridable via the
random.trust_bootloader command line option). But that's for the BSP
developer to ultimately decide.

So, if the board needs to have all that logic, why not also just have
it do the actual population of /chosen/rng-seed in ft_board_setup(),
which is not that many extra lines of code?

I considered that, but decided handling this logically belongs in
fdt_chosen(). Also, apart from saving the board code from the few
lines of boilerplate, doing it in ft_board_setup() is too late for at
least some use cases. For example, I want to allow the board logic to
decide

  ok, let's pass back this buffer and use that as seed, but also let's
  set random.trust_bootloader=n so no entropy is credited.

This requires the rng-seed handling to happen before bootargs
handling. For example, during the very first boot, the board might not
have a proper seed file, but the board could still return (a hash of)
some CPU serial# or whatnot, so that at least no two boards ever get
the same seed - the kernel always mixes in the value passed in
rng-seed, but if it is not "trusted", the kernel would still go
through the same motions as it would if no rng-seed was passed before
considering its CRNG initialized. I.e., by returning that
unique-to-this-board value and setting random.trust_bootloader=n, the
board would be no worse off than if board_rng_seed() returned nothing
at all.

Signed-off-by: Rasmus Villemoes