OTA Firmware Update nei Sistemi Embedded: Architettura, Sicurezza e Rollback

Nel mondo dei sistemi embedded professionali, la capacità di aggiornare il firmware da remoto non è più una funzionalità opzionale: è un requisito architetturale. Un dispositivo che non può ricevere aggiornamenti in campo è, per definizione, un sistema che accumula debito tecnico e rischio di sicurezza ad ogni giorno che passa.

Eppure, l'OTA è una di quelle funzionalità che molti team embedded affrontano troppo tardi — come un'aggiunta a posteriori, quando il firmware è già strutturato, la memoria organizzata e il bootloader scelto. Il risultato sono implementazioni fragili, che funzionano in laboratorio ma cedono al primo guasto reale in produzione: un'interruzione di corrente a metà flash, un download corrotto, un boot loop dopo un aggiornamento difettoso.

Progettare un sistema OTA robusto significa fare scelte prima ancora di scrivere la prima riga di codice applicativo. Partizione della memoria, struttura del bootloader, catena crittografica, logica di rollback: tutto questo si decide nella fase di architettura, non nell'ultima settimana prima del rilascio.

La Natura Reale di un Sistema OTA Embedded

Una delle semplificazioni più pericolose è trattare l'OTA come un semplice "trasferimento di file". In realtà, un aggiornamento firmware su un dispositivo embedded è una transazione critica che coinvolge almeno quattro fasi distinte, ciascuna con i propri rischi e requisiti.

La prima fase riguarda il trasporto: il pacchetto firmware deve arrivare al dispositivo in modo integro, autenticato e resistente alle interruzioni. La seconda è la verifica: prima ancora di toccare la flash, il dispositivo deve accertarsi che l'immagine ricevuta sia legittima, non corrotta e compatibile con l'hardware. La terza è la scrittura atomica: l'aggiornamento deve essere applicato in modo tale che un'interruzione in qualsiasi punto non lasci il dispositivo in uno stato inconsistente. La quarta è la validazione post-boot: solo dopo aver verificato che il nuovo firmware funziona correttamente, il sistema deve considerare l'aggiornamento completato.

Saltare o semplificare una qualsiasi di queste fasi non velocizza lo sviluppo — sposta semplicemente il problema in produzione, dove il costo è ordini di grandezza più alto.

Esempio pratico: verificare lo stato OTA corrente su ESP32 (ESP-IDF)

Prima di progettare qualsiasi cosa, è utile capire come il framework espone lo stato delle partizioni OTA:

#include "esp_ota_ops.h"
#include "esp_partition.h"

void check_ota_state(void) {
    const esp_partition_t *running = esp_ota_get_running_partition();
    const esp_partition_t *boot    = esp_ota_get_boot_partition();
    esp_ota_img_states_t state;

    esp_ota_get_state_partition(running, &state);

    ESP_LOGI("OTA", "Running: %s | Boot: %s | State: %d",
             running->label, boot->label, state);
}

Spiegazione: esp_ota_get_running_partition() ti dice da quale slot stai girando, esp_ota_get_boot_partition() quale slot verrà usato al prossimo reset. Se i due non coincidono dopo un aggiornamento, qualcosa nel processo di commit è andato storto.

Perché i Sistemi OTA Falliscono in Produzione

La maggior parte dei fallimenti OTA in campo non deriva da bug complessi o attacchi sofisticati. Deriva da scenari banali che semplicemente non erano stati testati: il dispositivo perde alimentazione durante la scrittura flash, la connessione cade a metà download, il firmware nuovo va in boot loop per un problema di inizializzazione hardware specifico di quel lotto.

Un altro pattern frequente è il testing OTA fatto solo in condizioni ideali — rete stabile, alimentazione garantita, hardware identico al banco di sviluppo. Il campo è diverso: tensioni al limite, temperatura, interferenze RF, varianti hardware non documentate.

Infine, c'è il problema del rollback non testato. Molti sistemi implementano il rollback sulla carta ma non lo verificano mai davvero. Quando serve, si scopre che il bootloader non ha mai fatto effettivamente il fallback, o che lo slot di recovery è stato sovrascritto da un aggiornamento precedente.

