public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Matthias Brugger <matthias.bgg@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] rpi3: Enable verified boot from FIT image
Date: Fri, 6 Sep 2019 12:05:29 +0200	[thread overview]
Message-ID: <c31b2b62-7ce6-96bf-7f93-d2c21ed17079@gmail.com> (raw)
In-Reply-To: <CABymUCOnW-vAAGTkVC-BfkUukJy7cCm8g7CTowfRT2yENCLnhA@mail.gmail.com>



On 03/09/2019 09:12, Jun Nie wrote:
> Heinrich Schuchardt <xypron.glpk@gmx.de> 于2019年9月2日周一 下午7:19写道:
>>
>> On 9/2/19 12:30 PM, Matthias Brugger wrote:
>>> +Alex, Lukas, Heinrich, Bin and Simon
>>>
>>> On 31/07/2019 10:16, Jun Nie wrote:
>>>> Matthias Brugger <mbrugger@suse.com> 于2019年7月31日周三 下午4:05写道:
>>>>>
>>>>>
>>>>>
>>>>> On 11/07/2019 05:55, Jun Nie wrote:
>>>>>> Enable verified boot from FIT image with select configs
>>>>>> and specify boot script image node in FIT image, the FIT
>>>>>> image is verified before it is run.
>>>>>>
>>>>>> Code that reusing dtb in firmware is disabled, so that
>>>>>> the dtb with pubic key packed in u-boot.bin can be used
>>>>>> to verify the signature of next stage FIT image.
>>>>>>
>>>>>> Signed-off-by: Jun Nie <jun.nie@linaro.org>
>>>>>> ---
>>>>>>   board/raspberrypi/rpi/rpi.c |  6 ++++++
>>>>>>   include/configs/rpi.h       | 15 ++++++++++++++-
>>>>>>   2 files changed, 20 insertions(+), 1 deletion(-)
>>>>>>
>>>>>> diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c
>>>>>> index 617c892..950ee84 100644
>>>>>> --- a/board/raspberrypi/rpi/rpi.c
>>>>>> +++ b/board/raspberrypi/rpi/rpi.c
>>>>>> @@ -297,6 +297,7 @@ static void set_fdtfile(void)
>>>>>>        env_set("fdtfile", fdtfile);
>>>>>>   }
>>>>>>
>>>>>> +#ifndef CONFIG_FIT_SIGNATURE
>>>>>>   /*
>>>>>>    * If the firmware provided a valid FDT at boot time, let's expose it in
>>>>>>    * ${fdt_addr} so it may be passed unmodified to the kernel.
>>>>>> @@ -311,6 +312,7 @@ static void set_fdt_addr(void)
>>>>>>
>>>>>>        env_set_hex("fdt_addr", fw_dtb_pointer);
>>>>>>   }
>>>>>> +#endif
>>>>>>
>>>>>>   /*
>>>>>>    * Prevent relocation from stomping on a firmware provided FDT blob.
>>>>>> @@ -393,7 +395,9 @@ static void set_serial_number(void)
>>>>>>
>>>>>>   int misc_init_r(void)
>>>>>>   {
>>>>>> +#ifndef CONFIG_FIT_SIGNATURE
>>>>>>        set_fdt_addr();
>>>>>> +#endif
>>>>>>        set_fdtfile();
>>>>>>        set_usbethaddr();
>>>>>>   #ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
>>>>>> @@ -470,6 +474,7 @@ int board_init(void)
>>>>>>        return bcm2835_power_on_module(BCM2835_MBOX_POWER_DEVID_USB_HCD);
>>>>>>   }
>>>>>>
>>>>>> +#ifndef CONFIG_FIT_SIGNATURE
>>>>>>   /*
>>>>>>    * If the firmware passed a device tree use it for U-Boot.
>>>>>>    */
>>>>>> @@ -479,6 +484,7 @@ void *board_fdt_blob_setup(void)
>>>>>>                return NULL;
>>>>>>        return (void *)fw_dtb_pointer;
>>>>>>   }
>>>>>> +#endif
>>>>>
>>>>> Just to get this clear we need this because we want to pass the device tree via
>>>>> OF_SEPARATE, correct?
>>>>
>>>> You are right.  U-boot need to read he signature from dtb.
>>>>
>>>>>
>>>>>>
>>>>>>   int ft_board_setup(void *blob, bd_t *bd)
>>>>>>   {
>>>>>> diff --git a/include/configs/rpi.h b/include/configs/rpi.h
>>>>>> index f76c7d1..ba91205 100644
>>>>>> --- a/include/configs/rpi.h
>>>>>> +++ b/include/configs/rpi.h
>>>>>> @@ -180,11 +180,24 @@
>>>>>>
>>>>>>   #include <config_distro_bootcmd.h>
>>>>>>
>>>>>> +#ifdef CONFIG_FIT_SIGNATURE
>>>>>> +#define FIT_BOOT_CMD                                                 \
>>>>>> +     "boot_a_script="                                                \
>>>>>> +             "load ${devtype} ${devnum}:${distro_bootpart} "         \
>>>>>> +                     "${scriptaddr} ${prefix}${script}; "            \
>>>>>> +             "iminfo ${scriptaddr};"                                 \
>>>>>> +             "if test $? -eq 1; then reset; fi;"                     \
>>>>>> +             "source ${scriptaddr}:bootscr\0"
>>>>>> +#else
>>>>>> +#define FIT_BOOT_CMD ""
>>>>>> +#endif
>>>>>> +
>>>>>
>>>>> Doesn't this overwrite the boot_a_script in distro_bootcmd?
>>>>>
>>>>> Would it make sense to add FIT booting to the distro boot command?
>>>>>
>>>>> Regards,
>>>>> Matthias
>>>>
>>>> Yes, it overwrite the boot_a_script in distro_bootcmd. It is make
>>>> sense to add this to the distro boot command. I can send another patch
>>>> to move these lines to common code later.
>>>>
>>>
>>> Question to the people just added, as you have relevant submission to
>>> distroboot. Do you think it makes sense to add FIT_BOOT_CMD to that?
>>>
>>> Regards,
>>> Matthias
>>
>> The idea of distro-boot was to make it easier for Linux distributions to
>> update the information needed by U-Boot to find the right kernel and
>> ramdisk.
>>
>> According to doc/README.distro file extlinux.conf should be used for the
>> communication between the distribution and U-Boot. Some distributions
>> like Debian still rely on boot.scr.
>>
>> Many distributions (OpenBSD, FreeBSD, Suse, Fedora) have moved from
>> distro-boot to UEFI as booting standard. Unfortunately we have not
>> documented our support for this in doc/README.distro (TODO for me).
>> Takahiro is working on secure boot using UEFI. Once completed this could
>> obsolete FIT images.
>>
>> Would we expect Linux distributions to provide FIT images upon kernel
>> updates?
>> Is there any Linux distribution doing so?
> 
> Embedded Linux, a new distribution from ARM, is using FIT images to
> update kernel.
> https://os.mbed.com/docs/mbed-linux-os/v0.8/welcome/index.html
> 

Ok, so secure boot does not provide all capabilities that FIT images do and
there exists a distro which uses FIT images.
I think that's enough to add FIT_BOOT_CMD to distro_boot.

So please do so. Sorry that this has taken longer then expected.

Regards,
Matthias

  reply	other threads:[~2019-09-06 10:05 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-11  3:55 [U-Boot] [PATCH] rpi3: Enable verified boot from FIT image Jun Nie
2019-07-26 14:23 ` Jun Nie
     [not found] ` <630dc300-b668-d20e-62e5-314fa88e1985@suse.com>
2019-07-31  8:16   ` Jun Nie
2019-08-08  4:08     ` Jun Nie
2019-09-02 10:30     ` Matthias Brugger
2019-09-02 11:19       ` Heinrich Schuchardt
2019-09-02 23:45         ` AKASHI Takahiro
2019-09-03  7:12         ` Jun Nie
2019-09-06 10:05           ` Matthias Brugger [this message]
2019-09-06 21:04         ` Simon Glass
2019-09-06 22:41           ` Heinrich Schuchardt
2019-09-17  5:48             ` Simon Glass
2019-09-02  8:12 ` Jun Nie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c31b2b62-7ce6-96bf-7f93-d2c21ed17079@gmail.com \
    --to=matthias.bgg@gmail.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox