[U-Boot] [PATCH 0/2] Add support for booting EFI FIT images

[Heinrich Schuchardt]

On 12/9/19 9:59 AM, Cristian Ciocaltea wrote:
> On Sun, Dec 08, 2019 at 01:25:27AM +0100, Heinrich Schuchardt wrote:
>> On 11/28/19 8:20 AM, Heinrich Schuchardt wrote:
>>> On 11/27/19 8:45 PM, Cristian Ciocaltea wrote:
>>>> On Tue, Nov 26, 2019 at 07:31:39PM +0100, Heinrich Schuchardt wrote:
>>>>> On 11/24/19 9:11 PM, Cristian Ciocaltea wrote:
>>>>>> Currently the only way to run an EFI binary like GRUB2 is via the
>>>>>> 'bootefi' command, which cannot be used in a verified boot scenario.
>>>>>>
>>>>>> The obvious solution to this limitation is to add support for
>>>>>> booting FIT images containing those EFI binaries.
>>>>>>
>>>>>> The implementation relies on a new image type - IH_OS_EFI - which
>>>>>> can be created by using 'os = "efi"' inside an ITS file:
>>>>>>
>>>>>> / {
>>>>>>        #address-cells = <1>;
>>>>>>
>>>>>>        images {
>>>>>>            efi-grub {
>>>>>>                description = "GRUB EFI";
>>>>>>                data = /incbin/("EFI/BOOT/bootarm.efi");
>>>>>>                type = "kernel_noload";
>>>>>>                arch = "arm";
>>>>>>                os = "efi";
>>>>>>                compression = "none";
>>>>>>                load = <0x0>;
>>>>>>                entry = <0x0>;
>>>>>>                hash-1 {
>>>>>>                    algo = "sha256";
>>>>>>                };
>>>>>>            };
>>>>>>        };
>>>>>>
>>>>>>        configurations {
>>>>>>            default = "config-grub";
>>>>>>            config-grub {
>>>>>>                kernel = "efi-grub";
>>>>>>                signature-1 {
>>>>>>                    algo = "sha256,rsa2048";
>>>>>>                    sign-images = "kernel";
>>>>>>                };
>>>>>>            };
>>>>>>        };
>>>>>> };
>>>>>>
>>>>>> The bootm command has been extended to handle the IH_OS_EFI images.
>>>>>> To enable this feature, a new configuration option has been added:
>>>>>> BOOTM_EFI
>>>>>>
>>>>>> I tested the solution using the 'qemu_arm' board:
>>>>>>
>>>>>> => load scsi 0:1 ${kernel_addr_r} efi-image.fit
>>>>>> => bootm ${kernel_addr_r}#config-grub
>>>>>
>>>>> Thanks a lot for the patch series which makes good sense to me.
>>>>>
>>>>> I think we should pass addresses and not strings to cmd/bootefi.c. This
>>>>> will need a bit of refactoring as already addressed in a comment to
>>>>> patch 2/2.
>>>>>
>>>>> Additionally the documentation in doc/uefi/u-boot_on_efi.rst and
>>>>> doc/uImage.FIT/howto.txt should be updated.
>>>>>
>>>>> I cc the contributors given by
>>>>> scripts/get_maintainer.pl -f common/bootm_os.c
>>>>>
>>>>> Best regards
>>>>>
>>>>> Heinrich
>>>>>
>>>>
>>>> Thanks for the feedback, Heinrich!
>>>>
>>>> Instead of creating new function(s), I think we could simply extend
>>>>     int do_bootefi_image(const char *image_opt)
>>>> with a new parameter to hold the fdt address and move here the call
>>>> to 'efi_install_fdt()', which is now performed by 'do_bootefi()'.
>>>
>>> efi_install_fdt() has to be called for the 'bootefi bootmgr' command too
>>> so the refactoring is a bit more complicated. I have started on that.
>>>
>>> The first step is to change efi_install_fdt() to expect the argument as
>>> address instead of a string.
>>>
>>> https://github.com/xypron/u-boot-patches/blob/efi-next/0001-efi_loader-pass-address-to-efi_install_fdt.patch
>>>
>>>
>>> fdt_addr==NULL indicates no device tree supplied by user.
>>>
>>> Best regards
>>>
>>> Heinrich
>>>
>>>>
>>>> However, I'm not sure about changing the data types, i.e. from
>>>> 'char *' to ulong, for the following reasons:
>>>> 1. image_opt may have a different meaning in addition to efi address
>>>> 2. fdt address may not be provided, so we need somehow to detect an >> invalid value
>>>>
>>>> Kind regards,
>>>> Cristian
>>>>
>>
>> Hello Christian,
>>
>> patch series
>> efi_loader: prepare for FIT images
>> https://lists.denx.de/pipermail/u-boot/2019-December/393192.html
>> is now available. It offers these functions:
>>
>> /* Install device tree */
>> efi_status_t efi_install_fdt(uintptr_t fdt_addr);
>> /* Run loaded UEFI image */
>> efi_status_t efi_run_image(void *source_buffer, efi_uintn_t source_size);
>>
>> Could you, please, rebase your patches on this patch series.
>>
>> Please, call efi_install_fdt with EFI_FDT_USE_INTERNAL if no device tree
>> is supplied by the FIT image.
>>
>> The patch series is also available in branch efi-2020-04 at
>> https://gitlab.denx.de/u-boot/custodians/u-boot-efi.git
>>
>> Best regards
>>
>> Heinrich
>
> Hello Heinrich,
>
> Thanks for the patch series!
> I will send the updated patches by latest tomorrow EOD.
>
> You also mentioned updating the documentation in
> doc/uefi/u-boot_on_efi.rst and doc/uImage.FIT/howto.txt.
>
> I've checked those documents and their content is quite generic,
> not particularly related to this work. The former describes
> how to build and run u-boot as an EFI application/payload, while
> the later shows how to build and use FIT images.
>
> If you agree, I could instead add a new ITS file in uImage.FIT folder
> and describe there the new functionality.

Having an example in uImage.Fit will be very helpful. But I still think
the capability to start UEFI binaries via FIT images should be mentioned
in the documentation. Just add a section after "Executing a UEFI binary"
in doc/uefi/uefi.rst, e.g.

Launching a UEFI binary from a FIT image
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A signed FIT image can be used to securely boot a UEFI image via the
bootm command. A sample configuration is provided as file
doc/uImage.FIT/uefi.its. See doc/uImage.FIT/howto.txt for an
introduction to FIT images.

Best regards

Heinrich

>
> Kind regards,
> Cristian
>
>