Esempio pratico: simulare un'interruzione di corrente durante OTA (STM32)

Su STM32 con HAL, puoi simulare un'interruzione forzando un reset durante la scrittura per verificare il comportamento del bootloader:

/* Nel firmware di test — interrompi deliberatamente a metà scrittura */
HAL_FLASH_Unlock();
for (uint32_t addr = FLASH_SLOT_B_START;
     addr < FLASH_SLOT_B_START + firmware_size;
     addr += FLASH_PAGE_SIZE) {

    FLASH_EraseInitTypeDef erase = {
        .TypeErase = FLASH_TYPEERASE_PAGES,
        .Page      = (addr - FLASH_BASE) / FLASH_PAGE_SIZE,
        .NbPages   = 1
    };
    uint32_t error;
    HAL_FLASHEx_Erase(&erase, &error);

    HAL_FLASH_Program(FLASH_TYPEPROGRAM_DOUBLEWORD, addr, data[i]);

    /* Simula power loss al 50% */
    if (addr == FLASH_SLOT_B_START + firmware_size / 2)
        NVIC_SystemReset();
}
HAL_FLASH_Lock();

Spiegazione: se dopo questo reset il bootloader avvia correttamente il firmware dello slot A, la tua logica di fallback funziona. Se il dispositivo resta bloccato, hai trovato un bug prima di mandarlo in campo.

Architettura della Memoria: La Decisione Più Importante

Prima di scegliere il protocollo di trasporto, prima di integrare qualsiasi libreria OTA, la decisione critica è come organizzare la memoria flash. È una scelta che non si può rivedere facilmente dopo il deployment.

L'approccio single-bank — dove il firmware nuovo sovrascrive direttamente quello attivo — è semplice da implementare ma catastrofico in caso di interruzione. Se la scrittura si interrompe a metà, il dispositivo non ha più un firmware funzionante. L'unica via di recupero è l'accesso fisico.

L'approccio dual-bank (A/B partitioning) mantiene sempre due slot firmware completi: uno attivo, uno di staging. Il nuovo firmware viene scritto nello slot inattivo, verificato, e solo dopo la verifica il bootloader viene istruito a fare il boot dalla nuova partizione. Se qualcosa va storto, il fallback è automatico.

Esempio pratico: layout partizioni per STM32 con dual-bank OTA

/* memory_map.h */
#define BOOTLOADER_START    0x08000000U  /* 32 KB  — mai aggiornabile via OTA */
#define BOOTLOADER_SIZE     0x00008000U

#define SLOT_A_START        0x08008000U  /* 192 KB — firmware attivo          */
#define SLOT_A_SIZE         0x00030000U

#define SLOT_B_START        0x08038000U  /* 192 KB — staging aggiornamento    */
#define SLOT_B_SIZE         0x00030000U

#define OTA_METADATA_START  0x08068000U  /* 4 KB   — flags, versione, CRC     */
#define OTA_METADATA_SIZE   0x00001000U

/* Struttura metadati OTA — in OTA_METADATA_START */
typedef struct {
    uint32_t magic;           /* 0xDEADBEEF — sanity check     */
    uint8_t  active_slot;     /* 0 = Slot A, 1 = Slot B        */
    uint8_t  update_pending;  /* 1 = nuovo fw in Slot B        */
    uint8_t  boot_attempts;   /* contatore tentativi boot      */
    uint8_t  reserved;
    uint32_t slot_b_crc32;    /* CRC32 firmware in Slot B      */
    uint32_t slot_b_size;
    uint32_t fw_version;      /* versione monotona anti-rollback */
} OtaMetadata_t;

Spiegazione: il bootloader legge OtaMetadata_t ad ogni avvio. Se update_pending == 1, verifica il CRC dello Slot B prima di committare il cambio. Se il CRC fallisce o boot_attempts supera la soglia, torna allo Slot A.

Esempio pratico: headroom minimo consigliato

/* Regola empirica per il dimensionamento */

