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:
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.
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?
Is there a way to just disable this silly feature?
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.
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.
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?
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?