Jetpack 4.4.1, How to tell if a boot failed because of failed secure boot?

Autonomous Machines Jetson & Embedded Systems Jetson AGX Xavier
1

Hi, We’re developing on Jetson AGX Xavier, and looking to implement secureboot, but I can’t find any documentation on how to tell if a boot failed because of a security failure (ie, no signature, incorrect signature, etc.).

We’re planning on using the PKC key and sign the kernel, kernel-dtb, and cboot, but we’d like to differentiate why a boot failed, and it reverted back to the original boot slot.

Thanks,
Will

3

hello will.jennings,

here’s documentation. Secure Boot.
here’re some related discussion threads as see-also, Topic 117585, Topic 158361.

BTW,
if that’s possible, please moving to JetPack 4.6.3, it’s the latest JP-4 release version. this release include some bug fixes.
there’s additional tools you’ll need, assume you’ve moving to JP-4.6.3, you should also check linux-tegra-r3273 for the [Tools] section to download secureBoot packages.

4

Hi Jerry,

I’m not asking how to do Secure Boot, I understand that process, What I’m asking is in the title:
How to tell if a boot failed because of failed secure boot?
I can’t find any documentation on how to tell if a boot failed because of a security failure (ie, no signature, incorrect signature, etc.).

So, please, could you help me in understanding how to know if a boot failed because the images were not signed, or had a invalid signature?

Moving to a later jetpack isn’t something we can do at this moment.

Thanks,
Will

5

hello will.jennings,

what’s your real use-case, is the board fused or not?

let’s assume you have a target fused with PKC+SBK.
the PKC key is used for signing the images, and SBK is for encrypting the images.
the flash process should be exit with failures reported if you’re not given keys, or mismatch target keys.
and… you may also setup a serial console to gather bootloader logs, it’ll report verification failure.

6

Hi Jerry,

My use case is running code in production environment, and our code gets notified there’s a firmware update, available. So, we update the firmware, but the kernel isn’t signed properly. We flash and reboot, but the bootloader fails to authenticate the kernel.
So, it reboots, using the previous boot slot into our firmware. how can we tell, after the reboot, that it did not load the new firmware because of a signature failure in software? We will know it didn’t upgrade, since the boot slots will not have changed, but we would like to know WHY it failed.

Also, do we have to use SBK with PKC for Jetson Xavier (AGX and NX) when running jetpack 4.4.1, or can we just use PKC?

7

hello will.jennings,

please setup a serial console to gather bootloader logs,
you may see-also Jetson AGX Xavier Developer Kit User Guide. it’s port [J501] Micro-USB connector provides access to the UART console.

yes, that depends-on your authentication type.

8

Hi Jerry,
I know how to look at the logs with my eyes via the console, but how can we tell when running our code, in the field, that an authentication error has occurred? Are the boot logs stored somewhere we can access them when our production code is running in a customer’s premise?

Thanks,
Will

9

practicality, you should debug locally then deliver the finalized binary to production platforms, isn’t it.

10

In a perfect world, there are never mistakes, but, we don’t live in that world. It would be good to know that a failed boot occurred because of authentication failures.

So, how can we tell when running our code, in the field, that an authentication error has occurred?

Thanks,
Will

1 Like
11

hello will.jennings,

there’s port [J501] Micro-USB connector provides access to the UART console, is your production platforms removing that?

how you plan to update the devices in the field?
there’s a failsafe way to update BSP, you may see-also Image-Based Over-the-Air Update.

13

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.