/* Slot size = dimensione attuale firmware × 1.5 (minimo)     */
/* Motivazione:                                                */
/*   - 30% headroom per crescita del codebase                 */
/*   - spazio per delta update staging (se implementato)      */
/*   - buffer per metadati e padding di allineamento          */

/* Esempio: firmware attuale = 120 KB                         */
/*   Slot size consigliato = 180–200 KB                       */

Spiegazione: sottodimensionare gli slot è uno degli errori più comuni. Un firmware che "ci sta" oggi non ci stà più dopo sei mesi di sviluppo attivo.

Il Bootloader: Gatekeeper di Tutto il Sistema OTA

Il bootloader è il componente che rende possibile — o impossibile — qualsiasi schema OTA affidabile. Un bootloader mal progettato vanifica qualsiasi altra misura di sicurezza e robustezza implementata nel firmware applicativo.

Le responsabilità minime di un bootloader OTA-capable sono chiare: verificare l'integrità dell'immagine da avviare, gestire il contatore di tentativi di boot con fallback automatico, proteggere la propria regione da scritture non autorizzate, e implementare la protezione anti-rollback.

Una regola che vale sempre: il bootloader non deve mai essere aggiornabile attraverso lo stesso canale OTA del firmware applicativo. Un bootloader corrotto può rendere il dispositivo permanentemente inutilizzabile senza accesso fisico.

Esempio pratico: logica di boot con fallback automatico (pseudocodice C)

/* bootloader/main.c */
#define MAX_BOOT_ATTEMPTS 3

void bootloader_main(void) {
    OtaMetadata_t meta;
    read_ota_metadata(&meta);

    if (meta.magic != 0xDEADBEEF) {
        /* Prima accensione o metadati corrotti — boot da Slot A */
        boot_from_slot(SLOT_A);
    }

    if (meta.update_pending) {
        /* Nuovo firmware disponibile in Slot B */
        if (!verify_crc32(SLOT_B_START, meta.slot_b_size, meta.slot_b_crc32)) {
            /* CRC fallito — torna a Slot A, annulla aggiornamento */
            meta.update_pending = 0;
            write_ota_metadata(&meta);
            boot_from_slot(SLOT_A);
        }
        if (!verify_signature(SLOT_B_START, meta.slot_b_size)) {
            /* Firma non valida — possibile tampering */
            meta.update_pending = 0;
            write_ota_metadata(&meta);
            boot_from_slot(SLOT_A);
        }
        /* Verifica ok: committa il cambio */
        meta.active_slot    = 1;   /* Slot B */
        meta.update_pending = 0;
        meta.boot_attempts  = 0;
        write_ota_metadata(&meta);
    }

    /* Gestione boot loop */
    uint8_t slot = meta.active_slot;
    meta.boot_attempts++;
    write_ota_metadata(&meta);

    if (meta.boot_attempts > MAX_BOOT_ATTEMPTS) {
        /* Boot loop rilevato — fallback allo slot opposto */
        slot = (slot == 0) ? 1 : 0;
        meta.active_slot   = slot;
        meta.boot_attempts = 0;
        write_ota_metadata(&meta);
    }

    boot_from_slot(slot == 0 ? SLOT_A : SLOT_B);
}

Spiegazione: boot_attempts viene incrementato prima del boot e azzerato dal firmware applicativo solo dopo aver confermato il corretto avvio. Se il firmware va in crash ripetuto prima di poter azzerare il contatore, il bootloader rileva il boot loop e torna allo slot precedente.

Esempio pratico: il firmware applicativo deve "confermare" il boot riuscito

/* Nel firmware applicativo — da chiamare dopo init completata */
void confirm_successful_boot(void) {
    OtaMetadata_t meta;
    read_ota_metadata(&meta);
    meta.boot_attempts = 0;  /* Azzera il contatore: boot ok */
    write_ota_metadata(&meta);

    /* Su ESP32 con ESP-IDF, equivalente a: */
    /* esp_ota_mark_app_valid_cancel_rollback(); */
}

Spiegazione: questo è il dettaglio che distingue un sistema OTA robusto da uno che "di solito funziona". Se l'app non chiama questa funzione entro un timeout, al prossimo reset il bootloader capisce che qualcosa è andato storto.

