I have some doubts related to secure boot on Jetson nano. I have read the documentation about it. but still, I am somehow confused about this things
I think the fuses are on the SoC (which is on the SoM), but someone would need to verify it. Maybe it is on memory? But, it is true that this feature is not available on the non-eMMC models (the SD card only model of Nano is included in those which cannot use the feature; technically, the feature is enabled, but the key is permanently a NULL key).
The security for this specific part is to force boot chains to be unaltered, except when flashed with a private key which is not available from the SoC itself. Other content in the boot chain is not “hidden” (aside from the key), but you know it is unaltered if it boots. Certain content which could normally be in a file in “/boot” is also no longer available, e.g., the kernel itself, and that content can then come only from a partition which is signed by the private key.
I haven’t heard of anyone protecting PCIe. I would suggest though that this sounds more like a task for SElinux. What SElinux does is to add “roles” to the usual file permissions. You could take something like a PCIe driver, and set the permissions to alter it to only root; but if someone got into root, they could still alter it. On the other hand, if there is a new user with name “pciuser” (just a contrived example, it could be any name), and if this user had the role of PCI maintenance, and if the PCIe drivers were to be marked with security rules that PCIe maintenance could only be changed by that user role, then even root could not change the driver software. A software stack overflow attack to get root authority would not be able to alter that driver after that. SElinux is a complicated tool, but you might want to read up on it.
The first example you will probably see for SElinux is that if a web server has a web administrator, and someone gets root authority, then that attack would not work against the web server.
@linuxdev , Thank you for your reply.
I read somewhere that jetson nano can be attacked through PCIe even after enabling secure boot, that’s why I was asking about that. I will try to use SElinux.
Thank you.
It is very difficult to stop physical attacks, but a PCIe attack would probably take some expensive hardware. My thought is that maybe the drivers can be secured such that the owner and maintainer of drivers are separate roles, and that the roles involved have no access to any other part of the system via SElinux, that this might help. Maybe. But this isn’t something specific to Jetsons, and anyone who has the hardware and knowledge to attack via PCIe is going to be difficult to stop.
Do note that most drivers (all in kernel space?) are running as part of the kernel, which is essentially root. I’m not sure how one would isolate a role for this separate from owner root. I’d look that up though. The device special files, if used to interface with a driver, can definitely have changes to owners and roles (basically, udev).
@linuxdev ,
One more doubt I had. If secure boot is not supported on SD card model, then is there any provision for the security of jetson nano SD card model?
I do not know of anything for SD card models which is hardware supported. I think the best you can do is to use something like Linux to encrypt the rootfs. The boot chain would not be protected. The dev kits were not intended for commercial resale products to be resold; that is the territory of the separately purchased eMMC module plus a third party carrier board. For example, if someone buys a dev kit, puts it in a product, and then sells that product, then NVIDIA does not provide any warranty to the new buyer (this would be the responsibility of the original purchaser). A separately purchased model does have a transfer of warranty, and would be warranted by NVIDIA even if the product is resold. In that light NVIDIA does not provide features on some dev kits (those without eMMC) which are not commercial modules, and custom boot chain signing is one of those missing features.
Note that eMMC models place a lot of boot content, along with content which is the equivalent of a BIOS, inside of eMMC binary partitions. SD card models place this in QSPI memory, and so if there is some sort of hardware directly wired to eMMC, then there is no possibility of that hardware working if there is no eMMC.
The actual operating system partition is always the o/s as the provider of any encryption, and not the Jetson itself. However, if you cannot guarantee the boot chain, then it means a possibility of not enforcing something the o/s does by changing its boot environment. If you want to build a secure product, and if it is for yourself, it is possible an eMMC model of dev kit (such as AGX) will do the job. If you are making a commercial product, and are willing to warrant it all on your own, then an AGX dev kit might work (it has eMMC). If you plan to actually sell such a product in volume, then you would only develop on a dev kit (which is why it is called a “developer” kit), and then produce a separate module+carrier board product.
If there is data on an encrypted SD card, then at least (if the unit is turned off) a way to prevent copy of that content.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.