Hi Belisko,
On 28 April 2014 00:30, Belisko Marek marek.belisko@gmail.com wrote:
Hi Simon,
On Wed, Apr 16, 2014 at 4:41 PM, Simon Glass sjg@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@1' signature node in 'conf@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@1' configuration Verifying Hash Integrity ... sha1,rsa2048:dev+ OK Trying 'kernel@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@1' configuration Trying 'fdt@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