Jetson AGX XAVIER Devkit
L4T 32.7.1
I don’t want the rootfs to be seen if the board is stolen, can this be accomplished with a rootfs signature?
Hi,
You may check the section in developer guide
For confidential data, you can put in APP_ENC partition.
Hello DaneLLL,
Is it normal to see the signed rootfs on the board as shown in the image?
It is running on emmc.
I have done the following steps to sign the rootfs in emmc.
- generate ekb key
- put the board in recovery mode, flash and generate signed rootfs
sudo ROOTFS_ENC=1 . /flash.sh -i “. /ekb.key” jetson-agx-xavier-devkit mmcblk0p1
- Flash encrypted rootfs to internal storage device (emmc)
sudo ROOTFS_ENC=1 . /tools/kernel_flash/l4t_initrd_flash.sh jetson-agx-xavier-devkit mmcblk0p1
We have not been able to resolve this issue yet. I would like some advice.
Hi,
You would need to generate your own system_root_encrypted.img and flash to APP_ENC partition. system_boot.img in APP is not protected and viewable.
In case you are searching for information on the internet, consider that to “sign” something only means that the signature can be examined and compared to what someone signing has shipped the software as. Signing detects changes. A package for something like the rootfs is signed because it is never modified as shipped.
Once software changes (and the rootfs changes the moment you mount it, which changes the mount count) the signature will no longer help. That’s when you see “encrypted” as useful instead of “signed”. The content will only be available with the secret key, and that content will be available even if it changes. So long as the rootfs is not mounted with the secret key nobody will be able to read it.
Once an encrypted filesystem is mounted, then its full content is available to anyone who has permission to read it (e.g., root/sudo can read anything unless special effort went into SElinux).
With encryption, a physically stolen Jetson would be safe against reading rootfs so long as the system is not running. A remote exploit to a running system with an already mounted rootfs would offer no protection. Jetsons don’t enable SElinux by default, and SElinux is its own difficult learning curve if you wish to customize with this, but it does offer certain areas of the system which would be protected unless some particular user is compromised (even root can’t read content which SElinux forbids by policy, e.g., if the web server runs as a web administrator account, and it isn’t expected to see root modify this, then SElinux can forbid root from reading this…useful if yet a different user is exploited and escalated to root privileges).
Almost forgot: Signing is useful on binary content for booting which never changes. Burning security fuses will cause boot content to work only if signatures are correct. For example, one could have a binary partition with a kernel set to enforce SElinux, and any attempt to replace or alter that kernel would cause boot to fail. One could still flash, but no content would work if that content was not flashed with the private key. The kernel and device tree normally can be loaded from “/boot”, but if security fuses are burned, then only the version in the partition is allowed.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.