[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