L4T - Block Ctrl+C during system boot

[nir_ke]

Hi there,
We’ve developed a product with Jetson Nano (first generation) and are currently going with it through penetration test (while working to port it for newer versions of the Jetson).
Can someone please share any best practice to completely block any way to enter the terminal of the system (L4T Operating System)?
So far we’ve tried some methods but it still doesn’t block it hermetically.

Thanks

[linuxdev]

Not an answer, but some related comments…

If you look at most I/O in Linux, especially noteworthy in C/C++, every program has a stdin file descriptor of “0”. There are also output I/O file descriptors. Most people know about stdout and the stderr: Descriptors 1 and 2. There is another output, buffered error, which works like stderr, except that it is buffered, 4 (stdlog). In theory, no matter which program you are talking to, you would have to remove stdin to stop CTRL+c, but I don’t know exactly what tradeoffs you are willing to accept.

There is something else which most people don’t know about, but which is likely critical to you. That’s the “magic sysrq” input. This is quite useful in kernel debugging and working with a system that is failing when you want to save something. I’ll start by suggesting you check one example: Watch “dmesg --follow”, and then hit the key combination “ALT+SysRq+s”. This tells the system to perform an emergency sync for filesystems. If I have a system which is failing to respond, I might run sync twice with this (and this works when most of the system is burning to the ground and failing), and I suspect it works even without a stdin (but maybe not? it’d be an interesting test if you can report results). This is designed for certain access under the worst of failure conditions, and while running the kernel in a debugger.

A typical emergency failure combination, in order, if the system fails, to sync and shut down:

1. ALT+SysRq+s
2. ALT+SysRq+s (yes, a second time to ensure the first sync finished)
3. ALT+SysRq+u (remounts filesystems read-only)
4. ALT+SysRq+b (reboots to shutdown stage)

There are many possible magic sysrq keys, not all of which are used on every system. There is a bit mask used to say which are available. If you set the bit mask you can completely remove magic sysrq availability. Those “commands” are made available either with the keyboard input, or via echo of the relevant command to the file “/proc/sysrq-trigger”. For example, sync could also trigger with “echo 's' > /proc/sysrq-trigger”.

In part, see:
https://docs.kernel.org/admin-guide/sysrq.html

Regarding the bitmask, check the output of this:
cat /proc/sys/kernel/sysrq

If you convert that to base two bits, then each bit is a field for enable of a feature. As root (sudo) you should be able to disable all sysrq with echo of ‘0’ into that file. It is a good idea to leave the ability to sync and set the filesystem to read-only if you consider there to be any chance you want to work on this system, but even that could be abused. For example, solid state memory such as that on an NVMe or eMMC or SSD could have its life drastically reduced by forcing sync over and over since this actually writes to the storage and not to the buffer or cache; buffer or cache is cleared to disk by doing this.

There is an article here about removing magic sysrq from the Linux kernel itself, and some information on the bit mask:
https://linuxconfig.org/how-to-enable-all-sysrq-functions-on-linux

Or, as mentioned, you could just set the bitmask. If the bitmask requires root access, and you don’t make root available, then the bitmask should suffice. Once someone has root access though, I don’t think you will care about magic sysrq.

Note for what follows: Nano dev kits do not have eMMC, and rootfs is on an SD card. Commercial Nano modules do have eMMC, and rootfs typically is on eMMC. Dev kits without eMMC do not have a feature to work with secure boot, but eMMC models do. All Jetsons, even dev kits, require a key to accept boot content, but that key has a default null key. The same is true for both eMMC and SD card dev kit models, but only the eMMC models can have a custom key applied to the fuses.

Also, don’t forget that the boot chain is its own program. The content in boot can be guarded against change via enabling secure boot with your own key. Note that once you burn those fuses, you can never unburn them. Those secure boot fuses will refuse to boot if the content found is not a match for the key used. The key itself cannot be discovered through examination of the Jetson (well, I suppose if you de-lid the SoC, know where to look, and examine it with an electron microscope, perhaps you could). This protection against boot chain change does not apply to content of the rootfs. Once Linux runs, secure boot no longer helps.

Regarding how secure boot works, there are certain files one can specify in “/boot/extlinux/extlinux.conf”. For example, one can specify the kernel as a file, typically it points at “/boot/Image”. Several boot-related files can be put in either a partition as binary data (which gets signed during flash), or set as a file in extlinux.conf. In normal circumstances the extlinux.conf specification for those files (such as Image) take precedence, and if those fail or cannot be found, then boot switches over to the partition for those files. When the key is not null, and secure boot fuses are burned, those files are no longer allowed and will be ignored; only the signed partition version of those files are then used. I couldn’t tell you which of those files go to a partition instead other than the Image; probably also device tree, perhaps others, e.g., the initrd. It is worth looking into if you think your boot chain might be altered.

I almost forgot: You would also need to be certain of what limitations your UEFI sets up for environment. For example, maybe it has the ability to boot to NFS under some circumstance that can be triggered even without modifying boot content (this would be a UEFI environment, and not a file).