We are working on Jetson Xavier NX board with USB OTG port.
We are trying to control media access on it. if somebody accesses it, I want them to see only a particular folder with non-confidential data and not the confidential data (my code, models, confidential files). Is there any way I can make this possible? Like by using OTG port’s Host/peripheral switching behaviour or any other way?
Thank you.
Hello,
Thanks for visiting the NVIDIA Developer forums! Your topic will be best served in the Jetson category.
I will move this post over for visibility.
Cheers,
Tom
I can’t give you a good solution, but I’ll add some information.
All USB ports are either host (such as on the computer for plugging in the keyboard/mouse, this is type-A), or they are device (if your printer has a USB plug, then it is device mode, type-B). The OTG port (“on the go”) is still only host or only device, but the connector itself will accept either a type-A micro USB plug, or a type-B micro USB plug, and there is an ID pin. That ID pin is how the system knows whether to route such that if a device plugs into the Jetson, the functionality routes to a host controller; if a host plugs in, then the connector ID causes this to route to the device function (which is what you would use to pretend you are mass storage). Type-C is still doing this, but a bit of “Jedi mind trickery” (using two sets of cables) makes the cable itself symmetric (one of the two sets of wires in this will always be purely host at one end, or device, but not both ends as host and device; two sets of cables means you can also get more bandwidth if both sets are in the same mode).
Getting back to the micro-OTG connector, those Jetsons with a micro-OTG plug for flashing are only wired to be a device. You could plug in a device into that port, but it would never go into host mode simply because that port does not have host mode wiring, and that cable would be inert. The software which is used to look like devices is through the kernel’s “Gadget API”.
If you are familiar with loopback software, which is able to make one device behave as if it is some other hardware, this is how the Gadget API works (but only for “standard” USB classes). Every USB plug-in results in some plug-n-play software, which is just a way to query the device and ask what it is, followed by pairing a compatible driver with that connector/port. This only works for “standard” classes, which includes some (many?) cameras, keyboards, mice, joysticks, mass storage, so on.
The setup for that port is mostly to specify the response when a host asks what the device is. When the host (which is not the Jetson end for this case) sees that this is something like mass storage (if you’ve set up mass storage as the response) comes from the configuration at “/opt/nvidia/l4t-usb-device-mode/
” (at least for the default that NVIDIA sets up on the micro-OTG port for a micro-B plugin event; the type-A goes to the Linux PC). More than one device can be shared on that one cable, and NVIDIA sets up a virtual wired ethernet, plus a virtual mass storage (which contains nothing but a tiny partition and a README file).
About that mass storage set up by NVIDIA: There is a small file which is an even multiple of the 512 byte sectors, covered by loopback, and formatted as VFAT (msdos). This file works that way only when accessed through loopback (otherwise it is just binary nonsense data).
There are however options for using an actual hard drive partition. Let’s say you have a partition, and that partition is formatted, and this partition has your data and files on it. You could substitute that partition and the actual partition would be used directly without loopback. If you have one partition for public content, then you could make that available simultaneously with any number of other partitions (though performance might not be so good as you add mass storage traffic during a simultaneous access). One of those other partitions could be your private data, and the example NVIDIA README file partition over loopback could also exist there (you could even add your own README to that partition).
However, you’re going to have some serious security issues in some cases. First, you can only use full Linux filesystem permissions on a Linux filesystem type, e.g., ext4
. If you format as VFAT
, then you don’t have the file permission restrictions (they are very watered down restrictions when using VFAT
). If you switch to ext4
, this is helpful…but then Windows and Mac can’t read it anymore.
Then there is the topic of which user owns that partition: There is no login for this, and so pretty much anyone can get to that content. You’d be using some “mapped” user credential. Let’s compare if your user is “root
” versus an “admin
” versus “guest
” account.
- If
root
, everything is accessible. For a filesystem capable of write (you can set this up as read-only), anyone can change permissions or read or write or delete or add content. - Similar for an
admin
user, but some operations might require a password withsudo
(this may not be as straightforward as it sounds because asking for passwords isn’t from the device bulk storage…it is the system mounting this that has most of the password pop-up code…you must test this if you want some password scenario as it won’t necessarily do what you want it to do when performed from a single computer system). guest
is great since it can have all kinds of permissions removed.- If you want to add content from the Jetson itself, then typically you need to mount the filesystem somewhere. You might find issues with mounting the partition simultaneously on both the Jetson and the remote PC. Note that in NVIDIA’s mass storage example with the README file that the loopback device is not mounted on the Jetson itself. You could experiment with getting that loopback README partition simultaneously accessible and mounted on the Jetson.
- There are reasons why an actual Network Attached Storage (NAS) use filesystems such as AFS (which is Mac stuff) or NFS (anything *nix). Network neighborhood is the Windows competitor, and for that you could set up SAMBA on the Jetson.
- Small partitions which can be mounted only for the PC, but which you might auto mount on the Jetson when not mounted externally, might be a best case scenario for using the Gadget API as a mass storage device, but then you do still have to test out simultaneous access and/or switching access between Jetson and remote PC. Read-only partitions are ideal because it can be mounted in multiple locations without issue…there is no need to synchronize with complex schemes like NFS or SAMBA when the data is read-only.
Let’s say that you have a separate removable media which is completely unrelated to the running Jetson. For example, you have an m.2 drive which is in no way associated with the running Jetson. That’s something which would be quite useful with the Gadget API. You could for example use it as a bit of a “whiteboard”. There might be conflicts, but you wouldn’t care, at least not so far as causing issues with the Jetson booting or breaking.
Note that if you have an encrypted filesystem, then it is at the Jetson end that the encryption password would run. Your Jetson is the one which has to have direct access. The remote PC would not see this encryption. You could do something tricky like a loopback encrypted file on the encrypted partition whereby the Jetson must mount the partition with a password, and then the data served could be loopback mounted by the remote system, and during that remote system mounting event another password would be requisted.
Or you could just set up something like AFS or NFS or SAMBA which has security built in (though it is arguable that the security is not always great, but you wouldn’t be reinventing the wheel).
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.