S32G-RDB2 secure boot example is not working

tylor · ‎06-20-2023

Hello,

I tried to follow the example of secure boot(kernel sign verification in Chapter 10.3.2 in the manual.) step-by-step. (BSP v33)

I made FIT file successfully, tried to load it and boot but it is failed with message below.

(I'm using SD-Card at the moment.)

1. What is the Kernel load and entry address for S32G-RDB2?

- I set it 0x810000000 now.

2. Where can I set the rootfs partition in SD-Card? (e.g /dev/mmcblk0p2)

Please refer message below and reply, Thank you in advance.

NOTICE: Reset status: Power-On Reset
NOTICE: BL2: v2.5(release):bsp33.0-2.5
NOTICE: BL2: Built : 10:30:20, Jun 21 2023
NOTICE: BL2: Booting BL31

U-Boot 2020.04-dirty (Jun 21 2023 - 10:27:04 +0900)

CPU: NXP S32G274A rev. 2.0
Model: NXP S32G274A-RDB2
DRAM: 3.5 GiB
MMC: FSL_SDHC: 0
Loading Environment from MMC... OK
Using external clock for PCIe0, CRNS
Configuring PCIe0 as RootComplex(x2)
Using external clock for PCIe1, CRNS
Frequency 125Mhz configured for PCIe1
Configuring PCIe1 as SGMII(x2) [XPCS0 2.5G, XPCS1 OFF]
Setting PCI Device and Vendor IDs to 0x4002:0x1957
PCIe0: Failed to get link up
Pcie0: LINK_DBG_1: 0x00000000, LINK_DBG_2: 0x00000800 (expected 0x000000d1)
DEBUG_R0: 0x00019900, DEBUG_R1: 0x08200000
PCI: Failed autoconfig bar 20
PCI: Failed autoconfig bar 24
PCIe1: Not configuring PCIe, PHY not configured
In: serial@401c8000
Out: serial@401c8000
Err: serial@401c8000
Board revision: RDB2/GLDBOX Revision D
Net: EQOS phy: rgmii @ 1

Warning: eth_eqos (eth0) using random MAC address - aa:0e:4d:58:ea:9b
eth0: eth_eqos PFE: emac0: sgmii emac1: none emac2: rgmii
PFEng firmware file 'mmc@0:1:s32g_pfe_class.fw' loading failed: -2

Hit any key to stop autoboot: 0
=>
=>
=>
=> fatload mmc 0:1 0x80000000 output.itb
13848849 bytes read in 610 ms (21.7 MiB/s)
=> run mmcargs
=> iminfo

## Checking Image at 80000000 ...
FIT image found
FIT description: kernel+dtb/fdt fit image
Image 0 (kernel@1)
Description: kernel image
Type: Kernel Image
Compression: uncompressed
Data Start: 0x800000cc
Data Size: 13824072 Bytes = 13.2 MiB
Architecture: AArch64
OS: Linux
Load Address: 0x81000000
Entry Point: 0x81000000
Hash algo: sha1
Hash value: eb0d0410ca15bd8ba3cdacdbb885d480161d6e91
Image 1 (fdt@1)
Description: dtb blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x80d2f20c
Data Size: 22874 Bytes = 22.3 KiB
Architecture: AArch64
Hash algo: sha1
Hash value: 8f65394358c47a6f3aa003a8384e7f3f3131ebeb
Default Configuration: 'conf@1'
Configuration 0 (conf@1)
Description: unavailable
Kernel: kernel@1
FDT: fdt@1
Sign algo: sha1,rsa2048:boot_key
Sign value: 3c4df47d7a3e84e16a56d9531059160424c7bef9cc1e9c0fd9af391cdb65029fef9ed4e492713999eed0ad2f3fc7117c9827d5579480e25202d8b7a9cfcf3262ac61cfa9dc28b924fd0d2893063a5a3f39504aff0bd0644ebbdff6678c3e1bf73b33e6b18096a183e22b5ff0a5e4e1b541ab86ec1750938aa4c9c2b51abbc093287644718cdf783a7f960eb9e7564c4ad24a7c3f2faac6ef110d6ab7b37adaf76b9b5d4868fc258349eebd43d46096d05e369bf12174001de876165e9595dee60886c8894c1dc02ba302e8e55c94ba5596e6ec3ba000227101c3afc5fe79ede2571c8a00458c4c72301b8409c37245132129a5a3fdedeca4b54eb74dc3adc07d
## Checking hash(es) for FIT Image at 80000000 ...
Hash(es) for Image 0 (kernel@1): sha1+
Hash(es) for Image 1 (fdt@1): sha1+
=> bootm 0x80000000
## Loading kernel from FIT Image at 80000000 ...
Using 'conf@1' configuration
Verifying Hash Integrity ... sha1,rsa2048:boot_key+ OK
Trying 'kernel@1' kernel subimage
Description: kernel image
Type: Kernel Image
Compression: uncompressed
Data Start: 0x800000cc
Data Size: 13824072 Bytes = 13.2 MiB
Architecture: AArch64
OS: Linux
Load Address: 0x81000000
Entry Point: 0x81000000
Hash algo: sha1
Hash value: eb0d0410ca15bd8ba3cdacdbb885d480161d6e91
Verifying Hash Integrity ... sha1+ OK
## Loading fdt from FIT Image at 80000000 ...
Using 'conf@1' configuration
Verifying Hash Integrity ... sha1,rsa2048:boot_key+ OK
Trying 'fdt@1' fdt subimage
Description: dtb blob
Type: Flat Device Tree
Compression: uncompressed
Data Start: 0x80d2f20c
Data Size: 22874 Bytes = 22.3 KiB
Architecture: AArch64
Hash algo: sha1
Hash value: 8f65394358c47a6f3aa003a8384e7f3f3131ebeb
Verifying Hash Integrity ... sha1+ OK
Booting using the fdt blob at 0x80d2f20c
Loading Kernel Image
Using Device Tree in place at 0000000080d2f20c, end 0000000080d37b65
Failed to get offset of '/clocks/serdes_100_ext' node
Failed to set the clock for SerDes0
Failed to get 'serdes1' alias
Failed to set the clock for SerDes1
Failed to get 'serdes1' alias
Failed to set mode for SerDes1

Starting kernel ...

"Synchronous Abort" handler, esr 0x02000000
elr: 0000000081000000 lr : 00000000ffaa27e4 (reloc)
elr: 0000000081000000 lr : 00000000ffaa27e4
x0 : 0000000080d2f20c x1 : 0000000000000000
x2 : 0000000000000000 x3 : 0000000000000000
x4 : 0000000081000000 x5 : 0000000000000001
x6 : 0000000000000004 x7 : 0000000000000000
x8 : 00000000ffde4c18 x9 : 0000000000000002
x10: 000000000a200023 x11: 0000000000000002
x12: 0000000000000002 x13: 0000000000000000
x14: 00000000ffa99000 x15: 00000000ffaa1b08
x16: 00000000ffae4e10 x17: 0000000000000000
x18: 00000000ffa01e70 x19: 00000000ffb473e0
x20: 0000000000000000 x21: 0000000000000400
x22: 0000000000000001 x23: 00000000ffe0d6c8
x24: 00000000ffe0d6c8 x25: 00000000ffb327c0
x26: 0000000000000000 x27: 00000000ffaa27f0
x28: 00000000800000cc x29: 00000000ffde4c50

Code: 00000000 00000000 00000000 00000000 (56190527)
Resetting CPU ...

resetting ...

MayanksPatel · ‎07-12-2023

Hi @tylor,

Can we close this ticket?

Thanks,

Mayank s Patel

在原帖中查看解决方案

MayanksPatel · ‎06-28-2023

Hi @tylor,

How do you get Kernel load address 0x810000000?

The issue does not seem in the secure boot side as it is authenticating the Kernel. I think the issue is in the device-tree which you are flashing.

Please check your device tree have you added all peripheral nodes to this?

Thanks,

Mayank s Patel

tylor · ‎06-28-2023

Hello @MayanksPatel,

Thank you for your reply.

I tried load address with 0x80000000 and 0x810000000 because BSP manual and u-boot environment provide me the address for kernel load. (and I refered to S32G reference manual to find A53 memory address and I think 0x8xxxxxxxx can be used.)

Actually, I used device tree dts file of branch bsp33.0-2.5 in arm-trusted-firmware for your example in BSP manual. And I made .itb file with .its file below using mkimage tool.

(I can boot successfully without any modification if I use dts files in the branch, but It's not working if I use image made by mkimage tool)

/dts-v1/;
/ {
        description = "kernel+dtb/fdt fit image";
        #address-cells = <1>;
        images {
            kernel@1 {
                description = "kernel image";
                data = /incbin/("/home/test/linux/arch/arm64/boot/Image");
                type = "kernel";
                arch = "arm64";
                os = "linux";
                compression = "none";
                load = <0x81000000>;
                entry = <0x81000000>;
                kernel-version = <1>;
                hash@1 {
                    algo = "sha1";
                };
        };
        fdt@1 {
                description = "dtb blob";
                data = /incbin/("/home/test/arm-trusted-firmware/build/s32g274ardb2/release/fdts/s32g274a-rdb2.dtb");
                type = "flat_dt";
                arch = "arm64";
                compression = "none";
                fdt-version = <1>;
                hash@1 {
                    algo = "sha1";
                };
        };
    };
    configurations {
        default = "conf@1";
        conf@1 {
                kernel = "kernel@1";
                fdt = "fdt@1";
                signature@1 {
                    algo = "sha1,rsa2048";
                    key-name-hint = "boot_key";
                    sign-images = "kernel", "fdt";
                };
        };
    };
};

Please let me know where I can find the reference or how to update device tree for my case. Then I can try to update my device tree file.

MayanksPatel · ‎07-02-2023

Hi @tylor,

Why do you need to create an image by mkimage tool? Is there a use case?

Are you changing the default .dts file while using mkimage tool?

Thanks,

Mayank s Patel

tylor · ‎07-02-2023

Hello, @MayanksPatel .

I'm trying to do part 10.3.2 Setup Kernel Authentication in "S32G2_LinuxBSP_33.0_User_Manual.pdf"

And your 8th step for the part, manual describe how to make FIT image with mkimage tool. (refer to 8th step below)

I did not change any .dtb file and made FIT image with .its file I already posted.

8. Sign the kernel image and pack it into a FIT image
After the kernel has been compiled, from the u-boot directory, run:
tools/mkimage -f ../linux/<its-filename>.its
-K ../arm-trusted-firmware/build/<board>/release/fdts/<dtb-filename>.dtb
-k ../kernel_keys
-r <itb-filename>.itb

The resulting FIT image must be copied to the boot partition of the SD Card.

And next step is load the FIT image and boot, but it is not working.

(I can find the key verification is OK log when I boot with bootm command but reset right after load the kernel)

9. Rebuild the ARM Trusted Firmware
The ARM Trusted Firmware must be rebuilt to include the DTB in which the key was placed in the previous step.

10. Boot the board and stop at U-Boot command line
To optionally enable U-Boot secure boot, run:
=> hse_secboot_enable <rsa_public_key>.der
Copy the FIT image from the SD Card to memory:
=> fatload mmc 0:1 <load-address> <fit-image-name>
U-Boot must use the bootm command to boot, not booti. Trying to boot using booti will display the "Bad Linux
ARM64 Image magic!" error, since the header for the FIT image is not recognized by booti.
=> run mmcargs
=> bootm <load-address>
To check if the FIT image loaded on the board is correct, run:
iminfo

The command will check the hashes of the image, dtb, and configuration, but will not check if the FIT image is properly signed.

MayanksPatel · ‎07-04-2023

Hi @tylor,

We need help from you to resolve the issue.

please provide a detailed log for each step you did as per 10.3.2 Setup Kernel Authentication in UM. I would like to have a check.

And, by the way, is there any booting issue when Kernel authentication was not enabled?

Thanks,

Mayank s Patel

tylor · ‎07-05-2023

Hello, @MayanksPatel

I've attached some logs I used for the FIT image based on the UM.

I lost previous logs, so retry part 10.3 in the UM, pointed on the 10.3.2 part and I created an image in the same way and tested it, but unlike the last time, there was a problem with the verification of the FIT file. The process I have performed is the contents that you have explained in the manual, and only the paths have been changed to suit me.

And we're considering verify boot process from your HSE -> u-boot -> kernel for security purpose, so ensuring the boot process is important.

Please look at the attached file and check if there are any problems with the process I went through.

MayanksPatel · ‎07-05-2023

Hi @tylor,

Thanks for updating the logs. I've created a ticket with the internal team and will get back to you once anything is needed.

Thanks,

Mayank s Patel

MayanksPatel · ‎07-11-2023

Hi @tylor,

Checked the log by the internal team and suggested below changes:

1. After running the mkimage tool, you need to re-build atf; as shown in the UM:

9. Rebuild the ARM Trusted Firmware

The ARM Trusted Firmware must be rebuilt to include the DTB in which the key was placed in the previous step.

2. I noticed in the file for_linux.its, load & entry address for kernel was set to 0x80000000; So, use a different address for loading output.itb. For example: fatload mmc 0:1 90000000 output.itb

3. Have a try to set env fdt_high to a0000000 before 'run mmcargs': setenv fdt_high a0000000

4. In my tests, for the first time after running 'hse_secboot_enable', kernel boot will fail; but for following re-booting, it works well without issue.

Hope this helps.

Thanks,

Mayank s Patel

MayanksPatel · ‎07-12-2023

Hi @tylor,

I noticed in the for_linux.its.txt, the dtb file used was from ATF, That is not correct, the dtb for Linux (linux/arch/arm64/boot/dts/freescale/...) should be used:

                fdt@1 {
                        description = "dtb blob";
                        data = /incbin/("/home/ty.lim/secure_temp/source/arm-trusted-firmware/build/s32g274ardb2/release/fdts/s32g274a-rdb2.dtb");
                        type = "flat_dt";
                        arch = "arm64";
                        compression = "none";
                        fdt-version = <1>;
                        hash@1 {
                            algo = "sha1";
                        };
                };

Hope this helps.

Thanks,

Mayank s Patel

tylor · ‎07-12-2023

Hi, @MayanksPatel .

Finally it works!

Thanks for your support.

MayanksPatel · ‎07-12-2023

Hi @tylor,

Can we close this ticket?

Thanks,

Mayank s Patel

tylor · ‎07-13-2023

Hi @MayanksPatel

I think you can close this ticket. Thank you!

tylor · ‎07-11-2023

Hello, @MayanksPatel

Thank you for your support.

I tried to set fdt_high and changed address to conflict with .itb file.

I think kernel start successfully but now it can not load fdt file.

Is there more task to do before bootm command? I attached log file of u-boot environment with print command. (I tried the command below) Could you check it once more if I miss something?

(

=> fatload mmc 0:1 0x90000000 output.itb
=> setenv fdt_high a0000000
=> run mmcargs
=> iminfo 0x90000000
=> bootm 0x90000000

)

Thanks in advance.

=> bootm 0x90000000
## Loading kernel from FIT Image at 90000000 ...
   Using 'conf@1' configuration
   Trying 'kernel@1' kernel subimage
     Description:  kernel image
     Type:         Kernel Image
     Compression:  uncompressed
     Data Start:   0x900000cc
     Data Size:    13824008 Bytes = 13.2 MiB
     Architecture: AArch64
     OS:           Linux
     Load Address: 0x80000000
     Entry Point:  0x80000000
     Hash algo:    sha1
     Hash value:   f86b480fd9b21b15d76f73a3e3de153fd7cf62b6
   Verifying Hash Integrity ... sha1+ OK
## Loading fdt from FIT Image at 90000000 ...
   Using 'conf@1' configuration
   Trying 'fdt@1' fdt subimage
     Description:  dtb blob
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x90d2f1cc
     Data Size:    30042 Bytes = 29.3 KiB
     Architecture: AArch64
     Hash algo:    sha1
     Hash value:   d5b55721c778d5f568af230773506f48425a6d3f
   Verifying Hash Integrity ... sha1+ OK
   Booting using the fdt blob at 0x90d2f1cc
   Loading Kernel Image
   Loading Device Tree to 000000009fff5000, end 000000009ffff559 ... OK
Failed to get offset of '/clocks/serdes_100_ext' node
Failed to set the clock for SerDes0
Failed to get 'serdes1' alias
Failed to set the clock for SerDes1
Failed to get 'serdes1' alias
Failed to set mode for SerDes1

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034]
[    0.000000] Linux version 5.10.109-rt65 (ty.lim@labriego) (aarch64-none-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture 10.2-2020.11 (arm-10.16)) 10.2.1 20201103, GNU ld (GNU Toolchain for the A-profile Architecture 10.2-2020.11 (arm-10.16)) 2.35.1.20201028) #1 SMP PREEMPT Wed Jul 12 11:38:48 KST 2023
[    0.000000] Machine model: NXP S32G274A-RDB2
[    0.000000] earlycon: linflex0 at MMIO 0x00000000401c8000 (options '115200n8')
[    0.000000] printk: bootconsole [linflex0] enabled
[    0.000000] Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP
[    0.000000] Modules linked in:
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.10.109-rt65 #1
[    0.000000] Hardware name: NXP S32G274A-RDB2 (DT)
[    0.000000] pstate: 60000085 (nZCv daIf -PAN -UAO -TCO BTYPE=--)
[    0.000000] pc : fdt_check_header+0x8/0x130
[    0.000000] lr : __unflatten_device_tree+0x34/0x180
[    0.000000] sp : ffffffc010c93ea0
[    0.000000] x29: ffffffc010c93ea0 x28: 0000000080b40018
[    0.000000] x27: 00000000ffaa27f0 x26: 0000000000000000
[    0.000000] x25: 00000000ffb30a28 x24: 0000000000000000
[    0.000000] x23: ffffffc010d5a8d0 x22: 0000000000000000
[    0.000000] x21: fffffffefe7f5000 x20: ffffffc010b663b4
[    0.000000] x19: ffffffc010b663b4 x18: 0000000000000005
[    0.000000] x17: 0000000000001800 x16: 0000000000000000
[    0.000000] x15: 0000000000000030 x14: 0000000000200000
[    0.000000] x13: 00000000ff800000 x12: 0000000000000000
[    0.000000] x11: 0000000000006000 x10: 000000009fff5000
[    0.000000] x9 : 0000000000000000 x8 : 0000000000000000
[    0.000000] x7 : 0000000000801000 x6 : ffffffc010d4d8c8
[    0.000000] x5 : ffffffc010d4d850 x4 : 0000000000000000
[    0.000000] x3 : ffffffc010b663b4 x2 : ffffffc010d5a8d0
[    0.000000] x1 : fffffffefe7f5000 x0 : fffffffefe7f5000
[    0.000000] Call trace:
[    0.000000]  fdt_check_header+0x8/0x130
[    0.000000]  unflatten_device_tree+0x38/0x50
[    0.000000]  setup_arch+0x278/0x58c
[    0.000000]  start_kernel+0x70/0x4e4
[    0.000000] Code: d50323bf d65f03c0 d503245f aa0003e1 (b9400000)
[    0.000000] random: get_random_bytes called from oops_exit+0x38/0xd0 with crng_init=0
[    0.000000] ---[ end trace 0000000000000000 ]---
[    0.000000] Kernel panic - not syncing:
[    0.000000] Attempted to kill the idle task!
[    0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---

MayanksPatel · ‎07-04-2023

Hi @tylor,

I have created a ticket with the internal team. I will get back to you soon.

Thanks,

Mayank s Patel