Sicurezza OTA: La Catena Crittografica End-to-End

Un canale OTA non protetto è peggio di nessun OTA: diventa un vettore di attacco diretto verso l'hardware. Un attaccante che riesce a iniettare firmware non autorizzato ottiene accesso completo al sistema, senza bisogno di exploit applicativi.

La sicurezza di un sistema OTA si costruisce su tre livelli indipendenti e complementari: autenticità del firmware (firma digitale), confidenzialità e integrità del canale di trasporto (TLS), autenticazione del dispositivo (certificati o token device-specifici). Rimuovere uno qualsiasi di questi livelli crea vulnerabilità reali.

Esempio pratico: generare e verificare la firma ECDSA del firmware (Python + openssl)

# ---- Lato build server ----

# Genera chiave privata (da conservare su HSM, mai su repo)
openssl ecparam -name prime256v1 -genkey -noout -out fw_signing_key.pem

# Estrai chiave pubblica (va flashata nel bootloader)
openssl ec -in fw_signing_key.pem -pubout -out fw_public_key.pem

# Firma il firmware binario
openssl dgst -sha256 -sign fw_signing_key.pem \
    -out firmware_v2.sig firmware_v2.bin

# ---- Lato bootloader (C, verifica con mbedTLS) ----

#include "mbedtls/ecdsa.h"
#include "mbedtls/sha256.h"

/* Chiave pubblica hardcoded nel bootloader (generata offline) */
static const uint8_t PUBLIC_KEY_DER[] = { /* ... bytes ... */ };

int verify_firmware_signature(const uint8_t *fw, size_t fw_len,
                              const uint8_t *sig, size_t sig_len) {
    uint8_t hash[32];
    mbedtls_sha256(fw, fw_len, hash, 0);

    mbedtls_ecdsa_context ctx;
    mbedtls_ecdsa_init(&ctx);
    mbedtls_ecp_keypair_init(&ctx);

    /* Carica chiave pubblica */
    mbedtls_pk_context pk;
    mbedtls_pk_init(&pk);
    mbedtls_pk_parse_public_key(&pk, PUBLIC_KEY_DER, sizeof(PUBLIC_KEY_DER));

    int ret = mbedtls_ecdsa_read_signature(
        mbedtls_pk_ec(pk), hash, sizeof(hash), sig, sig_len);

    mbedtls_pk_free(&pk);
    return (ret == 0) ? 0 : -1;  /* 0 = firma valida */
}

Spiegazione: la chiave privata non abbandona mai il build server (idealmente un HSM). Il bootloader contiene solo la chiave pubblica: può verificare ma non firmare. Anche se un attaccante ottiene accesso alla flash del dispositivo, non può estrarre la chiave per firmare firmware malevolo.

Esempio pratico: protezione anti-rollback con versione monotona

/* Nel bootloader, prima di accettare un aggiornamento */
int check_antirollback(uint32_t new_version) {
    OtaMetadata_t meta;
    read_ota_metadata(&meta);

    if (new_version < meta.fw_version) {
        /* Tentativo di downgrade — rifiuta */
        return -1;
    }
    if (new_version == meta.fw_version) {
        /* Stessa versione — accetta solo per reinstallazione esplicita */
        return 0;
    }
    /* Versione superiore — aggiornamento legittimo */
    meta.fw_version = new_version;
    write_ota_metadata(&meta);
    return 0;
}

Spiegazione: la versione firmware viene memorizzata in una regione protetta. Qualsiasi tentativo di installare una versione precedente viene bloccato a livello di bootloader, indipendentemente dalla firma. Questo previene gli attacchi di downgrade verso versioni con vulnerabilità già note e patchate.

Il Protocollo di Trasporto: Scegliere in Base al Contesto

Non esiste un protocollo OTA universalmente ottimale. La scelta dipende dalle caratteristiche del dispositivo, dall'ambiente di deployment e dai requisiti di affidabilità. La tabella seguente riassume i pattern più comuni:

Esempio pratico: download OTA con ripresa su connessione interrotta (ESP32)

