Best practices in packaging software (in Jetson) for customer devices. (with over the air upgrade capability)

Please provide the following information when requesting support.

• Hardware (T4/V100/Xavier/Nano/etc)
Xavier / Orin
• Network Type (Detectnet_v2/Faster_rcnn/Yolo_v4/LPRnet/Mask_rcnn/Classification/etc)
Multiple
• TLT Version (Please run “tlt info --verbose” and share “docker_tag” here)
Latest (Working) 4.0.0 or greater

Hi,
This is a broader scope question on how to package software for customers.

context: We come from the research background and we’ve developed something with the aim to be used in a commercial environment. We’ve stuck to the NVIDIA ecosystem extensively and developed our own modules where our use case specific customisation is needed or where open-source libraries weren’t viable due to commercial licensing constraints or we saw significant room for improvement in doing so.

Our task now is to protect our source code as required by our company, while also securing our devices against potential threats. Our Jetson devices will be housed within autonomous machines operating in public spaces, with physical access limited to operators or safety supervisors.

Our question is: what best practices do you recommend to achieve these objectives?

Could we use a Board Support Package (BSP) or a Docker container to secure our Python code, or is it necessary to convert everything to C? How should we approach securing our models?

We’re also interested in secure Over-The-Air (OTA) setup. What are the best practices for this, particularly when it comes to securing Python code and algorithms?

We are not very savvy in commercial deployments so any redirection to relevant resources or and sort of guidance is highly appreciated

Cheers,

Hi,
This is a board topic for Jetson, I’m moving it to Xavier forum for better support, thanks.

Thanks a lot !
We are currently using AGX Xavier modules (inside the compute unit, but may be open to upgrading to Orin or other down the line if it is beneficial ) but I reckon there wouldn’t be that much change in the answer!

I hesitate to say “burn the security fuses”, but I’ll point out what their purpose is: During boot much of the content is taken from partitions on eMMC (or in some cases QSPI memory). This includes content which is equivalent to what a PC’s BIOS would have, along with boot loader. eMMC models of Jetsons (including AGX Xavier) sign that content, and if the content does not match the signature, then it won’t boot.

The default case is that the fuses are a “null” key, and so flashing without any specific key works. Even so, they are signed partitions. However, you can choose to burn the fuses with your private key. In that case the content has to be signed with your key, or boot will refuse to use that content. This does not stop content from being read, but it does stop the content from being altered. Once the fuses are burned though, there is no going back.

Those fuses do not directly touch the root filesystem. However, without the fuses being burned, some content might appear in “/boot” and have a higher priority than the equivalent content in other signed partitions. The kernel and the device tree are examples. Once fuses are burned, then only the signed partition content is allowed for those cases where editing used to be allowed in “/boot”.

I don’t know if you are worried about boot content being altered, but there is the basis of protecting against alteration of boot. This in no way protects what is in the rootfs (o/s) partition.

Also, there is a serial console for login. This is rather important for debugging. If you leave this with a default password, it seems like a "bad idea"™. You can completely disable serial console, but I’d be wary of that in case of need for support. You will get boot logs output during boot even if the user of serial console does not have login privileges, but much of that isn’t of much use (though it could be used to analyze what software is present). You could also set it up so that serial console is still present, but no boot logs are available (not so useful for support, but if login is somehow still available, it still has a purpose). It is a bit of a dilemma as to how to deal with a serial console port, but the worst thing is to not consider it and then be surprised by it at a later date.

I couldn’t tell you how to protect neural network models or python code. Even if you do something like rootfs partition encryption, once the partition is mounted, it is no longer encrypted. I’m assuming your questions were more for the system content once it is up and running, which I can’t help with, but I wanted to also point out boot content.

Almost forgot: If you supply packages at a web site for updates, and if those packages touch the boot content, then it needs to be signed. If you didn’t change the key, then the same NULL key is used on content going into those non-rootfs partitions, but if you have individual keys, then each package needs a custom key signing.

2 Likes

Hi,
For upgrading software packages to Jetson devices, please refer to
Software Packages and the Update Mechanism — Jetson Linux Developer Guide documentation

You may refer to it and construct your own deb package.
For using NVIDIA Jetson software releases/packages, please read the software agreement:
https://developer.nvidia.com/downloads/embedded/l4t/r35_release_v3.1/release/tegra_software_license_agreement-tegra-linux.txt/

1 Like

Thanks a lot! both answers seem to be equally useful!

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.