| 5905ccea | 11-Sep-2023 |
Rasmus Villemoes <rasmus.villemoes@prevas.dk> |
UPSTREAM: fdt_support: add optional board_rng_seed() hook
A recurring theme on LKML is the boot process deadlocking due to some
process blocking waiting for random numbers, while the kernel's
Crypto
UPSTREAM: fdt_support: add optional board_rng_seed() hook
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 <rasmus.villemoes@prevas.dk>
(cherry picked from commit 6dca1d9ad38de9b7f9a44d2c6eaa6acf9be6c2c0)
Change-Id: I9838bccc384ff6d52505ed48815f8e599f0a7ee1
Signed-off-by: Joseph Chen <chenjh@rock-chips.com>
show more ...
|
| 7778b3e6 | 01-Aug-2023 |
William Wu <william.wu@rock-chips.com> |
usb: hub: Add retry for usb scan device
Some USB3.0 Disks fails to accept new address if
run at high speed. Test on RK3568/RK3588 USB3.0
host port with USB2.0 Type-A plug to USB2.0 Type-A
receptacle
usb: hub: Add retry for usb scan device
Some USB3.0 Disks fails to accept new address if
run at high speed. Test on RK3568/RK3588 USB3.0
host port with USB2.0 Type-A plug to USB2.0 Type-A
receptacle connector, we can reproduce this problem
with the following USB3.0 Disks:
1. idVendor=0930, idProduct=1408, Manufacturer: TOSHIBA
2. idVendor=0951, idProduct=1666, Manufacturer: Kingston
With this patch, it tries to do port reset and scan
device again if device not accepting new address.
Test on RK3588 EVB with this patch:
=> usb start
starting USB...
Bus usb@fc000000: usb maximum-speed not found
Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
Bus usb@fc800000: USB EHCI 1.00
Bus usb@fc840000: USB OHCI 1.0
Bus usb@fc880000: USB EHCI 1.00
Bus usb@fc8c0000: USB OHCI 1.0
Bus usb@fc400000: usb maximum-speed not found
Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.10
scanning bus usb@fc000000 for devices... 1 USB Device(s) found
scanning bus usb@fc800000 for devices... 1 USB Device(s) found
scanning bus usb@fc840000 for devices... 1 USB Device(s) found
scanning bus usb@fc880000 for devices... 1 USB Device(s) found
scanning bus usb@fc8c0000 for devices... 1 USB Device(s) found
scanning bus usb@fc400000 for devices... Device not responding to set address.
USB device not accepting new address (error=80000000)
GUID Partition Table Header signature is wrong: 0x4B4F504D != 0x5452415020494645
2 USB Device(s) found
scanning usb for storage devices... 1 Storage Device(s) found
Change-Id: Ibf55ae213365e07f0c74979cd02331b8933737dd
Signed-off-by: William Wu <william.wu@rock-chips.com>
show more ...
|