#include "esp_http_client.h"
#include "esp_ota_ops.h"

#define OTA_URL         "https://update.example.com/firmware_v2.bin"
#define CHUNK_SIZE      4096

void ota_task(void *arg) {
    esp_ota_handle_t ota_handle;
    const esp_partition_t *update_part = esp_ota_get_next_update_partition(NULL);
    esp_ota_begin(update_part, OTA_SIZE_UNKNOWN, &ota_handle);

    /* Leggi offset già scaricato (da NVS, sopravvive al reset) */
    uint32_t resume_offset = nvs_get_download_offset();

    esp_http_client_config_t cfg = {
        .url = OTA_URL,
        .cert_pem = server_cert_pem,  /* Verifica TLS */
    };
    esp_http_client_handle_t client = esp_http_client_init(&cfg);

    /* HTTP Range request per riprendere dal punto interrotto */
    char range_header[64];
    snprintf(range_header, sizeof(range_header), "bytes=%lu-", resume_offset);
    esp_http_client_set_header(client, "Range", range_header);
    esp_http_client_open(client, 0);

    uint8_t buf[CHUNK_SIZE];
    int read_len;
    while ((read_len = esp_http_client_read(client, (char*)buf, CHUNK_SIZE)) > 0) {
        esp_ota_write(ota_handle, buf, read_len);
        resume_offset += read_len;
        nvs_set_download_offset(resume_offset);  /* Checkpoint */
    }

    esp_ota_end(ota_handle);
    esp_ota_set_boot_partition(update_part);

    nvs_clear_download_offset();  /* Pulizia checkpoint */
    esp_restart();
}

Spiegazione: l'offset di download viene salvato in NVS (Non-Volatile Storage) ad ogni chunk ricevuto. In caso di interruzione — reset, caduta di rete, batteria scarica — il download riprende esattamente da dove si era fermato, senza scaricare nuovamente l'intero firmware.

Esempio pratico: delta update con heatshrink (riduzione payload)

# Lato server: genera patch binaria tra versione corrente e nuova
# Usa bsdiff (cross-platform, adatto a firmware binari)

bsdiff firmware_v1.bin firmware_v2.bin firmware_v1_to_v2.patch

# Dimensioni tipiche:
# firmware_v1.bin  →  256 KB
# firmware_v2.bin  →  258 KB  (cambio di 2 funzioni)
# patch            →   ~8 KB  (riduzione ~97%)

# Il dispositivo applica la patch in locale:
# bspatch firmware_v1.bin firmware_v2_reconstructed.bin firmware_v1_to_v2.patch

Spiegazione: il delta update è fondamentale su connessioni cellulari NB-IoT o LoRaWAN dove il costo energetico e monetario della trasmissione è rilevante. Una patch dell'8% rispetto al firmware completo può fare la differenza tra un aggiornamento riuscito e una batteria scarica a metà trasferimento.

Gestione dei Guasti: Il Vero Test di un Sistema OTA

Un sistema OTA viene giudicato non su come si comporta nelle condizioni ideali, ma su come sopravvive alle condizioni peggiori. Interruzione di corrente a metà flash, download corrotto, boot loop dopo un aggiornamento difettoso: questi scenari devono essere testati esplicitamente, non speranzosamente evitati.

Il watchdog hardware è l'ultima rete di sicurezza. Deve essere configurato per rilevare non solo crash espliciti, ma anche boot loop — situazioni in cui il firmware si avvia, fallisce durante l'inizializzazione e si riavvia continuamente senza mai diventare operativo.

Esempio pratico: staged rollout — non aggiornare tutto il fleet in una volta

# Esempio di configurazione staged rollout su Mender (mender.conf)
# Fase 1: 5% del fleet (canary)
{
  "deployment": {
    "filter": { "tags": ["canary"] },
    "max_devices": 50,
    "phases": [
      { "batch_size": 5, "delay_before_next": "24h" },
      { "batch_size": 20, "delay_before_next": "48h" },
      { "batch_size": 75 }
    ]
  }
}

