NVIDIA Jetson Orin Nano: adattare il software alle esigenze del prodotto
Il lavoro di Abinsula su Linux, aggiornamenti, protezione dei dati e produzione
La Developer Kit NVIDIA Jetson Orin Nano permette di lavorare su una configurazione hardware e software già funzionante. Per utilizzarla in un prodotto possono servire modifiche: collegare periferiche diverse, usare una scheda personalizzata, scegliere i programmi da installare o prevedere aggiornamenti e protezioni specifiche.
In Abinsula partiamo dall’hardware scelto dal cliente e dai requisiti del sistema. Individuiamo le personalizzazioni necessarie e le trasformiamo in software installabile e verificabile. Il lavoro comprende anche le procedure per preparare altri dispositivi con la stessa configurazione e mantenere le versioni successive.
Far funzionare Linux sulla scheda del cliente
Il modulo Jetson si collega a una carrier board, la scheda che ospita connettori e periferiche. Se questa cambia rispetto alla Developer Kit, il software deve conoscere i nuovi collegamenti. A questo serve la personalizzazione del BSP, il pacchetto di driver e configurazioni che permette a Linux di utilizzare l’hardware.
Esaminiamo lo schema e le specifiche della scheda per identificare le interfacce impiegate e i componenti collegati. Traduciamo queste informazioni nelle configurazioni software: indichiamo quali periferiche sono presenti, come sono collegate e quali segnali servono a inizializzarle. Configuriamo o adattiamo anche i driver, cioè i componenti software che consentono di utilizzarle.
Il boot NVIDIA attraversa più fasi. In sintesi, la BootROM, il codice iniziale incorporato nel chip, carica i primi componenti; MB1 inizializza memoria e impostazioni hardware, come la funzione dei pin; MB2 prepara il passaggio agli stadi successivi; UEFI seleziona e carica il sistema operativo. Linux avvia poi driver, servizi e applicazione. Adeguiamo le configurazioni nella fase interessata: per esempio, quelle dei pin in MB1 e la scelta del disco di avvio in UEFI. Verifichiamo quindi sulla scheda il funzionamento delle periferiche.
Le correzioni entrano nei sorgenti e nelle configurazioni del progetto. Questo permette di riprodurle nella successiva immagine software, il pacchetto completo da installare sul dispositivo, senza doverle applicare manualmente a ogni unità.
L4T o Yocto: due approcci per costruire Linux
Implementiamo sia soluzioni basate su NVIDIA Jetson Linux sia distribuzioni OpenEmbedded/Yocto. La sigla L4T significa Linux for Tegra: è la denominazione storica del software Linux NVIDIA per i processori Tegra, famiglia a cui appartiene Orin. Il nome è tuttora utilizzato per identificare la base software Jetson. La scelta dipende dai componenti richiesti e da come il cliente intende mantenere il sistema.
Con L4T manteniamo la base Ubuntu e i componenti NVIDIA, integrando le personalizzazioni del prodotto. Possiamo, per esempio, aggiungere il driver di una periferica e configurare l’applicazione perché parta automaticamente, conservando le librerie NVIDIA e la gestione dei pacchetti Ubuntu. Prepariamo quindi un’immagine che includa queste modifiche, pronta da installare su altre unità compatibili.
Con Yocto definiamo invece quali componenti costruire e includere nella distribuzione. Per un dispositivo senza interfaccia grafica possiamo, per esempio, creare un’immagine con i driver necessari, i servizi di rete e l’applicazione, senza includere un desktop. Le ricette descrivono come costruire e installare ciascun componente, fissandone la versione. Il supporto Jetson proviene da OE4T/meta-tegra, un progetto distinto da NVIDIA. Otteniamo così una distribuzione dedicata, ricostruibile dalle stesse definizioni.
In entrambi i percorsi conserviamo sorgenti, configurazioni e istruzioni di costruzione. Il cliente può così sapere cosa contiene una release, ricostruirla e confrontarla con quella successiva.
Aggiornamenti A/B con NVIDIA Image-Based OTA e SWUpdate
Un aggiornamento deve installare la nuova versione preservando una possibilità di recupero. Per questo definiamo insieme la struttura del disco e il funzionamento dell’aggiornamento. Nei sistemi con SSD NVMe, cioè un disco a stato solido collegato attraverso un’interfaccia ad alta velocità, configuriamo anche l’avvio di Linux dal disco.
Con lo schema A/B riserviamo due aree alle copie del sistema operativo. Il dispositivo lavora sulla prima mentre la seconda riceve l’aggiornamento. Al riavvio prova la nuova versione; se questa non parte, il sistema può tornare alla copia funzionante. Il beneficio è ridurre gli interventi fisici necessari dopo un aggiornamento fallito.
Abbiamo implementato due soluzioni: NVIDIA Image-Based OTA nel percorso L4T e SWUpdate nelle integrazioni Yocto. OTA significa Over-the-Air e indica la distribuzione degli aggiornamenti attraverso la rete. Image-Based OTA è la soluzione NVIDIA per preparare e applicare immagini di sistema, integrandosi con gli strumenti del BSP. SWUpdate è un software di installazione che permette di definire quali componenti aggiornare e come scriverli; può ricevere pacchetti distribuiti in rete o forniti localmente. Con entrambi prepariamo pacchetto e logica di aggiornamento, coordinandoli con gli slot A/B. La scelta riguarda il controllo richiesto sull’installazione e l’integrazione con il sistema esistente.
La verifica comprende l’aggiornamento in entrambe le direzioni, da A a B e da B ad A. Abbiamo anche provocato un errore di avvio per controllare il ritorno automatico alla copia funzionante. Dopo ogni passaggio verifichiamo quale sistema sia realmente in esecuzione e lo stato delle due copie.
L’avvio di Linux non dimostra però che l’applicazione funzioni. Occorre definire con il cliente quali servizi devono rispondere e quali controlli autorizzano la conferma della nuova versione. Questi criteri completano la gestione dell’aggiornamento secondo le esigenze del prodotto.
Full Disk Encryption: proteggere software e dati sul disco
La Full Disk Encryption, o FDE, protegge i contenuti persistenti del sistema attraverso la cifratura dei volumi che li ospitano. Applicazioni, configurazioni e dati non sono leggibili senza la chiave, anche se l’SSD viene estratto e collegato a un altro computer. Utilizziamo LUKS e dm-crypt, i componenti Linux che gestiscono i volumi protetti e la cifratura durante letture e scritture. Nel layout Jetson le partizioni necessarie al boot restano distinte: FDE non significa che ogni byte del disco sia cifrato.
Definiamo quali volumi cifrare e integriamo il loro sblocco nella sequenza di avvio. Utilizziamo il flusso NVIDIA basato su OP-TEE, un ambiente isolato da Linux che deriva la credenziale necessaria ad aprirli. Il dispositivo può così avviarsi autonomamente, mantenendo il meccanismo di accesso ai dati coerente con la configurazione delle chiavi.
Abbiamo integrato questo meccanismo con le due copie A/B e con l’area dati. Anche l’aggiornamento passa attraverso lo strato di cifratura: dopo l’installazione controlliamo che il nuovo sistema rimanga cifrato e si avvii correttamente. Le aree necessarie al boot sono gestite separatamente.
Abbiamo inoltre verificato il passaggio da una credenziale generica di installazione a una specifica del dispositivo, controllando che la precedente non fosse più accettata. La cifratura protegge i dati a riposo; quando il sistema li ha aperti, restano necessari il controllo degli accessi e la sicurezza dei programmi.
Secure Boot: proteggere l’integrità della catena di avvio
La cifratura protegge il contenuto del disco. Secure Boot affronta un problema diverso: impedire che un componente di avvio sostituito o alterato venga eseguito come se fosse autorizzato. Il dispositivo verifica una firma digitale prima di caricare il software protetto.
In Abinsula integriamo la firma nella preparazione delle immagini e configuriamo il firmware di avvio per controllarla. Definiamo quali componenti devono essere verificati e manteniamo coerenti le chiavi usate per firmare e quelle riconosciute dal dispositivo. Applichiamo gli stessi controlli alle immagini contenute negli aggiornamenti, così che le versioni successive possano continuare ad avviarsi.
La prova comprende sia immagini valide sia immagini modificate. Abbiamo verificato che UEFI, il firmware che gestisce le fasi successive dell’avvio, accetti le prime e rifiuti quelle alterate, controllando anche il ritorno alla copia funzionante del sistema.
Queste verifiche sono state eseguite su hardware di sviluppo. La protezione completa fin dalle prime istruzioni del chip richiede anche una configurazione hardware permanente, distinta dalla verifica UEFI. Questa separazione permette di provare il software prima delle operazioni irreversibili di produzione. Il codice autorizzato deve comunque essere mantenuto e aggiornato: una firma valida non esclude la presenza di vulnerabilità.
FSKP: gestire il provisioning sicuro in produzione
Il provisioning è la preparazione iniziale delle unità: installazione del software e applicazione delle configurazioni previste, comprese quelle di sicurezza. Una parte di queste impostazioni viene memorizzata nei fuse, elementi interni al chip programmabili in modo permanente. Un errore in questa fase non si corregge semplicemente reinstallando Linux.
Factory Secure Key Provisioning, o FSKP, è il meccanismo NVIDIA per trasferire al dispositivo i dati destinati alla programmazione dei fuse in forma protetta. Nell’ambiente che custodisce le chiavi viene preparato un pacchetto cifrato e autenticato. La postazione di fabbrica riceve questo pacchetto e lo invia all’unità attraverso la modalità di servizio NVIDIA.
Le postazioni di produzione possono così svolgere la programmazione senza ricevere in chiaro le chiavi crittografiche usate per proteggere il pacchetto. Abinsula integra gli strumenti NVIDIA con la configurazione di sicurezza del prodotto, collegando la preparazione del pacchetto alla sua applicazione sui dispositivi compatibili. Il vantaggio è circoscrivere l’accesso al materiale crittografico e rendere utilizzabile sulla linea una configurazione già definita.
Il percorso può essere provato prima di rendere permanenti le impostazioni: abbiamo utilizzato la modalità di simulazione FSKP per verificarne il funzionamento sul dispositivo senza modificarne i fuse. Questa possibilità consente di preparare il passaggio alla produzione; la programmazione definitiva richiede poi le chiavi di produzione, il materiale NVIDIA previsto e la verifica della procedura sul profilo hardware interessato.
Ottimizzazione del boot
Quando il prodotto richiede tempi di avvio più brevi, ottimizziamo la sequenza di boot per ridurre l’attesa fino alla disponibilità dell’applicazione. Verifichiamo il risultato sul dispositivo, mantenendo le funzioni di sicurezza, aggiornamento e recupero previste.
La release: software e strumenti per installazione e manutenzione
La release raccoglie il software pronto da installare e gli strumenti necessari per aggiornarlo e ripristinarlo. Può includere sorgenti, configurazioni e documentazione, così che il cliente possa utilizzare la versione consegnata in produzione e disporre di quanto serve per mantenerla nel tempo.
Riferimenti tecnici
NVIDIA Jetson Linux Developer Guide R36.4.4
https://docs.nvidia.com/jetson/archives/r36.4.4/DeveloperGuide/
Jetson Orin NX and Nano Series - Adaptation and Bring-Up
Jetson Boot Architecture
https://docs.nvidia.com/jetson/archives/r36.4.4/DeveloperGuide/AR/BootArchitecture.html
Jetson Orin Series Boot Flow
Software Packages and the Update Mechanism
Secure Boot
https://docs.nvidia.com/jetson/archives/r36.4.4/DeveloperGuide/SD/Security/SecureBoot.html
Disk Encryption / Factory Secure Key and Expansion Key Provisioning (FSKP)
https://docs.nvidia.com/jetson/archives/r36.4.4/DeveloperGuide/SD/Security/DiskEncryption.html
https://docs.nvidia.com/jetson/archives/r36.4.4/DeveloperGuide/SD/Security/FSKP.html
OE4T / meta-tegra — OpenEmbedded/Yocto support for NVIDIA Jetson