NVIDIA Jetson Orin Nano: adaptar el software a las necesidades del producto
El trabajo de Abinsula en Linux, actualizaciones, protección de datos y producción
El Developer Kit NVIDIA Jetson Orin Nano permite trabajar con una configuración de hardware y software ya operativa. Para utilizarlo en un producto pueden ser necesarias modificaciones: conectar periféricos distintos, usar una placa personalizada, elegir los programas que se instalan o prever actualizaciones y protecciones específicas.
En Abinsula partimos del hardware elegido por el cliente y de los requisitos del sistema. Identificamos las personalizaciones necesarias y las convertimos en software instalable y verificable. El trabajo incluye también los procedimientos para preparar otros dispositivos con la misma configuración y mantener las versiones posteriores.
Hacer funcionar Linux en la placa del cliente
El módulo Jetson se conecta a una carrier board, la placa que aloja conectores y periféricos. Si esta difiere de la del Developer Kit, el software debe conocer las nuevas conexiones. Para eso sirve la personalización del BSP, el paquete de drivers y configuraciones que permite a Linux utilizar el hardware.
Examinamos el esquema y las especificaciones de la placa para identificar las interfaces empleadas y los componentes conectados. Trasladamos esta información a las configuraciones de software: indicamos qué periféricos están presentes, cómo están conectados y qué señales se necesitan para inicializarlos. También configuramos o adaptamos los drivers, es decir, los componentes de software que permiten utilizarlos.
El arranque de NVIDIA atraviesa varias fases. En resumen, la BootROM, el código inicial integrado en el chip, carga los primeros componentes; MB1 inicializa la memoria y los ajustes de hardware, como la función de los pines; MB2 prepara el paso a las etapas siguientes; UEFI selecciona y carga el sistema operativo. A continuación, Linux inicia drivers, servicios y la aplicación. Ajustamos las configuraciones en la fase correspondiente: por ejemplo, las de los pines en MB1 y la elección del disco de arranque en UEFI. Después verificamos en la placa el funcionamiento de los periféricos.
Las correcciones se incorporan al código fuente y a las configuraciones del proyecto. Esto permite reproducirlas en la siguiente imagen de software, el paquete completo que se instala en el dispositivo, sin tener que aplicarlas manualmente en cada unidad.
L4T o Yocto: dos enfoques para construir Linux
Implementamos tanto soluciones basadas en NVIDIA Jetson Linux como distribuciones OpenEmbedded/Yocto. La sigla L4T significa Linux for Tegra: es el nombre histórico del software Linux de NVIDIA para los procesadores Tegra, familia a la que pertenece Orin. El nombre se sigue utilizando para identificar la base de software Jetson. La elección depende de los componentes requeridos y de cómo el cliente piensa mantener el sistema.
Con L4T mantenemos la base Ubuntu y los componentes de NVIDIA, integrando las personalizaciones del producto. Podemos, por ejemplo, añadir el driver de un periférico y configurar la aplicación para que se inicie automáticamente, conservando las bibliotecas de NVIDIA y la gestión de paquetes de Ubuntu. Después preparamos una imagen que incluye estas modificaciones, lista para instalarse en otras unidades compatibles.
Con Yocto, en cambio, definimos qué componentes se construyen e incluyen en la distribución. Para un dispositivo sin interfaz gráfica podemos, por ejemplo, crear una imagen con los drivers necesarios, los servicios de red y la aplicación, sin incluir un escritorio. Las recetas describen cómo construir e instalar cada componente y fijan su versión. El soporte para Jetson procede de OE4T/meta-tegra, un proyecto independiente de NVIDIA. Obtenemos así una distribución dedicada, que se puede reconstruir a partir de las mismas definiciones.
En ambos casos conservamos el código fuente, las configuraciones y las instrucciones de compilación. Así, el cliente puede saber qué contiene una release, reconstruirla y compararla con la siguiente.
Actualizaciones A/B con NVIDIA Image-Based OTA y SWUpdate
Una actualización debe instalar la nueva versión preservando una posibilidad de recuperación. Por eso definimos conjuntamente la estructura del disco y el funcionamiento de la actualización. En los sistemas con SSD NVMe, es decir, un disco de estado sólido conectado a través de una interfaz de alta velocidad, configuramos también el arranque de Linux desde el disco.
Con el esquema A/B reservamos dos áreas para las copias del sistema operativo. El dispositivo trabaja en la primera mientras la segunda recibe la actualización. Al reiniciar, prueba la nueva versión; si no arranca, el sistema puede volver a la copia que funciona. La ventaja es reducir las intervenciones físicas necesarias tras una actualización fallida.
Hemos implementado dos soluciones: NVIDIA Image-Based OTA en el enfoque L4T y SWUpdate en las integraciones Yocto. OTA significa Over-the-Air e indica la distribución de actualizaciones a través de la red. Image-Based OTA es la solución de NVIDIA para preparar y aplicar imágenes del sistema, integrada con las herramientas del BSP. SWUpdate es un software de instalación que permite definir qué componentes actualizar y cómo escribirlos; puede recibir paquetes distribuidos por red o proporcionados localmente. Con ambos preparamos el paquete y la lógica de actualización, coordinándolos con los slots A/B. La elección depende del control requerido sobre la instalación y de la integración con el sistema existente.
La verificación incluye la actualización en ambas direcciones, de A a B y de B a A. También provocamos un fallo de arranque para comprobar la vuelta automática a la copia que funciona. Después de cada paso verificamos qué sistema se está ejecutando realmente y el estado de las dos copias.
Sin embargo, que Linux arranque no demuestra que la aplicación funcione. Es necesario definir con el cliente qué servicios deben responder y qué comprobaciones autorizan a confirmar la nueva versión. Estos criterios completan la gestión de la actualización según las necesidades del producto.
Full Disk Encryption: proteger software y datos en el disco
La Full Disk Encryption, o FDE, protege los contenidos persistentes del sistema mediante el cifrado de los volúmenes que los alojan. Aplicaciones, configuraciones y datos no se pueden leer sin la clave, aunque el SSD se extraiga y se conecte a otro ordenador. Utilizamos LUKS y dm-crypt, los componentes de Linux que gestionan los volúmenes protegidos y el cifrado durante las lecturas y escrituras. En el layout de Jetson, las particiones necesarias para el arranque permanecen separadas: FDE no significa que cada byte del disco esté cifrado.
Definimos qué volúmenes cifrar e integramos su desbloqueo en la secuencia de arranque. Utilizamos el flujo de NVIDIA basado en OP-TEE, un entorno aislado de Linux que deriva la credencial necesaria para abrirlos. Así, el dispositivo puede arrancar de forma autónoma, manteniendo el mecanismo de acceso a los datos coherente con la configuración de las claves.
Hemos integrado este mecanismo con las dos copias A/B y con el área de datos. También la actualización pasa por la capa de cifrado: tras la instalación comprobamos que el nuevo sistema sigue cifrado y arranca correctamente. Las áreas necesarias para el arranque se gestionan por separado.
Además, hemos verificado el paso de una credencial genérica de instalación a una específica del dispositivo, comprobando que la anterior ya no era aceptada. El cifrado protege los datos en reposo; una vez que el sistema los ha abierto, siguen siendo necesarios el control de accesos y la seguridad de los programas.
Secure Boot: proteger la integridad de la cadena de arranque
El cifrado protege el contenido del disco. Secure Boot aborda un problema distinto: impedir que un componente de arranque sustituido o alterado se ejecute como si estuviera autorizado. El dispositivo verifica una firma digital antes de cargar el software protegido.
En Abinsula integramos la firma en la preparación de las imágenes y configuramos el firmware de arranque para que la compruebe. Definimos qué componentes deben verificarse y mantenemos la coherencia entre las claves usadas para firmar y las que reconoce el dispositivo. Aplicamos los mismos controles a las imágenes incluidas en las actualizaciones, para que las versiones posteriores puedan seguir arrancando.
La prueba abarca tanto imágenes válidas como imágenes modificadas. Hemos verificado que UEFI, el firmware que gestiona las fases posteriores del arranque, acepta las primeras y rechaza las alteradas, comprobando también la vuelta a la copia del sistema que funciona.
Estas verificaciones se han realizado en hardware de desarrollo. La protección completa desde las primeras instrucciones del chip requiere también una configuración de hardware permanente, distinta de la verificación UEFI. Esta separación permite probar el software antes de las operaciones irreversibles de producción. El código autorizado debe mantenerse y actualizarse igualmente: una firma válida no excluye la presencia de vulnerabilidades.
FSKP: gestionar el aprovisionamiento seguro en producción
El aprovisionamiento (provisioning) es la preparación inicial de las unidades: instalación del software y aplicación de las configuraciones previstas, incluidas las de seguridad. Parte de estos ajustes se almacena en los fuses, elementos internos del chip que se programan de forma permanente. Un error en esta fase no se corrige simplemente reinstalando Linux.
Factory Secure Key Provisioning, o FSKP, es el mecanismo de NVIDIA para transferir al dispositivo, de forma protegida, los datos destinados a la programación de los fuses. En el entorno que custodia las claves se prepara un paquete cifrado y autenticado. El puesto de fábrica recibe este paquete y lo envía a la unidad a través del modo de servicio de NVIDIA.
Así, los puestos de producción pueden realizar la programación sin recibir en claro las claves criptográficas usadas para proteger el paquete. Abinsula integra las herramientas de NVIDIA con la configuración de seguridad del producto, vinculando la preparación del paquete con su aplicación en los dispositivos compatibles. La ventaja es limitar el acceso al material criptográfico y hacer que una configuración ya definida pueda utilizarse en la línea de producción.
El proceso puede probarse antes de que los ajustes se vuelvan permanentes: hemos utilizado el modo de simulación de FSKP para verificar su funcionamiento en el dispositivo sin modificar sus fuses. Esta posibilidad permite preparar el paso a producción; la programación definitiva requiere después las claves de producción, el material de NVIDIA previsto y la verificación del procedimiento en el perfil de hardware correspondiente.
Optimización del arranque
Cuando el producto requiere tiempos de arranque más cortos, optimizamos la secuencia de boot para reducir la espera hasta que la aplicación esté disponible. Verificamos el resultado en el dispositivo, manteniendo las funciones de seguridad, actualización y recuperación previstas.
La release: software y herramientas para la instalación y el mantenimiento
La release reúne el software listo para instalar y las herramientas necesarias para actualizarlo y restaurarlo. Puede incluir código fuente, configuraciones y documentación, para que el cliente pueda utilizar en producción la versión entregada y disponga de lo necesario para mantenerla a lo largo del tiempo.
Referencias técnicas
- NVIDIA Jetson Linux Developer Guide R36.4.4
- Jetson Orin NX and Nano Series - Adaptation and Bring-Up
- Jetson Boot Architecture
- Jetson Orin Series Boot Flow
- Software Packages and the Update Mechanism
- Secure Boot
- Disk Encryption
- Factory Secure Key and Expansion Key Provisioning (FSKP)
- OE4T / meta-tegra — soporte OpenEmbedded/Yocto para NVIDIA Jetson