# Metriche di successo da monitorare prima di avanzare alla fase successiva:
# - boot_success_rate > 99%
# - crash_rate < 0.1%
# - watchdog_triggers == 0
# - app_ready_time entro soglia attesa

Spiegazione: distribuire un aggiornamento al 100% del fleet in un colpo solo è il modo più rapido per trasformare un bug sfuggito al testing in un'emergenza su scala. Il canary deployment limita il blast radius: se il 5% dei dispositivi mostra problemi, l'aggiornamento viene bloccato prima di propagarsi.

Esempio pratico: monitorare lo stato del fleet con GPIO marker (recuperato dall'architettura di boot)

/* Nel firmware applicativo, dopo che l'OTA è stata applicata e
   l'app è operativa — stessa tecnica del boot marker */

void app_ready_after_ota(void) {
    /* 1. Conferma al bootloader che il boot è andato a buon fine */
    confirm_successful_boot();

    /* 2. Segnala allo stack di telemetria che l'aggiornamento è completato */
    telemetry_send_event("ota_success", current_fw_version());

    /* 3. Marker fisico (utile in fase di test con logic analyzer) */
    gpio_set_level(GPIO_APP_READY, 1);
}

Spiegazione: la conferma al bootloader, la notifica al sistema di telemetria e il marker fisico sono tre operazioni distinte ma complementari. La prima evita rollback indesiderati, la seconda permette il monitoring remoto del fleet, la terza rende verificabile il comportamento in laboratorio prima del deployment.

OTA su Linux Embedded: Complessità Diverse

Su sistemi Linux embedded, l'OTA non riguarda solo il firmware applicativo: l'intero stack può richiedere aggiornamenti coordinati. Kernel, device tree, root filesystem, librerie, applicazioni — tutto ha dipendenze che devono essere gestite in modo atomico.

I due framework open source più consolidati sono SWUpdate e Mender. SWUpdate lavora con pacchetti SWUPD contenenti un manifest firmato e le immagini da installare, ed è ampiamente usato in ambito industriale europeo. Mender introduce il concetto di Artifact — un container con metadati di compatibilità hardware, script di pre/post-installazione e immagini cifrate — con un'integrazione cloud nativa per la gestione del fleet.

Esempio pratico: struttura sw-description per SWUpdate

/* sw-description — manifest firmato nel pacchetto SWUPD */
software =
{
    version = "2.1.0";
    hardware-compatibility = ["1.0", "1.1", "2.0"];

    images: (
        {
            filename = "rootfs.ext4.gz";
            type     = "raw";
            device   = "/dev/mmcblk0p2";
            sha256   = "a1b2c3d4...";
            compressed = true;
        },
        {
            filename = "kernel.itb";
            type     = "raw";
            device   = "/dev/mmcblk0p1";
            sha256   = "e5f6a7b8...";
        }
    );

    scripts: (
        {
            filename  = "post_install.sh";
            type      = "shellscript";
            /* Eseguito dopo la scrittura, prima del reboot */
        }
    );
}

Spiegazione: il campo hardware-compatibility è fondamentale — impedisce che un firmware compilato per una revisione hardware venga installato su una revisione diversa. Il sha256 di ogni componente viene verificato da SWUpdate prima della scrittura, non dopo.

Esempio pratico: U-Boot environment per gestire slot A/B su Linux embedded

# /etc/fw_env.config — mappa l'environment U-Boot
/dev/mmcblk0    0x3F000   0x1000

# Leggi lo slot attivo corrente
fw_printenv mmcpart

# Dopo un aggiornamento riuscito, conferma il cambio slot
fw_setenv mmcpart 2          # Slot B
fw_setenv upgrade_available 0  # Disabilita rollback automatico

# In caso di rollback manuale
fw_setenv mmcpart 1          # Torna a Slot A
reboot

Spiegazione: U-Boot legge upgrade_available ad ogni avvio. Se vale 1, decrementa bootcount. Quando bootcount supera bootlimit, U-Boot torna automaticamente allo slot precedente — lo stesso meccanismo del contatore boot_attempts visto per i microcontrollori, ma implementato nelle variabili d'ambiente di U-Boot.

OTA e Cyber Resilience Act: Cosa Cambia Concretamente

Dal marzo 2025, il Cyber Resilience Act (CRA) europeo è formalmente in vigore. Per chi sviluppa dispositivi connessi destinati al mercato europeo, le implicazioni sul sistema OTA sono concrete e non delegabili.

L'obbligo di aggiornabilità richiede che i prodotti possano ricevere patch di sicurezza per tutto il ciclo di vita commerciale previsto. I log di aggiornamento devono essere verificabili — timestamp, hash delle immagini, esito dell'installazione — con un audit trail che dimostri la conformità. La generazione automatica di SBOM (Software Bill of Materials) deve essere parte del processo di build, non un'attività manuale.

Esempio pratico: generare SBOM automaticamente con Yocto/BitBake

# In local.conf del progetto Yocto
INHERIT += "create-spdx"

# Genera SBOM in formato SPDX 2.3 per ogni build
# Output: ${DEPLOY_DIR}/spdx/${MACHINE}/

# Include dipendenze ricorsive di tutti i pacchetti
SPDX_PRETTY = "1"

# Verifica versioni con vulnerabilità note (CVE check)
INHERIT += "cve-check"
CVE_CHECK_REPORT_PATCHED = "1"

Spiegazione: Yocto genera automaticamente l'SBOM completo di ogni build, incluse le versioni esatte di kernel, librerie e applicazioni. Il CVE check confronta le versioni usate con il database delle vulnerabilità note e segnala quelle non ancora patchate. Questo non è solo compliance: è uno strumento operativo per decidere quando e cosa aggiornare via OTA.

Esempio pratico: log di aggiornamento per audit trail

/* Nel firmware: registra ogni evento OTA in area NVS con timestamp */
typedef struct {
    uint32_t timestamp;          /* Unix timestamp                   */
    uint32_t from_version;       /* Versione firmware precedente     */
    uint32_t to_version;         /* Versione firmware installata     */
    uint8_t  result;             /* 0=successo, 1=fallito, 2=rollback*/
    uint8_t  trigger;            /* 0=automatico, 1=manuale          */
    uint8_t  reserved[2];
    uint32_t image_crc32;        /* CRC del firmware installato      */
} OtaLogEntry_t;

void log_ota_event(OtaLogEntry_t *entry) {
    /* Scrivi in area NVS circolare — ultimi N eventi */
    nvs_set_blob(nvs_handle, "ota_log_latest", entry, sizeof(OtaLogEntry_t));
    /* Invia anche al backend di telemetria */
    telemetry_send_ota_event(entry);
}

Spiegazione: il CRA richiede che il produttore possa dimostrare quando un dispositivo ha ricevuto un aggiornamento e se è andato a buon fine. Questo log, combinato con i dati del backend, costituisce l'audit trail necessario per la conformità.

L'OTA Come Problema di Architettura

Progettare l'OTA come un'aggiunta tardiva — un layer inserito quando il firmware è già completo — è la causa principale dei sistemi di aggiornamento fragili. Le scelte che determinano la qualità del sistema OTA vengono fatte molto prima: nella dimensione della flash, nel design del bootloader, nella scelta del microcontrollore, nella struttura del filesystem.

Il principio ingegneristico più efficace resta sorprendentemente semplice: ogni componente del sistema OTA deve essere progettato per fallire in modo sicuro. Non "progettato per funzionare" — progettato per fallire senza lasciare il dispositivo in uno stato irrecuperabile.

Conclusione

Un sistema embedded senza OTA robusto è un prodotto con data di scadenza incorporata. Le vulnerabilità vengono scoperte, i requisiti cambiano, i bug emergono in produzione. La capacità di aggiornare in campo non è una feature: è ciò che trasforma un prodotto embedded in un sistema con un ciclo di vita reale.

Come per il boot time, non esiste una soluzione universale. Ma i fondamentali sono chiari: architettura dual-bank, bootloader con rollback automatico, firma crittografica del firmware, protezione anti-rollback, staged rollout. Implementare correttamente questi elementi richiede lavoro nelle prime fasi del progetto — ma evita interventi fisici in campo che costano ordini di grandezza di più.