diff options
Diffstat (limited to 'doc/usage')
-rw-r--r-- | doc/usage/cmd/bootmeth.rst | 2 | ||||
-rw-r--r-- | doc/usage/fit/beaglebone_vboot.rst | 21 | ||||
-rw-r--r-- | doc/usage/fit/signature.rst | 2 | ||||
-rw-r--r-- | doc/usage/fit/source_file_format.rst | 34 | ||||
-rw-r--r-- | doc/usage/measured_boot.rst | 35 | ||||
-rw-r--r-- | doc/usage/netconsole.rst | 55 |
6 files changed, 105 insertions, 44 deletions
diff --git a/doc/usage/cmd/bootmeth.rst b/doc/usage/cmd/bootmeth.rst index 2903977ee54..bac9fdf85cd 100644 --- a/doc/usage/cmd/bootmeth.rst +++ b/doc/usage/cmd/bootmeth.rst @@ -48,7 +48,7 @@ The format looks like this: ===== === ================== ================================= Order Seq Name Description ===== === ================== ================================= - 0 0 extlinunx Extlinux boot from a block device + 0 0 extlinux Extlinux boot from a block device 1 1 efi EFI boot from an .efi file 2 2 pxe PXE boot from a network device 3 3 sandbox Sandbox boot for testing diff --git a/doc/usage/fit/beaglebone_vboot.rst b/doc/usage/fit/beaglebone_vboot.rst index cd6bb141910..1298ba1ae08 100644 --- a/doc/usage/fit/beaglebone_vboot.rst +++ b/doc/usage/fit/beaglebone_vboot.rst @@ -67,18 +67,20 @@ a. Set up the environment variable to point to your toolchain. You will need export CROSS_COMPILE=arm-linux-gnueabi- -b. Configure and build U-Boot with verified boot enabled:: +b. Configure and build U-Boot with verified boot enabled. Note that we use the +am335x_evm target since it covers all boards based on the AM335x evaluation +board:: export UBOOT=/path/to/u-boot cd $UBOOT # You can add -j10 if you have 10 CPUs to make it faster - make O=b/am335x_boneblack_vboot am335x_boneblack_vboot_config all - export UOUT=$UBOOT/b/am335x_boneblack_vboot + make O=b/am335x_evm am335x_evm_config all + export UOUT=$UBOOT/b/am335x_evm c. You will now have a U-Boot image:: - file b/am335x_boneblack_vboot/u-boot-dtb.img - b/am335x_boneblack_vboot/u-boot-dtb.img: u-boot legacy uImage, + file b/am335x_evm/u-boot-dtb.img + b/am335x_evm/u-boot-dtb.img: u-boot legacy uImage, U-Boot 2014.07-rc2-00065-g2f69f8, Firmware/ARM, Firmware Image (Not compressed), 395375 bytes, Sat May 31 16:19:04 2014, Load Address: 0x80800000, Entry Point: 0x00000000, @@ -466,7 +468,7 @@ the private key that you signed with so that it can verify any kernels that you sign:: cd $UBOOT - make O=b/am335x_boneblack_vboot EXT_DTB=${WORK}/am335x-boneblack-pubkey.dtb + make O=b/am335x_evm EXT_DTB=${WORK}/am335x-boneblack-pubkey.dtb Here we are overriding the normal device tree file with our one, which contains the public key. @@ -597,14 +599,11 @@ Further Improvements Several of the steps here can be easily automated. In particular it would be capital if signing and packaging a kernel were easy, perhaps a simple make -target in the kernel. +target in the kernel. A starting point for this is the 'make image.fit' target +for ARM64 in Linux from v6.9 onwards. Some mention of how to use multiple .dtb files in a FIT might be useful. -U-Boot's verified boot mechanism has not had a robust and independent security -review. Such a review should look at the implementation and its resistance to -attacks. - Perhaps the verified boot feature could be integrated into the Amstrom distribution. diff --git a/doc/usage/fit/signature.rst b/doc/usage/fit/signature.rst index 03a71b5192d..b868dcbf9fd 100644 --- a/doc/usage/fit/signature.rst +++ b/doc/usage/fit/signature.rst @@ -15,7 +15,7 @@ that it can be verified using a public key later. Provided that the private key is kept secret and the public key is stored in a non-volatile place, any image can be verified in this way. -See verified-boot.txt for more general information on verified boot. +See :doc:`verified-boot` for more general information on verified boot. Concepts diff --git a/doc/usage/fit/source_file_format.rst b/doc/usage/fit/source_file_format.rst index b2b1e42bd73..15990e3ff54 100644 --- a/doc/usage/fit/source_file_format.rst +++ b/doc/usage/fit/source_file_format.rst @@ -192,13 +192,13 @@ type invalid Invalid Image aisimage Davinci AIS image atmelimage ATMEL ROM-Boot Image - copro Coprocessor Image} + copro Coprocessor Image fdt_legacy legacy Image with Flat Device Tree filesystem Filesystem Image firmware Firmware - firmware_ivt Firmware with HABv4 IVT } + firmware_ivt Firmware with HABv4 IVT flat_dt Flat Device Tree - fpga FPGA Image } + fpga FPGA Device Image (bitstream file, vendor specific) gpimage TI Keystone SPL Image imx8image NXP i.MX8 Boot Image imx8mimage NXP i.MX8M Boot Image @@ -207,31 +207,31 @@ type kernel_noload Kernel Image (no loading done) kwbimage Kirkwood Boot Image lpc32xximage LPC32XX Boot Image - mtk_image MediaTek BootROM loadable Image } + mtk_image MediaTek BootROM loadable Image multi Multi-File Image mxsimage Freescale MXS Boot Image omapimage TI OMAP SPL With GP CH pblimage Freescale PBL Boot Image pmmc TI Power Management Micro-Controller Firmware ramdisk RAMDisk Image - rkimage Rockchip Boot Image } - rksd Rockchip SD Boot Image } - rkspi Rockchip SPI Boot Image } + rkimage Rockchip Boot Image + rksd Rockchip SD Boot Image + rkspi Rockchip SPI Boot Image script Script socfpgaimage Altera SoCFPGA CV/AV preloader socfpgaimage_v1 Altera SoCFPGA A10 preloader - spkgimage Renesas SPKG Image } + spkgimage Renesas SPKG Image standalone Standalone Program - stm32image STMicroelectronics STM32 Image } - sunxi_egon Allwinner eGON Boot Image } - sunxi_toc0 Allwinner TOC0 Boot Image } + stm32image STMicroelectronics STM32 Image + sunxi_egon Allwinner eGON Boot Image + sunxi_toc0 Allwinner TOC0 Boot Image tee Trusted Execution Environment Image ublimage Davinci UBL image vybridimage Vybrid Boot Image x86_setup x86 setup.bin - zynqimage Xilinx Zynq Boot Image } - zynqmpbif Xilinx ZynqMP Boot Image (bif) } - zynqmpimage Xilinx ZynqMP Boot Image } + zynqimage Xilinx Zynq Boot Image + zynqmpbif Xilinx ZynqMP Boot Image (bif) + zynqmpimage Xilinx ZynqMP Boot Image ==================== ================== compression @@ -254,9 +254,6 @@ compression zstd zstd compressed ==================== ================== -data-size - size of the data in bytes - Conditionally mandatory property ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -276,6 +273,9 @@ data-position not relative to the loading of the FIT. This is mandatory if external data used with a fixed address. +data-size + Size of the data in bytes. This is mandatory if external data is used. + os OS name, mandatory for types "kernel". Valid OS names are: diff --git a/doc/usage/measured_boot.rst b/doc/usage/measured_boot.rst index 9691904a9d8..05c439e9ac6 100644 --- a/doc/usage/measured_boot.rst +++ b/doc/usage/measured_boot.rst @@ -7,19 +7,46 @@ U-Boot can perform a measured boot, the process of hashing various components of the boot process, extending the results in the TPM and logging the component's measurement in memory for the operating system to consume. +The functionality is available when booting via the EFI subsystem or 'bootm' +command. + +UEFI measured boot +------------------ + +The EFI subsystem implements the `EFI TCG protocol +<https://trustedcomputinggroup.org/resource/tcg-efi-protocol-specification/>`_ +and the `TCG PC Client Specific Platform Firmware Profile Specification +<https://trustedcomputinggroup.org/resource/pc-client-specific-platform-firmware-profile-specification/>`_ +which defines the binaries to be measured and the corresponding PCRs to be used. + +Requirements +~~~~~~~~~~~~ + +* A hardware TPM 2.0 supported by an enabled U-Boot driver +* CONFIG_EFI_TCG2_PROTOCOL=y +* CONFIG_EFI_TCG2_PROTOCOL_EVENTLOG_SIZE=y +* optional CONFIG_EFI_TCG2_PROTOCOL_MEASURE_DTB=y will measure the loaded DTB + in PCR 1 + +Legacy measured boot +-------------------- + +The commands booti, bootm, and bootz can be used for measured boot +using the legacy entry point of the Linux kernel. + By default, U-Boot will measure the operating system (linux) image, the initrd image, and the "bootargs" environment variable. By enabling -CONFIG_MEASURE_DEVICETREE, U-Boot will also measure the devicetree image. +CONFIG_MEASURE_DEVICETREE, U-Boot will also measure the devicetree image in PCR1. The operating system typically would verify that the hashes found in the TPM PCRs match the contents of the event log. This can further be checked against the hash results of previous boots. Requirements ------------- +~~~~~~~~~~~~ -* A hardware TPM 2.0 supported by the U-Boot drivers -* CONFIG_TPM=y +* A hardware TPM 2.0 supported by an enabled U-Boot driver +* CONFIG_TPMv2=y * CONFIG_MEASURED_BOOT=y * Device-tree configuration of the TPM device to specify the memory area for event logging. The TPM device node must either contain a phandle to diff --git a/doc/usage/netconsole.rst b/doc/usage/netconsole.rst index 2aa3b9ccc59..df27b78342f 100644 --- a/doc/usage/netconsole.rst +++ b/doc/usage/netconsole.rst @@ -3,10 +3,10 @@ Network console In U-Boot, we implemented the networked console via the standard "devices" mechanism, which means that you can switch between the -serial and network input/output devices by adjusting the 'stdin' and -'stdout' environment variables. To switch to the networked console, -set either of these variables to "nc". Input and output can be -switched independently. +serial and network input/output devices by adjusting the 'stdin', +'stdout', and 'stderr' environment variables. To switch to the +networked console, set either of these variables to "nc". Input and +output can be switched independently. The default buffer size can be overridden by setting CFG_NETCONSOLE_BUFFER_SIZE. @@ -18,14 +18,18 @@ broadcast address and port 6666 are used. If it is set to an IP address of 0 (or 0.0.0.0) then no messages are sent to the network. The source / listening port can be configured separately by setting the 'ncinport' environment variable and the destination port can be -configured by setting the 'ncoutport' environment variable. +configured by setting the 'ncoutport' environment variable. Note that +you need to set up the network interface (e.g. using DHCP) before it +can be used for network console. -For example, if your server IP is 192.168.1.1, you could use:: +For example, if your server IP is 192.168.1.1, you could use: - => setenv nc 'setenv stdout nc;setenv stdin nc' - => setenv ncip 192.168.1.1 - => saveenv - => run nc +.. prompt:: bash => + + env set nc 'env set stdout nc; env set stderr nc; env set stdin nc' + env set ncip '192.168.1.1' + env save + run nc On the host side, please use this script to access the console @@ -107,3 +111,34 @@ as follows: Note that unlike the U-Boot implementation the Linux netconsole is unidirectional, i. e. you have console output only in Linux. + +Setup via environment +--------------------- + +If persistent environment is enabled in your U-Boot configuration, you +can configure the network console using the environment. For example: + +.. prompt:: bash => + + env set autoload no + env set hostname "u-boot" + env set bootdelay 5 + env set nc 'dhcp; env set stdout nc; env set stderr nc; env set stdin nc' + env set ncip '192.168.1.1' + env set preboot "${preboot}; run nc;" + env save + reset + +``autoload no`` tells the ``dhcp`` command to configure the network +interface without trying to load an image. ``hostname "u-boot"`` sets +the hostname to be sent in DHCP requests, so they are easy to +recognize in the DHCP server log. The command in ``nc`` calls ``dhcp`` +to make sure the network interface is set up before enabling +netconsole. + +Adding ``nc`` to ``preboot`` tells U-Boot to activate netconsole +before trying to find any boot options, so you can interact with it if +desired. + +``env save`` stores the settings persistently, and ``reset`` then +triggers a fresh start that will use the changed settings. |