Ingegneria del BIOS e del firmware

L'hardware si avvia, ma il prodotto no

Lo sviluppo del firmware ha inizio dopo che la scheda si è accesa

Una scheda madre può completare il POST e tuttavia non essere compatibile con il prodotto installato. Potrebbe arrestarsi sul dispositivo di avvio errato, rimanere spenta dopo il ripristino dell’alimentazione di rete, mostrare opzioni di configurazione che gli operatori sul campo non dovrebbero mai modificare, segnalare un’identità del prodotto errata o non riuscire a riprendersi quando il software applicativo smette di rispondere.

L'ingegneria del firmware traduce tali requisiti di prodotto in un comportamento controllato della piattaforma. Il punto di partenza è costituito da una specifica revisione della scheda madre, dalla versione corrente del firmware, dall'immagine del sistema operativo, dai dispositivi collegati, dai requisiti relativi allo stato di alimentazione, dalla politica di sicurezza e dal metodo di aggiornamento.

Progettazione personalizzata di schede Mini-ITX → Specifiche della piattaforma →

Ambito di applicazione del firmware a livello di prodotto

Cosa è possibile configurare nel BIOS e nel firmware UEFI

Impostazioni predefinite

Priorità di avvio, dispositivi abilitati, virtualizzazione, modalità di archiviazione, impostazioni seriali, opzioni di sicurezza e impostazioni predefinite di produzione.

Configurazione dell'accesso

Nascondere i menu selezionati, limitare le modifiche, impostare l'accesso dell'amministratore e rimuovere le opzioni relative all'assistenza sul campo che devono rimanere sotto il controllo della casa produttrice.

Politica di avvio

NVMe, SATA, USB, PXE o HTTP supportato: priorità di avvio, ordine di ripiego, ritardo di avvio e condizioni di accesso alla modalità di ripristino.

Politica energetica

Ripristino in caso di perdita di alimentazione CA, riattivazione RTC, comportamento di spegnimento graduale, stati di sospensione supportati, e fonti di riattivazione specifiche della scheda.

Identità della piattaforma

Produttore, nome del prodotto, informazioni sul numero di serie, identificativo della scheda, campi SMBIOS, dati relativi alle risorse e modifiche approvate al logo di avvio.

Sicurezza e aggiornamenti

Proprietà della chiave di avvio sicuro, esposizione del TPM, protezione della configurazione, politica di aggiornamento firmato, percorso di ripristino e provisioning in produzione.

Requisiti relativi allo stato di alimentazione

Definire esattamente cosa succede all'avvio, allo spegnimento e al ritorno alla corrente alternata

Le apparecchiature non presidiate non possono fare affidamento sul fatto che un tecnico prema un tasto dopo un evento di alimentazione. Il comportamento di avvio e di alimentazione deve essere definito in base all'effettiva implementazione UEFI, alla logica di alimentazione della scheda, alle unità di archiviazione collegate, al percorso di rete e all'immagine del sistema operativo.

Piattaforme di alimentazione →

Controllo a livello di consiglio di amministrazione

Il firmware può controllare solo ciò che la scheda rende disponibile

I progetti Mini-ITX embedded spesso includono controlli che non compaiono nel BIOS di un computer desktop. Il loro funzionamento dipende dal Super I/O installato, dal controller embedded, dall’espansore GPIO, dal ricetrasmettitore, dal watchdog, dal controller della ventola o dal chipset.

Porte seriali multiple → Piattaforma GPIO e CAN →

Dati dal firmware al sistema operativo

ACPI e SMBIOS devono descrivere l'hardware in dotazione

Il firmware fornisce informazioni standardizzate che il sistema operativo e il software di gestione utilizzano per la configurazione, la gestione dell'alimentazione e l'inventario dell'hardware. Una struttura corretta non è sufficiente; i dati devono corrispondere esattamente alla scheda di produzione e all'identità del prodotto.

Affidabilità pre-avvio

L'avvio sicuro richiede la definizione di un titolare della chiave e di un percorso di aggiornamento

