Nano boot process

Autonomous Machines Jetson & Embedded Systems Jetson Nano
#1

I do not quite understand the Nano boot process and the idea behind signing the kernel and the DTB files.

So far I got that the DTB needs to be signed and placed in a separate partition. If an unsigned DTB is specified in the extlinux.conf file, the boot process will stop.

The kernel Image needs to be signed as well somehow and placed in the /boot folder. If it is not signed, it will boot but X11 will fail to start and GPU functions will not be available.

The way to sign those files is to use the “./create-jetson-nano-sd-card-image.sh” of the SDK-Manager on some Ubuntu PC.

My questions regarding this are:

  1. What is the purpose of the signing? It does not seem to serve any particular security feature since if an attacker could replace the DTB and/or kernel on the target system, he could still do so, he just needs to sign them.

  2. Are there any open source tools to create the signed files so that they could be run in a sane development environment, outside of the SDK Manager?

  3. Is there a way to just disable this silly feature?

#2

I was wondering about that when I used that script to make a new image for my nano (btw, the revision you use for that script is 200).

Everything seems to work and I have a fully functional firewall now.

I would guess that when it comes time to release the production modules they will explain how to sign stuff / install custom keys as well.

#3

The whole process is to use the secure boot feature. It is for those customers who need to fuse the odm_lock.

You could refer to this topic.
https://devtalk.nvidia.com/default/topic/1039010

If you look into the slides, you shall know how this signature authentication works.

#4

@WayneWWW

While the slides show how the secure boot process itself works, they do not answer the question how to disable it on the Nano or how to sign the boot files yourself.

Could you tell me how to sign the required files or how to disable trusted boot?

#5

Hi aren.caspari,

The method to sign is under L4T documentation -> Preparing Files to Boot from a Flash Drive with Secure Boot Implemented.

And sorry that this feature cannot be disabled.

#6

I see no such chapter. I found “Secureboot on Jetson AGX Xavier and Jetson TX2 Devices” while this answer
from another moderator says it’s not supported at all on Nano yet. Please can clarify who is right and post a link to the good documentation for nano.

#7

Yes, the whole process of secure boot on Nano is not fully implemented. But the kernel/kernel-dtb is already signed.

#8

I guess i’m curious then. I generated my own image and flashed it with create-jetson-nano-sd-card-image.sh. It booted, kernel modules load, etc. I couldn’t have signed the image with your keys and I didn’t install any keys onto the nano. Who verifies the keys and how are they installed? Docs link?

I’m new to arm64 in general. Is there an equivalent to mokutil to install keys and a way to enforce secure boot? Is there a way to tell if it is enforced. Normally i use mokutil but it’s not working.

Edit:

So I skimmed this process here which is for Xavier and TX2, and that looks pretty irreversible? Does the same apply to Nano, so there is no way to install and remove keys at will?

#9

If you look into the script “create-jetson-nano-sd-card-image.sh”, you can find a function “create_signed_images” and it would sign your image. It would sing your image with the key we provided.

Sorry that there is no specific doc for this part. You could refer to the document of Xavier/TX2.

#10

I see. Ok. So based on that documentation, the default key right now must be all zeroes, correct? The documentation says “… keys stored in write-once-read-multiple fuse devices … NVIDIA SoCs contain multiple fuses that control different items for security and boot. Programming a fuse, such as changing the value of a fuse bit from 0 to 1, is non-reversible.”.

Does all that apply to Nano?

So if I generate a key, and use odmfuse.sh to write those arbitrary ones and zeroes, that’s permanant permanant once odm_lock is flipped? And if odm_lock is not flipped, the best I can do is write a key of all ones? I take it there is no way to revoke keys the way this is set up? Will that change in the future with the production module?

#11

Sorry I may not help here.

As we previously mentioned, this function is not fully implemented yet. Also, the fuse tool we shared on download center is also for TX2/Xavier, so I think there is no official tool here.

I cannot guarantee what would be like in future either. This is beyond what I can decide.

#12

is this still not fully functional or has it been updated / completed ?