aboutsummaryrefslogtreecommitdiffstats
path: root/boot
Commit message (Collapse)AuthorAgeFilesLines
* lmb: bootm: remove superfluous lmb stub functionsSughosh Ganu2024-09-031-6/+3
| | | | | | | | | Remove a couple of superfluous LMB stub functions, and instead put a check for calling the lmb_reserve() function. Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
* lmb: remove lmb_init_and_reserve_range() functionSughosh Ganu2024-09-031-14/+1
| | | | | | | | | | | | With the move to make the LMB allocations persistent and the common memory regions being reserved during board init, there is no need for an explicit reservation of a memory range. Remove the lmb_init_and_reserve_range() function. Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* lmb: allow lmb module to be used in SPLSughosh Ganu2024-09-032-3/+3
| | | | | | | | | | | With the introduction of separate config symbols for the SPL phase of U-Boot, the condition checks need to be tweaked so that platforms that enable the LMB module in SPL are also able to call the LMB API's. Use the appropriate condition checks to achieve this. Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
* lmb: make LMB memory map persistent and globalSughosh Ganu2024-09-034-56/+44
| | | | | | | | | | | | | | | | | The current LMB API's for allocating and reserving memory use a per-caller based memory view. Memory allocated by a caller can then be overwritten by another caller. Make these allocations and reservations persistent using the alloced list data structure. Two alloced lists are declared -- one for the available(free) memory, and one for the used memory. Once full, the list can then be extended at runtime. [sjg: Use a stack to store pointer of lmb struct when running lmb tests] Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Signed-off-by: Simon Glass <sjg@chromium.org> [sjg: Optimise the logic to add a region in lmb_add_region_flags()]
* Merge tag 'v2024.10-rc3' into nextTom Rini2024-08-191-4/+3
|\ | | | | | | Prepare v2024.10-rc3
| * boot: set correct block device name in set_efi_bootdev()Heinrich Schuchardt2024-08-111-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | For SATA devices the class name is 'ahci' but the block device name is 'sata'. Use function blk_get_uclass_name() to retrieve the correct string. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org>
* | upl: Plumb in universal payload to the init processSimon Glass2024-08-091-1/+11
| | | | | | | | | | | | | | Read the UPL early in boot so that it is available. For now none of the information is used. Signed-off-by: Simon Glass <sjg@chromium.org>
* | spl: Plumb in the Universal Payload handoffSimon Glass2024-08-091-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | Specify the FIT and include information about each loaded image, as required by the UPL handoff. Write the UPL handoff into the bloblist before jumping to the next phase. Control this using a runtime flag to avoid conflicting with other handoff mechanisms. Signed-off-by: Simon Glass <sjg@chromium.org>
* | upl: Add support for Universal Payload in SPLSimon Glass2024-08-091-0/+32
| | | | | | | | | | | | | | Add the basic code to create a handoff structure in SPL, so it can be passed to the next phase. For now this is not plumbed in. Signed-off-by: Simon Glass <sjg@chromium.org>
* | upl: Add a commandSimon Glass2024-08-091-0/+1
| | | | | | | | | | | | | | Add a 'upl' command to work with Universal Payload features. For now it only supports reading and writing a handoff structure. Signed-off-by: Simon Glass <sjg@chromium.org>
* | upl: Add support for writing a upl handoffSimon Glass2024-08-093-0/+631
| | | | | | | | | | | | | | | | Universal Payload provides a standard way of handing off control between two firmware phases. Add support for writing the handoff information from a structure. Signed-off-by: Simon Glass <sjg@chromium.org>
* | upl: Add support for reading a upl handoffSimon Glass2024-08-095-0/+694
|/ | | | | | | | Universal Payload provides a standard way of handing off control between two firmware phases. Add support for reading the handoff information into a structure. Signed-off-by: Simon Glass <sjg@chromium.org>
* usb: bootm: Drop old USB-device-removal codeSimon Glass2024-07-311-12/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | USB is stopped using driver model now, in dm_remove_devices_flags() in announce_and_cleanup() at the top of this file. The usb_stop() call actually unbinds devices. When a USB device is unbound, it causes any bootflows attached to it to be removed, via a call to bootdev_clear_bootflows() from bootdev_pre_unbind(). This obviously makes it impossible to boot the bootflow. However, when booting a bootflow that relies on USB, usb_stop() is called, which unbinds the device. At that point any information attached to the bootflow is dropped. This is quite risky since the contents of freed memory are not guaranteed to remain unchanged. Depending on what other options are done before boot, a hard-to-find bug may crop up. Drop the call to this old function. Leave the netconsole call there, since this needs conversion to driver model. Signed-off-by: Simon Glass <sjg@chromium.org> Suggested-by: Shantur Rathore <i@shantur.com> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
* boot: provide CONFIG_BOOTMETH_QFW Kconfig parameterHeinrich Schuchardt2024-07-192-1/+10
| | | | | | | | | | | | | | | U-Boot is often used conjunction with QEMU to boot via EFI or syslinux. Here the QFW boot method is not needed. At least for qemu-riscv64_smode_defconfig the kernel parameter is used to specify the U-Boot binary. Trying to run U-Boot as a kernel makes no sense. Provide Kconfig parameter CONFIG_BOOTMETH_QFW to decide if the QFW boot method shall be provided. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* bootstash: Do not provide a default address for allTom Rini2024-07-191-1/+5
| | | | | | | | | A valid memory location to stash bootstage information at will be architecture dependent. Move the existing defaults to the main Kconfig file for this option and set 0x0 as the default only for sandbox. Signed-off-by: Simon Glass <sjg@chromium.org> Signed-off-by: Tom Rini <trini@konsulko.com>
* boot: Correct indentation in efi bootmethSimon Glass2024-07-191-1/+1
| | | | | | | | | Fix a minor indentation / whitespace problem in a comment. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heinrich Schuchardt <xypron.glkp@gmx.de> Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
* bootstd: Correct handling of script from networkSimon Glass2024-07-191-20/+31
| | | | | | | | | When reading a script from a network, no block device is available. Update the implementation to support this correctly, avoiding setting environment variables which relate only to block devices. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
* bootstd: Tidy up comments on the boothmeth driversSimon Glass2024-07-193-2/+3
| | | | | | | | | Fix a typo in the comment and add one to the EFI driver too. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
* doc: Add a description for bootmeth_sandboxSimon Glass2024-07-191-1/+1
| | | | | | | | | | | Add documentation for the sandbox bootmeth. Fix up the compatible string to drop the 'extlinux' part, which is not relevant to this bootmeth. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
* doc: Add a description for bootmeth_qfwSimon Glass2024-07-191-1/+1
| | | | | | | | | | | Add documentation for the qfw bootmeth. Fix up the compatible string to drop the 'extlinux' part, which is not relevant to this bootmeth. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
* Merge patch series "bootstd: Add Android support"Tom Rini2024-07-187-1/+619
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Mattijs Korpershoek <mkorpershoek@baylibre.com> says: Android boot flow is a bit different than a regular Linux distro. Android relies on multiple partitions in order to boot. A typical boot flow would be: 1. Parse the Bootloader Control Block (BCB, misc partition) 2. If BCB requested bootonce-bootloader, start fastboot and wait. 3. If BCB requested recovery or normal android, run the following: a. Get slot (A/B) from BCB b. Run AVB (Android Verified Boot) on boot partitions c. Load boot and vendor_boot partitions d. Load device-tree, ramdisk and boot The AOSP documentation has more details at [1], [2], [3] This has been implemented via complex boot scripts such as [4]. However, these boot script are neither very maintainable nor generic. Moreover, DISTRO_DEFAULTS is being deprecated [5]. Add a generic Android bootflow implementation for bootstd. For this initial version, only boot image v4 is supported. This has been tested on sandbox using: $ ./test/py/test.py --bd sandbox --build -k test_ut This has also been tested on the AM62X SK EVM using TI's Android SDK[6] To test on TI board, the following (WIP) patch is needed as well: https://gitlab.baylibre.com/baylibre/ti/ti-u-boot/-/commit/84cceb912bccd7cdd7f9dd69bca0e5d987a1fd04 [1] https://source.android.com/docs/core/architecture/bootloader [2] https://source.android.com/docs/core/architecture/partitions [3] https://source.android.com/docs/core/architecture/partitions/generic-boot [4] https://source.denx.de/u-boot/u-boot/-/blob/master/include/configs/meson64_android.h [5] https://lore.kernel.org/r/all/20230914165615.1058529-17-sjg@chromium.org/ [6] https://software-dl.ti.com/processor-sdk-android/esd/AM62X/09_02_00/docs/android/Overview.html
| * bootstd: Add a bootmeth for AndroidMattijs Korpershoek2024-07-184-0/+601
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Android boot flow is a bit different than a regular Linux distro. Android relies on multiple partitions in order to boot. A typical boot flow would be: 1. Parse the Bootloader Control Block (BCB, misc partition) 2. If BCB requested bootonce-bootloader, start fastboot and wait. 3. If BCB requested recovery or normal android, run the following: 3.a. Get slot (A/B) from BCB 3.b. Run AVB (Android Verified Boot) on boot partitions 3.c. Load boot and vendor_boot partitions 3.d. Load device-tree, ramdisk and boot The AOSP documentation has more details at [1], [2], [3] This has been implemented via complex boot scripts such as [4]. However, these boot script are neither very maintainable nor generic. Moreover, DISTRO_DEFAULTS is being deprecated [5]. Add a generic Android bootflow implementation for bootstd. For this initial version, only boot image v4 is supported. [1] https://source.android.com/docs/core/architecture/bootloader [2] https://source.android.com/docs/core/architecture/partitions [3] https://source.android.com/docs/core/architecture/partitions/generic-boot [4] https://source.denx.de/u-boot/u-boot/-/blob/master/include/configs/meson64_android.h [5] https://lore.kernel.org/r/all/20230914165615.1058529-17-sjg@chromium.org/ Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Julien Masson <jmasson@baylibre.com> Tested-by: Guillaume La Roque <glaroque@baylibre.com> Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
| * bootstd: Add bootflow_iter_check_mmc() helperMattijs Korpershoek2024-07-181-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | Some bootflows might be able to only boot from MMC devices. Add a helper function these bootflows can use. Reviewed-by: Igor Opaniuk <igor.opaniuk@gmail.com> Reviewed-by: Julien Masson <jmasson@baylibre.com> Reviewed-by: Guillaume La Roque <glaroque@baylibre.com> Tested-by: Guillaume La Roque <glaroque@baylibre.com> Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * boot: android: Provide vendor_bootimg_addr in boot_get_fdt()Mattijs Korpershoek2024-07-182-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When calling android_image_get_dtb_by_index() using boot image v3+, we should also pass the vendor_boot ramdisk address. Use get_avendor_bootimg_addr() to do so. Notes: on boot image v2, this is harmless since get_avendor_bootimg_addr() returns -1. for legacy implementations that don't have CMD_ABOOTIMG, add a weak implementation to avoid linking errors. Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Julien Masson <jmasson@baylibre.com> Reviewed-by: Igor Opaniuk <igor.opaniuk@gmail.com> Reviewed-by: Guillaume La Roque <glaroque@baylibre.com> Tested-by: Guillaume La Roque <glaroque@baylibre.com> Signed-off-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
* | Merge patch series "Respin bootstd cros patch into a series of two"Tom Rini2024-07-181-1/+1
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Vincent Stehlé <vincent.stehle@arm.com> says: Hi, This is a respin of this patch [1] after discussion [2]. Thanks to Simon and Heinrich for their reviews. To use the guidcmp() function, as suggested by Heinrich, we need to make it available to bootmeth_cros.c and I think that the cleanest way to do that is (arguably) to move the guid helper functions to efi.h near the efi_guid_t definition; this is why the original patch has now become a series of two patches. The alternative would be to include efi_loader.h from bootmeth_cros.c but I think this does not sound "right". If this is in fact the preferred approach just let me know and I will respin. There is no difference in the sandbox binaries before/after this series on Arm and on PC, and all the tests I have run on the sandbox are unchanged.
| * | bootstd: cros: store partition type in an efi_guid_tVincent Stehlé2024-07-161-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The scan_part() function uses a struct uuid to store the little-endian partition type GUID, but this structure should be used only to contain a big-endian UUID. Use an efi_guid_t instead and use guidcmp() for the comparison. Suggested-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com> Cc: Simon Glass <sjg@chromium.org> Cc: Tom Rini <trini@konsulko.com>
* | | boot: Remove duplicate newlinesMarek Vasut2024-07-151-1/+0
| | | | | | | | | | | | | | | | | | Drop all duplicate newlines. No functional change. Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
* | | Merge patch series "Add Turris 1.x board"Tom Rini2024-07-121-1/+1
|\ \ \ | |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Marek Mojík <marek.mojik@nic.cz> says: Hello all, this is a continuation of previous work by Pali to add support for the Turris 1.x board. As the patches were based on u-boot v2022.04, a nontrivial rebasing was needed. Some notes: - Some options that are in SD defconfig are disabled in NOR defconfig because over the years u-boot grew and the old NOR defconfig will not fit into NOR memory. - SD boot with RAM larger than 2GB will only allocate 2GB of RAM (We were not able to fix this yet)
| * | powerpc: Add support for CZ.NIC Turris 1.x routersPali Rohár2024-07-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for CZ.NIC Turris 1.x routers. CZ.NIC Turris 1.0 (RTRS01) and 1.1 (RTRS02) are open source routers, they have dual-core PowerPC Freescale P2020 CPU and are based on reference Freescale P2020RDB-PC-A board design. Hardware design is fully open source, all firmware and hardware design files are available at Turris project website: https://docs.turris.cz/hw/turris-1x/turris-1x/ https://project.turris.cz/en/hardware.html The P2020 BootROM can load U-Boot either from NOR flash or from SD card. We add the new defconfigs, turris_1x_nor_defconfig, which configures U-Boot for building the NOR image, and turris_1x_sdcard_defconfig, which configures U-Boot for building an image suitable for SD card. The defconfig for NOR image is stripped-down a - many config options enabled in SD defconfig are disabled for NOR defconfig. This is because U-Boot grew non-trivially in the last two years and it would not fit into the space allocated for U-Boot in the NOR memory. In the future we may try to use LTO to reduce the size of the code and enable more options. The design of CZ.NIC Turris 1.x routers is based on Freescale P2020RDB-PC-A board, so some code from boards/freescale/p1_p2_rdb_pc is used and linked into Turris 1.x board code. Turris 1.x code in this patch uses modern distroboot and can boot Linux kernel from various locations, including NAND, SD card, USB flash disks, NVMe disks or SATA disks (connected to extra SATA/SCSI PCIe controllers). Via distroboot is implemented also rescue NOR boot for factory recovery, triggered by reset button, like on other existing Turris routers. SD boot with RAM larger than 2GB will only allocate 2GB of RAM (We were not able to fix this yet) [ Because various CONFIG_ macros were migrated to Kconfig since the last time this worked on upstream U-Boot (in 2022), a non-trivial rebasing was needed and some issues were solved. ] Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Marek Mojík <marek.mojik@nic.cz> Reviewed-by: Marek Behún <kabel@kernel.org>
| * | Restore patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"WIP/20May2024-nextTom Rini2024-05-2043-43/+6
| | | | | | | | | | | | | | | | | | | | | | | | As part of bringing the master branch back in to next, we need to allow for all of these changes to exist here. Reported-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Tom Rini <trini@konsulko.com>
* | | Fix Kconfig coding style from spaces to tabAnand Moon2024-07-051-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | Adjust indentation from spaces to tab (+optional two spaces) as in coding style with command like: $ sed -e 's/^ /\t/' -i */Kconfig Signed-off-by: Anand Moon <linux.amoon@gmail.com>
* | | cmd: bootm: add ELF file supportMaxim Moskalets2024-07-053-2/+24
| | | | | | | | | | | | | | | | | | | | | | | | Some operating systems (e.g. seL4) and embedded applications are ELF images. It is convenient to use FIT-images to implement trusted boot. Added "elf" image type for booting using bootm command. Signed-off-by: Maxim Moskalets <maximmosk4@gmail.com>
* | | bootstd: cros: store partition type in an efi_guid_tVincent Stehlé2024-07-031-2/+2
| |/ |/| | | | | | | | | | | | | | | | | | | The scan_part() function uses a struct uuid to store the little-endian partition type GUID, but this structure should be used only to contain a big-endian UUID. Use an efi_guid_t instead. Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com> Cc: Simon Glass <sjg@chromium.org> Cc: Tom Rini <trini@konsulko.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* | Merge tag 'efi-2024-10-rc1' of ↵WIP/30Jun2024-nextTom Rini2024-06-302-0/+5
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://source.denx.de/u-boot/custodians/u-boot-efi into next Pull request efi-2024-10-rc1 Documentation: Update requirements.txt to use current Python module versions Add a page describing debugging U-Boot with GDB FIT: describe data-size as a conditionally mandatory property Correct link to FIT specification in SPL code. Correct kaslrseed command long text description UEFI: Add unit test checking that don't have kaslr-seed when measuring boot Deduplicate code for measured boot. Other: Print size information in fwu command
| * | tpm: allow the user to select the compiled algorithmsIlias Apalodimas2024-06-301-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Simon reports that after enabling all algorithms on the TPM some boards fail since they don't have enough storage to accommodate the ~5KB growth. The choice of hash algorithms is determined by the platform and the TPM configuration. Failing to cap a PCR in a bank which the platform left active is a security vulnerability. It might allow unsealing of secrets if an attacker can replay a good set of measurements into an unused bank. If MEASURED_BOOT or EFI_TCG2_PROTOCOL is enabled our Kconfig will enable all supported hashing algorithms. We still want to allow users to add a TPM and not enable measured boot via EFI or bootm though and at the same time, control the compiled algorithms for size reasons. So let's add a function tpm2_allow_extend() which checks the TPM active PCRs banks against the one U-Boot was compiled with. We only allow extending PCRs if the algorithms selected during build match the TPM configuration. It's worth noting that this is only added for TPM2.0, since TPM1.2 is lacking a lot of code at the moment to read the available PCR banks. We unconditionally enable SHA1 when a TPM is selected, which is the only hashing algorithm v1.2 supports. Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> # chromebook-link
| * | tpm: Move TCG headers into a separate fileIlias Apalodimas2024-06-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | commit 97707f12fdab ("tpm: Support boot measurements") moved out code from the EFI subsystem into the TPM one to support measurements when booting with !EFI. Those were moved directly into the TPM subsystem and in the tpm-v2.c library. In hindsight, it would have been better to move it in new files since the TCG2 is governed by its own spec, it's overeall cleaner and also easier to enable certain parts of the TPM functionality. So let's start moving the headers in a new file containing the TCG specific bits. Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
* | | Merge patch series "automatically add /chosen/kaslr-seed and deduplicate code"WIP/28Jun2024-nextTom Rini2024-06-282-33/+54
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tim Harvey <tharvey@gateworks.com> says: This series will automatically add /chosen/kaslr-seed to the dt if DM_RNG is enabled during the boot process. 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. If we have DM_RNG enabled populate this value automatically when fdt_chosen is called. We skip this if ARMV8_SEC_FIRMWARE_SUPPORT is enabled as its implementation uses a different source of entropy 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 overwrite the node 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. Note that the kalsrseed command (CMD_KASLRSEED) is likely pointless now but left in place in case boot scripts exist that rely on this command existing and returning success. An informational message is printed to alert users of this command that it is likely no longer needed. Note that the Kernel's EFI STUB only relies on EFI_RNG_PROTOCOL for randomization and completely ignores the kaslr-seed for its own randomness needs (i.e the randomization of the physical placement of the kernel). It gets weeded out from the DTB that gets handed over via efi_install_fdt() as it would also mess up the measured boot DTB TPM measurements as well.
| * | use fdt_kaslrseed function to de-duplicate codeTim Harvey2024-06-281-33/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Use the fdt_kaslrseed function to deduplicate code doing the same thing. Note that the kalsrseed command (CMD_KASLRSEED) is likely pointless now but left in place in case boot scripts exist that rely on this command existing and returning success. An informational message is printed to alert users of this command that it is likely no longer needed. Note that the Kernel's EFI STUB only relies on EFI_RNG_PROTOCOL for randomization and completely ignores the kaslr-seed for its own randomness needs (i.e the randomization of the physical placement of the kernel). It gets weeded out from the DTB that gets handed over via efi_install_fdt() as it would also mess up the measured boot DTB TPM measurements as well. Signed-off-by: Tim Harvey <tharvey@gateworks.com> Reviewed-by: Simon Glass <sjg@chromium.org> Cc: Michal Simek <michal.simek@amd.com> Cc: Andy Yan <andy.yan@rock-chips.com> Cc: Akash Gajjar <gajjar04akash@gmail.com> Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org> Cc: Simon Glass <sjg@chromium.org> Cc: Patrick Delaunay <patrick.delaunay@foss.st.com> Cc: Patrice Chotard <patrice.chotard@foss.st.com> Cc: Devarsh Thakkar <devarsht@ti.com> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Hugo Villeneuve <hvilleneuve@dimonoff.com> Cc: Marek Vasut <marex@denx.de> Cc: Tom Rini <trini@konsulko.com> Cc: Chris Morgan <macromorgan@hotmail.com> Acked-by: Michal Simek <michal.simek@amd.com>
| * | fdt: automatically add /chosen/kaslr-seed if DM_RNG is enabledTim Harvey2024-06-281-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. If we have DM_RNG enabled populate this value automatically when fdt_chosen is called. We skip this if ARMV8_SEC_FIRMWARE_SUPPORT is enabled as its implementation uses a different source of entropy 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). Note that the Kernel's EFI STUB only relies on EFI_RNG_PROTOCOL for randomization and completely ignores the kaslr-seed for its own randomness needs (i.e the randomization of the physical placement of the kernel). It gets weeded out from the DTB that gets handed over via efi_install_fdt() as it would also mess up the measured boot DTB TPM measurements as well. Signed-off-by: Tim Harvey <tharvey@gateworks.com> Reviewed-by: Simon Glass <sjg@chromium.org> Cc: Michal Simek <michal.simek@amd.com> Cc: Andy Yan <andy.yan@rock-chips.com> Cc: Akash Gajjar <gajjar04akash@gmail.com> Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org> Cc: Simon Glass <sjg@chromium.org> Cc: Patrick Delaunay <patrick.delaunay@foss.st.com> Cc: Patrice Chotard <patrice.chotard@foss.st.com> Cc: Devarsh Thakkar <devarsht@ti.com> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Hugo Villeneuve <hvilleneuve@dimonoff.com> Cc: Marek Vasut <marex@denx.de> Cc: Tom Rini <trini@konsulko.com> Cc: Chris Morgan <macromorgan@hotmail.com>
| * | Add fdt_kaslrseed function to add kaslr-seed to chosen nodeTim Harvey2024-06-281-0/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <tharvey@gateworks.com> Reviewed-by: Simon Glass <sjg@chromium.org> Cc: Michal Simek <michal.simek@amd.com> Cc: Andy Yan <andy.yan@rock-chips.com> Cc: Akash Gajjar <gajjar04akash@gmail.com> Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org> Cc: Simon Glass <sjg@chromium.org> Cc: Patrick Delaunay <patrick.delaunay@foss.st.com> Cc: Patrice Chotard <patrice.chotard@foss.st.com> Cc: Devarsh Thakkar <devarsht@ti.com> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de> Cc: Hugo Villeneuve <hvilleneuve@dimonoff.com> Cc: Marek Vasut <marex@denx.de> Cc: Tom Rini <trini@konsulko.com> Cc: Chris Morgan <macromorgan@hotmail.com> Reviewed-by: Caleb Connolly <caleb.connolly@linaro.org>
* | | pxe: Add debugging for bootingSimon Glass2024-06-261-4/+11
| | | | | | | | | | | | | | | | | | | | | Show which boot protocol is being used. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Michael Trimarchi <michael@amarulasolutions.com>
* | | Merge tag 'v2024.07-rc5' into nextWIP/24Jun2024-nextTom Rini2024-06-242-4/+4
|\| | | | | | | | | | | Prepare v2024.07-rc5
| * | boot: links to FIT documentation in KconfigHeinrich Schuchardt2024-06-221-3/+3
| | | | | | | | | | | | | | | | | | Correct the links to the FIT documentation in boot/Kconfig. Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
| * | tpm: measure DTB in PCR1 instead of PCR0Ilias Apalodimas2024-06-161-1/+1
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The PC client spec [0], doesn't describe measurements for DTBs. It does describe what do to for ACPI tables though. There is a description for ACPI in 3.3.4.1 PCR[0] – SRTM, POST BIOS, and Embedded Drivers and they explicitly mention ACPI in there. There's no mention of ACPI in 3.3.4.2 PCR[1] – Host Platform Configuration. However, in Figure 6 -- PCR Mapping of UEFI Components ACPI is shown in PCR1. The general description also mentions PCR0 is for code and PCR1 is for data such as ACPI and SMBIOS. So let's switch over the DTB measurements to PCR1 which seems a better fit. [0] https://trustedcomputinggroup.org/resource/pc-client-specific-platform-firmware-profile-specification Reported-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Reviewed-by: Eddie James <eajames@linux.ibm.com>
| * Revert "Merge patch series "arm: dts: am62-beagleplay: Fix Beagleplay Ethernet""Tom Rini2024-05-1943-6/+43
| | | | | | | | | | | | | | | | | | | | | | | | When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"' I failed to notice that b4 noticed it was based on next and so took that as the base commit and merged that part of next to master. This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35. Reported-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Tom Rini <trini@konsulko.com>
* | boot: bootflow_menu: fix crash for EFI BOOTMGR global bootmethQuentin Schulz2024-06-201-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | The global bootmeths don't set the dev in bootflow struct which means the dev_get_parent(bflow->dev) triggers a NULL-pointer dereference and crash U-Boot. So before trying to handle a bootflow, check that the associated bootmeth isn't global, otherwise skip it. Suggested-by: Simon Glass <sjg@chromium.org> Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Simon Glass <sjg@chromium.org>
* | boot: fix typos in help text of Kconfig configsQuentin Schulz2024-06-201-11/+11
| | | | | | | | | | | | | | This fixes a handful of typos in various help texts in Kconfig configs. Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de> Reviewed-by: Simon Glass <sjg@chromium.org>
* | Merge tag 'efi-next-20240611' of ↵WIP/11Jun2024-nextTom Rini2024-06-111-58/+2
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | https://source.denx.de/u-boot/custodians/u-boot-efi into next Pull request efi-next-20240611 UEFI: * Allow specifying a device-tree in an EFI load option using the efidebug or eficonfig command. * Let the EFI boot manager fall back to an OS provided device-tree if no device-tree is specified.
| * | efi_loader: move distro_efi_get_fdt_name()Heinrich Schuchardt2024-06-101-58/+2
| | | | | | | | | | | | | | | | | | | | | | | | Move distro_efi_get_fdt_name() to a separate C module and rename it to efi_get_distro_fdt_name(). Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
* | | abootimg: Add init_boot image supportRoman Stratiienko2024-06-071-3/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Quote from [1]: "For devices launching with Android 13, the generic ramdisk is removed from the boot image and placed in a separate init_boot image. This change leaves the boot image with only the GKI kernel." While at it, update wrong error handling message when vendor_boot cannot be loaded. [1]: https://source.android.com/docs/core/architecture/partitions/generic-boot Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com> Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com>
generated by cgit (git 2.34.1) at 2025-02-27 01:53:30 +0000