[U-Boot] [PATCH v2 0/11] Minor improvements to secure boot and enable on beaglebone

Simon Glass sjg at chromium.org
Tue Jun 3 06:42:55 CEST 2014


Hi Belisko,

On 28 April 2014 00:30, Belisko Marek <marek.belisko at gmail.com> wrote:
> Hi Simon,
>
> On Wed, Apr 16, 2014 at 4:41 PM, Simon Glass <sjg at chromium.org> wrote:
>> This series fixes a few problems that have come up since the secure boot
>> series was merged:
>>
>> - A recent commit broken the assumption that u-boot.bin ends at a known
>> address (thus making things appended to U-Boot inaccessible from the code).
>> This is fixed for Beaglebone and also a new test is added to the Makefile
>> to ensure that it does not break again. All boards have been tested.
>>
>> - A way is needed to provide an externally-build device tree binary for
>> U-Boot. This allows signing to happen outside the U-Boot build system.
>>
>> - The .img files generated by an OMAP build need to include the FDT if one
>> is appended.
>>
>> - Adding signatures to an FDT can cause the FDT to run out of space. The
>> fix is to regenerate the FDT from scratch with different dtc parameters, so
>> pretty painful. Instead, we automatically expand the FDT.
>>
>> The last two commits enable secure boot on Beaglebone (this will have no
>> effect unless signed images are used). This could be moved to a separate
>> configuration if required, or these patches could even be ignored:
> I've tested this patch series and I found some issues. When I use dtb
> build from latest 3.15-rc3 kernel
> I got during signing this errors:
> Couldn't create signature node: FDT_ERR_NOSPACE
> Failed to add verification data for 'signature at 1' signature node in
> 'conf at 1' image node
>
> which was fixed by those 2 small patches:
> - this one doesn't overwrite return value because upper layer then
> stop with no space error and doesn't allocate more space
> --- a/lib/rsa/rsa-sign.c
> +++ b/lib/rsa/rsa-sign.c
> @@ -405,7 +405,7 @@ int rsa_add_verify_data(struct image_sign_info
> *info, void *keydest)
>                 if (parent < 0) {
>                         fprintf(stderr, "Couldn't create signature node: %s\n",
>                                 fdt_strerror(parent));
> -                       return -EINVAL;
> +                       return parent;
>                 }
>         }
>
> --- a/tools/image-host.c
> +++ b/tools/image-host.c
> @@ -612,7 +612,7 @@ static int fit_config_process_sig(const char
> *keydir, void *keydest,
>                 if (ret) {
>                         printf("Failed to add verification data for
> '%s' signature node in '%s' image node\n",
>                                node_name, conf_name);
> -                       return ret == FDT_ERR_NOSPACE ? -ENOSPC : -EIO;
> +                       return ret == -FDT_ERR_NOSPACE ? -ENOSPC : -EIO;
>                 }
>         }
>
> With this small changes I can create signed fit image. Other problem
> appear during booting. I'm using simple uEnv.txt
> to get fit image to ram and boot (setenv loadaddr '0x8050000'; run
> loadimage; bootm). Booting of kernel fails with data abort:
>
> Importing environment from mmc ...
> Running uenvcmd ...
> reading /uImage
> 4322274 bytes read in 585 ms (7 MiB/s)
> ## Loading kernel from FIT Image at 80500000 ...
>    Using 'conf at 1' configuration
>    Verifying Hash Integrity ... sha1,rsa2048:dev+ OK
>    Trying 'kernel at 1' kernel subimage
>      Description:  Linux kernel
>      Type:         Kernel Image
>      Compression:  uncompressed
>      Data Start:   0x805000e4
>      Data Size:    4289584 Bytes = 4.1 MiB
>      Architecture: ARM
>      OS:           Linux
>      Load Address: 0x80008000
>      Entry Point:  0x80008000
>      Hash algo:    sha1
>      Hash value:   74d429a5c48d72ce3f569ba7eaa072c8c1eaab20
>    Verifying Hash Integrity ... sha1+ OK
> ## Loading fdt from FIT Image at 80500000 ...
>    Using 'conf at 1' configuration
>    Trying 'fdt at 1' fdt subimage
>      Description:  Flattened Device Tree blob
>      Type:         Flat Device Tree
>      Compression:  uncompressed
>      Data Start:   0x80917608
>      Data Size:    29802 Bytes = 29.1 KiB
>      Architecture: ARM
>      Hash algo:    sha1
>      Hash value:   e86cfd55c3e869c6b3014c758825b2a1ade3991e
>    Verifying Hash Integrity ... sha1+ OK
>    Booting using the fdt blob at 0x80917608
>    Loading Kernel Image ... OK
>    Using Device Tree in place at 80917608, end 80921a71
>
> Starting kernel ...
>
> data abort
> pc : [<81a80020>]          lr : [<80008008>]
> sp : 8e71b528  ip : 0000000c     fp : 00000400
> r10: 8f7a3d60  r9 : 8e723f28     r8 : 00000000
> r7 : 00000000  r6 : 00000ffc     r5 : 0ffc0004  r4 : 000000f7
> r3 : fc7391ff  r2 : 80917608     r1 : 00000e05  r0 : 80917608
> Flags: Nzcv  IRQs off  FIQs on  Mode SVC_32
> Resetting CPU ...
>
> I wasn't able yet track down what is causing this issue but it
> happened when jumping to kernel
> image (kernel_entry(0, machid, r2);). Any ideas what to check? Thanks
> in advance.

For this I'm not sure, perhaps your load address is wrong?

I just sent out a new series (available in u-boot-x86.git branch
'bone') which adds some step-by-step documentation. It also collects
all the fixes in one place.

[snip]

Regards,
Simon


More information about the U-Boot mailing list