Hi ondra,
sorry for the delay.
Thanks for providing info.i’ll look in to this and update you.
Hi ondra,
Board is booted succesfully with your kernel tree.Thanks for your help.
reading dragonboard-kernel_x1.snap/kernel.img
27388478 bytes read in 3064 ms (8.5 MiB/s)
Loading kernel from FIT Image at 90000000 …
Using ‘config@1’ configuration
Verifying Hash Integrity … sha256,rsa2048:ondra+ OK
Trying ‘kernel@1’ kernel subimage
Description: Dragonboard snappy kernel
Type: Kernel Image
Compression: uncompressed
Data Start: 0x900000f8
Data Size: 22495232 Bytes = 21.5 MiB
Architecture: AArch64
OS: Linux
Load Address: 0x80080000
Entry Point: 0x80080000
Hash algo: crc32
Hash value: ab4ec50e
Hash algo: sha1
Hash value: d7b218041fb018bf41d535d15162d1cd6015e520
Sign algo: sha256,rsa2048:ondra
Sign value: 1f09d105d9808c04fb89fd3dc54e6549638155e553f66001d0316307d7b284cc451bf0eb8143fdd39f1958e6a8dbe9dda5e65d5dd3a467e561b522e81f1798709a76c1fedcf0ccf8296b298f1a2f23cffd54df9571b2fe3f73eb7a6aa93dd5c3235fe0f1aca981e6e175c73cecf0eae799e0249f2148b873bc2d57ee222424466417d9fa3802113c93e7e79b2acebfaad82390b9d4ef2ee5c752b0f103def80886169672f75caa45062a0076379750f5cb33cc71b02e71ae7f209e870888c4ef4db68d740e7dc09351e19a62ca0752bce739bb40f4bcb9c329a262d39bb78bfa2d0d77268282c93dad58f3c82de4d44af2407fd8ef0413cd15d2dd9b4f71b716
Verifying Hash Integrity … sha256,rsa2048:ondra+ crc32+ sha1+ OK
Loading ramdisk from FIT Image at 90000000 …
Using ‘config@1’ configuration
Trying ‘ramdisk@1’ ramdisk subimage
Description: Ubuntu snappy ramdisk
Type: RAMDisk Image
Compression: gzip compressed
Data Start: 0x915743d4
Data Size: 4822057 Bytes = 4.6 MiB
Architecture: AArch64
OS: Linux
Load Address: 0x84000000
Entry Point: 0x84000000
Hash algo: crc32
Hash value: b4a91bb6
Hash algo: sha1
Hash value: 321f663a298298204510a56487d90dca48deed92
Sign algo: sha256,rsa2048:ondra
Sign value: 158ca0968bb29f6f59d7870c1439df768cdea094a12ad6886eb802651f278ca2f484272352b06f0847dee75b5d120baf95cfc8c7d254410ed86edd6291d5da4fb28821fbb7eeb2718b9b1e69cf5c137396998c9e4ea3e0172b2b33780982527e9f4b287fa43fc78353698cd7cbcd12378072fbfc31f6711ad854133b1267035079df8b95633d03eb79af501a07ed128a8b6f052a0f49d112c72ffc62fc86707935884a43127a2d32a4cd32fdb0ed38e9925e2ef8cf555c476c167b5eb0f8c11312da277feb031b296284b35c61e26721df6a03ad52e9629e5c7c1063c60cc7ecdd3313e5049610dd31ad64b16f59b5c1184c531a86001b2d691ee5ea631d5b4e
Verifying Hash Integrity … sha256,rsa2048:ondra+ crc32+ sha1+ OK
Loading ramdisk from 0x915743d4 to 0x84000000
Loading fdt from FIT Image at 90000000 …
Using ‘config@1’ configuration
Trying ‘fdt@1’ fdt subimage
Description: Flattened dragonboard Device Tree blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x91a0dae8
Data Size: 66447 Bytes = 64.9 KiB
Architecture: AArch64
Hash algo: crc32
Hash value: 44a12cd1
Hash algo: sha1
Hash value: 200bcfc7b64e1da7ffae6df9bf8148a6f1b5b426
Sign algo: sha256,rsa2048:ondra
Sign value: 00a3dcb81f88cebbfeb4205d9baf21c4f48b85775110909b1cd6ce0a01714d89007af1d14f89d76d4bdee317f8c88e33ebe79fa07a5cf3c40f535b6badc9d222e6748fde05785579b07de6bca8da346896789e8411caca48189c23f119e3bf03347ea476585ab1ffa47f85b593bf6ca9015df4bd07743dd452f82a8d0ad58046eef6a48e1add366bd0a8fe5dbed41c38b46bd281843861e55ec6a5be8f2f185a82050bd807c5f3b32e9c91bc22205a65088aa1efdd697e5d0ebced6b128ffd65f5569d078e5b5b8cdda1843ef0b20c9b330f128a709c7dad457178e0a22ac4f7785eac7808e0c652112543eba3c9aa7e52f5d22f217b62e249c75eb782222709
Verifying Hash Integrity … sha256,rsa2048:ondra+ crc32+ sha1+ OK
Loading fdt from 0x91a0dae8 to 0x83000000
Booting using the fdt blob at 0x83000000
Loading Kernel Image … OK
Using Device Tree in place at 0000000083000000, end 000000008301338e
Starting kernel …
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Initializing cgroup subsys cpuset
1 Like
Hi ondra/ogra,
To have fully secure boot process, u-boot authentication should happen from LK right?
if so can you help me on what needs to be done in LK?
Regards,
Laxman
Hi ondra,
u-boot/tools/mkimage -D “-I dts -O dtb -p 2000” -f $SNAPCRAFT_PART_INSTALL/fit-image.its -k $KEYS -K …/…/…/dragonboard410c.dtb …
in above command—> -K is the FDT where the public key information will be stored.
so i want to know how you generated this dragonboard410c.dtb and what are the changes you incorporated in to this dtb.
Regards,
Laxman
so if you want to have secure boot done properly, you will also need to sign sbl1 and aboot. This is something what would typically do Qualcomm or one of the oems.
aboot needs to be signed and needs to check signature of uboot binary, as uboot has built in public key for next stage, therefore aboot needs to verify its integrity……
As for key in uboot dtb, you can see all in gadget snap. There are multiple patches applied to uboot code, related to the verified boot. One of them is introducing padding to dtb, so key can be injected with mkimage tool.
check:
u-boot-generic-03-dtb-padding.patch
u-boot-generic-04-dts-signature.patch
Hi ondra,
i have signed sbl1 and aboot using qcom procedure. As you said, the next step is, aboot needs to verify u-boot signature. so can you please help me on how to do this, what changes to be made in lk.
Regards,
Laxman
I have not done this step, but there should be public part of your key build into lk (aboot) which you signed. It needs be there as previous step will check integrity of aboot, and consequently also public key in it.
With private part of that key you need to then sign u-boot, which acts as boot image.
My bet would be that Qualcomm’s mkimage tool from git://codeaurora.org/quic/kernel/skales should do that. Or some similar tool
Thanks ondra for the info.will look in to this
Regards,
Laxman
built the lk with verified boot enabled
Building the lk(http://git.linaro.org/landing-teams/working/qualcomm/lk.git branch:LA.BR.1.2.7-03810-8x16.0+sdboot_mac) by these flags
make -j16 msm8916 EMMC_BOOT=1 VERIFIED_BOOT=1 SIGNED_KERNEL=1 DEBUG=1 TOOLCHAIN_PREFIX=…/arm-eabi-4.8/bin/arm-eabi-
After signing the emmc_appsboot.mbn from qcom sectools, uboot is able to boot further, but in lk boot_verifier fails to read the signature length
[160] [160] failed to get ffbm cookie[170] [170] Loading boot image (405504): start
[190] [190] Loading boot image (405504): done
[190] [190] use_signed_kernel=1, is_unlocked=0, is_tampered=0.
[200] [200] Authenticating boot image (405504): start
[200] [200] boot_verifier: Error while reading signature length.
[210] [210] boot_verifier: Device is in GREEN boot state.
[210] [210] Authenticating boot image: done return value = 0
Any suggestion how we can sign the (u-boot) sd_u-boot.img binary? so that lk will be able to verify the u-boot.