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

[Belisko Marek]

Dear Simon Glass,

On Tue, Jun 3, 2014 at 6:42 AM, Simon Glass <sjg at chromium.org> wrote:
> 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?
Yes I've fixed this issue some time ago. What about those two
mentioned patches? Without them
I cannot create FIT properly.

>
> 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.
Thanks I'll look on that.
>
> [snip]
>
> Regards,
> Simon

BR,

marek

-- 
as simple and primitive as possible
-------------------------------------------------
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com