I’m in the final stretch of developing a product with Jetson Nano Dev Kit, now my main concerns are security against SD theft or cloning.
In the case of the Jetson Nano module, does it have a dedicated memory to store the program? As I update the software, can I find any way to update the products already in that memory? Do you have any documents explaining how to create a PCB similar to the dev kit for the module?
For end product, the Jetson Nano eMMC module is the one you should use, you can refer to Jetson Nano Fuse Specification Application Note, and NVIDIA Jetson Linux Developer Guide : Security | NVIDIA Docs for device security.
For board design, please check Jetson Nano Product Design Guide
Thank you, but what about sending the software? How can I do this on the onboard memory, since it seems to me that this module does not come with an SD reader, but rather an integrated memory?
An added detail you might be interested in…
Jetsons do not have a BIOS, so they have the equivalent in software. eMMC models tend to have a lot of partitions which are not the operating system, but which support boot. All of those non-rootfs partitions must be signed, or their content is rejected. SD card models have this in QSPI memory instead of eMMC partitions, but this is still signed. The detail to think about is that eMMC models have a security fuse which can be burned with a private key that the outside world cannot read, while the SD card models do not have a burnable fuse. Neither model will necessarily protect reading of the boot content, but the eMMC module version, with a burned fuse, will protect against booting with any altered boot content.
The operating system itself is just Linux on a partition for either model. Whatever method is available for a desktop PC running Ubuntu is typically the same as what is available on a Jetson, although installation of that sort of content may differ. If you have decrypted a filesystem in order to mount it, which makes it possible to use that filesystem, then you do not have any protection unless the user on that operating system is prevented from reading whatever it is. At some point the rootfs must be mounted, and typically any decrypting key is provided in an an
initrd (the initial ramdisk is sort of a “filesystem adapter”; it contains the minimal content to deal with filesystem mount, and once that is accomplished, there is a pivot root type command to change the temporary
initrd filesystem to the actual rootfs filesystem).
Even if you have the end application such that it can execute, but not be copied or directly read, there are all kinds of tools someone could use to reverse engineer it. If it is simply an issue of being able to copy, then you could for example encrypt just the program, and provide a key to use it. Then comes the dilemma: How do you provide a key to an end user which allows execute, but not copy? It isn’t easy. Some companies resort to USB dongles. It isn’t really a Jetson-specific question except when it comes to how to install content when the content exists during boot.
Thank you for your response, almost all devices have a way to perform reverse engineering, but using the module instead of the dev kit SD card greatly reduces the possibility (from what you said and from what I read in the documents).
Now I’m worried about this memory being 16 GB, I’m using a 32 GB SD in my dev kit and from what I’ve seen most of the GB is used in my SD and by the software and drivers that are already installed with the jetpack.
I’ve already used a Jetson dev kit with a 16 SD card but there was only a few GB left (I don’t remember the exact amount) and most of it was used by jetpack driver software.
From the documents it looks like I’m going to suffer a little because of these fuses to update, clone, etc.
I wonder if there is any way to disable his HDMI? HDMI only works if I put a pin high on the Jetson or I send a signal on the serial or if you put a different pen drive
Remember that Linux can mount other media, e.g., an m.2 or SD card, to most any mount point. For example, “
/usr/local” could be an SD card. When not used as the root filesystem (rootfs) there is no special requirement (in this case the SD card is not used as boot media, it is only secondary storage; similar for an m.2 or SSD or USB external drive).
It is also possible, if you have an eMMC model with m.2 or similar slot (I’m not thinking SD card) to flash such that “
/boot” is on the eMMC, but then a pivot root is performed (using an
initrd boot…there is a different command line flash for doing this) to then switch the rootfs over to the other media.
I will emphasize that the boot content more or less has a pointer, and the initial pointer for eMMC models mandates the eMMC; this in no way stops you from then switching to other media, but the initial execution is pointing at eMMC as the boot chain ends. SD card models point at the SD card. The difference seems subtle, but it is key to understanding why an eMMC model cannot boot to the SD card on the carrier board without some third party mechanism.
You will find that eMMC modules don’t come with a carrier board. Those are instead sold by NVIDIA partners as a third party carrier board. Sometimes they are sold together, and sometimes you can purchase eMMC module and carrier board separately. Those models do require different flash software, but mostly that is due to the device tree. Many of those models have an m.2 slot.
The device tree could disable HDMI. I’m not sure what consequences would be, e.g., some CUDA applications require the X server, and the default X server uses HDMI (there are virtual desktops which look like an ordinary X server, but in reality they allow either HDMI or a virtual remote connection). Someone else would have to answer any details on that, and you would have to give much more detail about what software (especially CUDA or GPU-related) you plan to run.
I already knew about the modules until I researched some carrier plates created by waveshare, I believe I will buy the module and the carrier plate there
About HDMI, I understood, there could be a method but it worked, I believe it is better to use a method of blocking any change or output from the interface (only unlocking with a password)
For eMMC models consider that device tree, and some other content, e.g., kernel, can be loaded from either eMMC or the “
/boot” content (depending on how “
/boot/extlinux/extlinux.conf” is configured). If the entry in
extlinux.conf is missing or invalid, then it is ignored and the partition content of the eMMC model is used. eMMC also adds the feature that if the security fuses are burned, then none of that content named in
extlinux.conf is used; at that point it is the signed partition content which is mandatory during boot. Someone could read that content, but it will not be allowed if altered and not matching the security fuse key. You would be guaranteed that the device tree flashed into the partition is used, without editing.
Is there another way to disable or enable the HDMI if the device tree has set to “disabled” instead of “okay” for
status? I don’t know of a way. Perhaps there is a way. Someone from NVIDIA would have to comment. I also don’t know which software you might be interested in, which uses GPU, might also fail with HDMI disabled. You could always test prior to burning security fuses.
Incidentally, if someone had root access, it would be possible to add or remove packages related to HDMI. There are also software-only graphics servers which could work even if the GPU itself is disabled. You aren’t trying to disable GPU though, you’re trying to disable HDMI. You have to be very careful about giving exact details of what you want to occur, e.g., present a use-case. I’m only giving you a start, there are likely a lot of situations I can’t comment on.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.