Il Secure Boot in produzione non è semplicemente un’impostazione da attivare o disattivare. Il progetto deve definire chi controlla la chiave di piattaforma, quali chiavi di scambio sono considerate affidabili, quali elementi vengono inseriti nel database delle firme consentite, in che modo le immagini revocate vengono inserite in dbx e come garantire che gli aggiornamenti autorizzati sul campo rimangano recuperabili.

Gli attuali requisiti UEFI stabiliscono che il formato della chiave della piattaforma Secure Boot sia almeno RSA-2048 e richiedono che gli hash delle immagini UEFI memorizzati in dbx utilizzino almeno SHA-256. Si tratta di requisiti crittografici minimi, non di una politica completa di sicurezza del prodotto.

Proprietà di PK

Stabilire se sia l’OEM, il cliente o un altro proprietario autorizzato a gestire la chiave della piattaforma utilizzata per stabilire la titolarità del Secure Boot.

KEK, db e dbx

Definire le autorità di aggiornamento attendibili, le immagini consentite, le firme revocate e il metodo di provisioning utilizzato in produzione.

TPM 2.0

Rendere accessibile e configurare la piattaforma TPM, ove supportata, con la titolarità e la politica di implementazione definite dal sistema finale.

Ripresa

Mantenere un percorso di ripristino autorizzato in caso di aggiornamenti non riusciti o modifiche alle chiavi, senza aggirare la politica di affidabilità prevista.

Sistemi di sicurezza di rete →

Controllo del firmware di produzione

Pubblica il file binario con la relativa scheda, le impostazioni predefinite e il registro delle modifiche

Un file di firmware diventa un artefatto di produzione solo quando ne vengono verificate l'identità e la compatibilità. Il file binario rilasciato deve rimanere associato alla revisione della scheda madre, alla configurazione predefinita, alle impostazioni di sicurezza, al metodo di aggiornamento e al motivo della modifica.

1. Identità binaria Registrare la versione del firmware, la revisione esatta della scheda, la dimensione del file, il digest SHA-256 e la data di rilascio.
2. Impostazioni predefinite di produzione Bloccare i valori di configurazione inviati separatamente dalle impostazioni di debug tecniche e dalle modifiche apportate dai tecnici in loco.
3. Modifica record Identificare le funzioni modificate, l'hardware interessato o le versioni del sistema operativo, i vincoli noti e i controlli di regressione richiesti.
4. Aggiornamento e ripristino Definire il metodo di flashing approvato, la politica relativa alle versioni, le precauzioni in caso di interruzione di corrente, le regole di rollback e il percorso di ripristino.

Specifiche di riferimento

Interfacce firmware e specifiche di riferimento

UEFI 2.11

Specifiche UEFI attuali relative all'ambiente firmware standardizzato pre-sistema operativo, ai servizi di avvio, ai servizi di runtime, alle variabili e ai protocolli.

ACPI 6.6

Attuale specifica ACPI relativa alla configurazione dei dispositivi guidata dal sistema operativo, alla descrizione della piattaforma, alla gestione dell'alimentazione e agli eventi di sistema.

SMBIOS 3.9.0

Specifiche DMTF relative alle informazioni gestionali standardizzate fornite dal firmware di sistema riguardo alla piattaforma e all'hardware installato.

TCG TPM 2.0 v185

Marzo 2026: specifica della libreria TPM 2.0 che definisce l'architettura, le strutture e i comandi utilizzati dalle implementazioni TPM 2.0.

Certificazioni e standard di qualità →

Gate di rilascio del firmware

Verifica che la versione esatta del firmware che intendi distribuire sia quella corretta

Il processo di sviluppo del firmware si conclude con la definizione di un file binario e di una configurazione di produzione. La fase di validazione tecnica prevede quindi l'esecuzione di quella specifica versione sulla scheda di destinazione con l'immagine del sistema operativo prevista, le periferiche, gli stati di alimentazione, le impostazioni di sicurezza, il metodo di aggiornamento e il percorso di ripristino.

Convalida ingegneristica → Tutti i servizi di ingegneria →

FAQ

Domande relative all'ingegneria del BIOS e del firmware