Il firmware è software progettato per controllare o inizializzare uno specifico componente hardware. Può occuparsi dell’avvio di un dispositivo, della gestione delle periferiche, delle operazioni di input/output o di funzioni più ampie, a seconda del sistema.
Definirlo semplicemente come qualcosa “a metà tra hardware e software” aiuta solo fino a un certo punto. Si tratta a tutti gli effetti di software: ciò che lo distingue dalle normali applicazioni è soprattutto il legame molto stretto con l’hardware su cui viene eseguito, con il processo di avvio e con le funzioni fondamentali del dispositivo.
Questo spiega perché lo trovi in prodotti molto diversi fra loro: PC, router, smartphone, SSD, stampanti, televisori, fotocamere, dispositivi IoT e microcontrollori.
La documentazione IBM dedicata al firmware lo descrive come codice incorporato nei dispositivi hardware e utilizzato, tra le altre cose, per l’avvio, la comunicazione e le operazioni di input/output.
Il punto importante, però, non è imparare una definizione. È capire dove si colloca questo codice nel sistema, cosa controlla e cosa cambia quando viene aggiornato.
Che cos’è il firmware e perché è legato all’hardware
Per capire che cos’è il firmware conviene partire dal rapporto con il componente che deve controllare. Non è la memoria utilizzata a definirlo e nemmeno il fatto che sia invisibile all’utente: ciò che conta è la funzione svolta all’interno del dispositivo e quanto quella funzione dipenda dall’hardware specifico.
Questa relazione può essere molto stretta. In alcuni prodotti il codice incorporato gestisce direttamente sensori, controller o periferiche; in altri partecipa alle prime fasi di avvio e prepara l’ambiente necessario ai livelli software successivi.
Il firmware è software, ma svolge un ruolo diverso dalle normali applicazioni
Un’applicazione e un firmware sono entrambi costituiti da codice, ma normalmente lavorano a livelli differenti.
Un browser, un editor di testo o un’app per smartphone vengono eseguiti sopra un sistema operativo e sono progettati soprattutto per fornire funzioni all’utente.
Il codice integrato nel dispositivo tende invece a operare molto più vicino all’hardware.
Può, per esempio:
- inizializzare componenti elettronici;
- configurare periferiche;
- leggere sensori;
- controllare motori o attuatori;
- gestire memoria e controller;
- rendere disponibile un dispositivo al sistema operativo;
- implementare funzioni di avvio o recovery.
Su un microcontrollore molto semplice, il programma memorizzato può coincidere praticamente con tutta la logica che il dispositivo deve eseguire.
Su un computer moderno la situazione è invece più stratificata: motherboard, controller di storage, periferiche di rete e altri componenti possono avere ciascuno il proprio software a basso livello.
Questo è il primo errore da evitare: “firmware” non identifica necessariamente un singolo programma presente nel dispositivo.
Dove viene memorizzato: ROM, EEPROM e memoria flash
Il codice necessario al funzionamento di base deve generalmente essere disponibile anche dopo che il dispositivo viene spento. Per questo viene normalmente conservato in memoria non volatile.
Storicamente era comune associarlo alla ROM, cioè memoria di sola lettura. Nei sistemi moderni sono molto diffuse memorie riprogrammabili, soprattutto flash, proprio perché permettono di distribuire aggiornamenti senza sostituire fisicamente un componente.
A seconda dell’architettura puoi quindi incontrare ROM, EEPROM, memoria flash o combinazioni differenti.
Non bisogna però trasformare il tipo di memoria in una definizione.
Ciò che conta è la funzione svolta dal codice e il suo rapporto con l’hardware, non semplicemente il fatto che sia memorizzato in una ROM.
Esistono inoltre sistemi nei quali una parte del software necessario al dispositivo viene caricata durante il boot. Anche in questo caso il concetto non cambia, pur essendo diverso il modo in cui il codice viene archiviato e avviato.
Perché non esiste un’unica forma di firmware
Confronta tre casi.
Un microcontrollore che legge un sensore può eseguire direttamente un piccolo programma dedicato.
Un SSD utilizza codice interno per governare controller, memoria NAND, gestione degli errori, wear leveling e altre operazioni che restano invisibili al normale utente.
Un PC possiede invece un intero livello di platform firmware che partecipa all’inizializzazione del sistema prima dell’avvio del normale sistema operativo.
Chiamare tutti e tre questi elementi “firmware” è corretto, ma non significa che funzionino allo stesso modo.
Per capire davvero un dispositivo conviene quindi chiedere:
quale componente esegue questo codice e quale responsabilità gli è affidata?
Questa domanda è molto più utile di una definizione rigida basata soltanto sulla posizione in memoria.
Come funziona il firmware in un dispositivo
Sapere che il firmware è legato all’hardware non basta per capire come intervenga nel funzionamento reale. Il suo ruolo emerge soprattutto osservando cosa succede quando il dispositivo viene acceso e quali componenti devono essere preparati prima che possa iniziare l’attività normale.
La sequenza cambia molto tra un microcontrollore, un router e un PC. Il principio comune è che esiste un livello di codice capace di inizializzare o governare l’hardware prima, oppure indipendentemente, dalle normali applicazioni.
Cosa succede dall’accensione al controllo dell’hardware
Il funzionamento cambia in base all’architettura, ma possiamo partire da un modello semplice.
Quando un dispositivo riceve alimentazione, il processore o il microcontrollore deve sapere quale codice eseguire per primo.
Su un sistema embedded elementare il percorso può essere vicino a questo:
accensione → reset → firmware → inizializzazione hardware → funzione prevista
Il programma configura le risorse necessarie e inizia a eseguire la logica per cui il dispositivo è stato progettato.
In un computer il percorso è più articolato:
accensione → platform firmware → inizializzazione hardware → bootloader → sistema operativo
Il livello iniziale prepara quindi l’ambiente necessario affinché il software successivo possa prendere il controllo.
È proprio questa struttura a strati a spiegare perché alcuni problemi possano presentarsi prima ancora che Windows, Linux o un altro sistema operativo abbiano iniziato realmente a funzionare.
Firmware semplice, sistemi embedded e platform firmware
In un progetto embedded il programma può controllare direttamente pin, timer, bus di comunicazione e periferiche.
È ciò che accade, per esempio, in molte schede a microcontrollore. Nella nostra guida ad Arduino il flusso è particolarmente evidente:
codice → compilazione → firmware → microcontrollore → periferiche
Una volta caricato il programma, il microcontrollore può eseguirlo autonomamente senza avere bisogno di un sistema operativo general-purpose.
Un single-board computer è diverso. Nella guida a Raspberry Pi distinguiamo infatti i computer Raspberry Pi, che normalmente eseguono un sistema operativo, dalla famiglia Pico, basata su microcontrollori e pensata per eseguire programmi dedicati.
Questa distinzione evita una semplificazione frequente:
dispositivo elettronico ≠ necessariamente computer con sistema operativo
Molti oggetti programmabili hanno bisogno di software, ma non per questo hanno bisogno di Windows, Android o Linux.
Esempi concreti: PC, router, smartphone, SSD, stampanti e microcontrollori
Il concetto diventa più semplice osservando che cosa viene controllato nei diversi dispositivi.
PC: il platform firmware inizializza componenti, prepara l’ambiente di boot e mette a disposizione servizi utilizzati prima o durante l’avvio del sistema.
Router: il software integrato può occuparsi di una parte molto ampia del funzionamento, dalla gestione dell’hardware alle funzioni di rete e amministrazione.
Smartphone: convivono più livelli software. Android, i driver e il codice specifico dei vari componenti non sono la stessa cosa; la nostra guida ad Android approfondisce questa architettura a strati.
SSD: il controller esegue software dedicato per gestire memoria NAND, errori, allocazione dei dati e altre funzioni interne che il sistema operativo non governa direttamente.
Stampanti: il codice incorporato può controllare motori, sensori, interfacce di comunicazione, consumabili e logica operativa.
Microcontrollori: il programma caricato può rappresentare quasi tutta la logica applicativa del prodotto.
Il termine rimane lo stesso, ma il confine fra software di basso livello, sistema operativo e applicazione può cambiare molto da un dispositivo all’altro.
Firmware, software, driver, BIOS/UEFI e bootloader: le differenze
Firmware, driver, BIOS, UEFI e bootloader vengono spesso nominati insieme perché operano vicino all’hardware o intervengono durante l’avvio. Questo non significa però che svolgano lo stesso compito.
La distinzione più utile non consiste nel chiedersi quale di questi elementi sia “più vicino” all’hardware in senso assoluto, ma dove viene eseguito, quale componente controlla e quale livello software dipende dal suo funzionamento.
| Componente | Dove opera principalmente | Funzione tipica | Legame con l’hardware |
|---|---|---|---|
| Firmware | sul dispositivo o sulla piattaforma | controllo, inizializzazione, funzioni di basso livello | molto stretto |
| Sistema operativo | sul computer o dispositivo host | gestione delle risorse e piattaforma per le applicazioni | medio/alto |
| Driver | nel sistema operativo | permette all’OS di gestire uno specifico hardware | specifico per hardware e OS |
| Applicazione | sopra l’OS | funzione rivolta all’utente o a un servizio | generalmente più debole |
| Bootloader | fase di avvio | carica o avvia il livello software successivo | stretto |
| BIOS/UEFI | platform firmware | inizializzazione e ambiente pre-boot | molto stretto |
La tabella descrive ruoli tipici, non compartimenti sempre impermeabili. Le architetture moderne possono sovrapporre alcune responsabilità.
Firmware e software: cosa cambia davvero
La contrapposizione firmware e software è utile soltanto se non la interpreti come una separazione assoluta.
Il primo appartiene infatti alla più ampia categoria del software.
La differenza riguarda soprattutto:
- il grado di dipendenza dall’hardware;
- il livello al quale il codice viene eseguito;
- la funzione svolta;
- il modo in cui viene distribuito;
- la frequenza e il rischio degli aggiornamenti;
- il rapporto con il processo di avvio.
Un’applicazione viene normalmente sostituita, installata o rimossa senza cambiare il comportamento fondamentale dell’hardware.
Un’immagine sbagliata destinata a un componente può invece impedire che quel dispositivo si inizializzi o funzioni correttamente.
È per questo che gli update a basso livello richiedono spesso più attenzione rispetto all’aggiornamento di una normale app.
Firmware e driver non svolgono lo stesso compito
Driver e firmware lavorano spesso insieme, ma non sono sinonimi.
In forma semplificata:
applicazione → sistema operativo → driver → dispositivo
Il driver è normalmente software eseguito dal sistema operativo. Traduce o coordina le richieste del sistema affinché possano essere gestite dall’hardware.
Il codice incorporato viene invece eseguito sul dispositivo o sul componente controllato.
Prendi una periferica USB.
Il computer può usare un driver per comunicare con la periferica, mentre il microcontrollore interno esegue il proprio programma.
Il confine può sembrare meno evidente quando anche la distribuzione degli aggiornamenti coinvolge i driver. Microsoft, per esempio, documenta un meccanismo in cui Windows Update può distribuire pacchetti che contengono il payload firmware.
Questo non rende però driver e firmware la stessa cosa: il pacchetto e il driver possono partecipare alla distribuzione, mentre il payload è destinato al dispositivo.
BIOS e UEFI sono firmware, ma firmware non significa BIOS
BIOS e UEFI appartengono alla famiglia del platform firmware dei PC.
Non sono quindi sinonimi generali dell’intera categoria.
Un SSD possiede il proprio codice interno. Lo stesso vale per molti router, controller e periferiche, anche se non hanno nulla a che vedere con il BIOS di un computer.
UEFI definisce invece un ambiente standardizzato fra sistema operativo e platform firmware, includendo strutture dati e servizi disponibili durante il boot e in altre fasi della vita del sistema. La documentazione dell’UEFI Forum descrive questa relazione fra sistema operativo e piattaforma.
La relazione corretta è quindi:
UEFI → standard/interfaccia per il platform firmware
e non:
firmware = UEFI
Bootloader e microcodice: dove si collocano
Anche il bootloader viene spesso confuso con il firmware.
Un bootloader è un programma specializzato nell’avvio o nel caricamento del software successivo. In alcuni dispositivi embedded può essere esso stesso una componente del software complessivo memorizzato sull’hardware.
Su una scheda a microcontrollore, per esempio, un piccolo bootloader può permettere di caricare un nuovo programma senza utilizzare ogni volta un programmatore esterno.
Il microcodice appartiene invece a un livello ancora più basso e riguarda l’implementazione interna di determinate operazioni del processore.
Anche qui il sistema di distribuzione può generare confusione, perché alcuni aggiornamenti di microcodice vengono caricati durante il boot.
La regola pratica è evitare di utilizzare tutti questi termini come sinonimi soltanto perché si trovano “vicino all’hardware”.
Aggiornamento firmware: quando serve e quando non va forzato
Aggiornare il software incorporato di un dispositivo può essere necessario per correggere problemi, chiudere vulnerabilità o migliorare la compatibilità. È però un’operazione diversa dall’installazione di una normale applicazione, perché un errore può coinvolgere componenti indispensabili all’avvio o al funzionamento dell’hardware.
Per questo un aggiornamento firmware dovrebbe iniziare dalla verifica del modello, della revisione hardware, della versione installata e delle istruzioni ufficiali. L’obiettivo non è installare sempre “l’ultima versione”, ma capire se l’update è pertinente al proprio dispositivo e come eseguirlo senza introdurre un rischio evitabile.
Perché un produttore rilascia un nuovo firmware
Le ragioni più comuni sono:
- correzione di bug;
- mitigazione di problemi di sicurezza;
- miglioramento della stabilità;
- supporto a nuovi componenti;
- correzione di incompatibilità;
- modifica di comportamenti interni;
- introduzione di nuove funzionalità.
Il changelog o le note di rilascio servono proprio a capire cosa cambia e se quel cambiamento riguarda davvero il tuo dispositivo.
Se tutto funziona, non esiste una regola universale secondo cui bisogna installare immediatamente qualsiasi nuova versione.
Allo stesso modo, ignorare una correzione di sicurezza rilevante soltanto perché “il dispositivo funziona” può essere una scelta sbagliata.
La decisione va presa sul contenuto dell’update, sul supporto del produttore e sul rischio concreto.
Come controllare la versione firmware installata
Non esiste un percorso universale.
La versione firmware può essere visibile:
- nelle impostazioni del dispositivo;
- nel BIOS/UEFI;
- nel pannello di amministrazione;
- nell’app ufficiale del produttore;
- in un software di gestione;
- nel sistema operativo;
- tramite un comando o un tool diagnostico.
Prima di cercare un aggiornamento devi identificare almeno:
produttore → modello esatto → eventuale revisione hardware → versione installata
La revisione hardware è particolarmente importante.
Due dispositivi commercializzati con nomi quasi identici possono utilizzare componenti differenti e richiedere immagini incompatibili fra loro.
Prima dell’aggiornamento: modello, revisione hardware, compatibilità e changelog
Prima di installare un nuovo firmware conviene fare questi controlli:
- Identifica il dispositivo esatto. Non fermarti al nome della famiglia commerciale.
- Controlla la revisione hardware, se il produttore ne utilizza più di una.
- Verifica la versione installata.
- Leggi changelog e avvertenze della release.
- Usa la fonte ufficiale o il meccanismo previsto dal produttore.
- Controlla prerequisiti e compatibilità.
- Verifica alimentazione e condizioni di recovery.
- Salva configurazioni o dati importanti quando il tipo di dispositivo lo richiede.
Su smartphone e sistemi complessi è particolarmente rischioso confondere un’immagine prevista per un modello con quella destinata a un altro.
Per questo, quando il produttore non prevede espressamente una procedura, è meglio evitare pacchetti trovati casualmente online.
Come aggiornare il firmware in sicurezza senza usare una procedura universale
Non esiste un comando valido per qualsiasi hardware.
Un dispositivo può ricevere l’aggiornamento:
- tramite il sistema operativo;
- con un’utility del produttore;
- dal pannello web;
- attraverso un’applicazione mobile;
- via USB;
- mediante un bootloader;
- durante il boot;
- over-the-air.
Su Windows esistono anche meccanismi specifici per distribuire questi aggiornamenti tramite Windows Update e UEFI. Microsoft documenta sia la distribuzione attraverso Windows Update sia la piattaforma UEFI per gli aggiornamenti.
Il punto non è scegliere uno di questi metodi arbitrariamente.
Devi usare quello previsto per il tuo modello dal produttore.
Se la documentazione ufficiale dice di lasciare il dispositivo collegato all’alimentazione, non interrompere il processo o rimuovere determinate periferiche, quelle istruzioni fanno parte della procedura e non sono dettagli facoltativi.
Cosa succede se l’aggiornamento fallisce: bricking, recovery e rollback
Un update interrotto o incompatibile può lasciare il dispositivo in uno stato in cui non riesce più ad avviarsi correttamente.
In gergo si parla spesso di brick quando l’hardware diventa inutilizzabile, o apparentemente tale, a causa del software a basso livello.
Non tutti i brick sono definitivi.
Un prodotto può prevedere:
- una seconda immagine di sistema;
- una partizione di recovery;
- un bootloader protetto;
- una modalità di emergenza;
- un ripristino tramite USB;
- un rollback alla versione precedente;
- una procedura con programmatore esterno.
Queste possibilità dipendono però dall’hardware.
Dell, per esempio, documenta specifiche procedure di BIOS recovery per i sistemi compatibili e distingue il normale aggiornamento dal recupero di BIOS/UEFI danneggiato.
È un buon esempio del motivo per cui conviene verificare prima se esiste una procedura di recovery, invece di scoprirlo quando qualcosa è già andato storto.
Firmware e sicurezza: perché gli aggiornamenti contano
La sicurezza è uno dei motivi per cui il livello firmware merita particolare attenzione. Un componente che viene eseguito prima del sistema operativo o che controlla direttamente una periferica può trovarsi in una posizione privilegiata rispetto al normale software applicativo.
Questo non significa che ogni vulnerabilità sia automaticamente critica. Significa piuttosto che protezione dell’integrità, autenticità degli aggiornamenti e possibilità di recovery assumono un peso particolare, soprattutto nei dispositivi connessi o destinati a rimanere operativi a lungo.
Vulnerabilità e compromissioni a un livello difficile da ripristinare
Una vulnerabilità a questo livello può esporre funzioni sensibili o consentire modifiche non autorizzate.
Negli scenari più gravi, una compromissione può offrire persistenza al di sotto del normale sistema operativo.
Il NIST, nelle sue linee guida sulla resilienza del platform firmware, organizza il problema attorno a tre capacità: protezione, rilevamento e recovery.
La logica è importante: non basta impedire modifiche non autorizzate. Bisogna poterle rilevare e disporre di un percorso per riportare il sistema a uno stato integro.
Se vuoi approfondire il problema della persistenza, la nostra guida alle backdoor mostra perché una compromissione che coinvolge software a basso livello o supply chain non può essere trattata come la semplice reinstallazione di una normale applicazione.
Integrità, firma degli aggiornamenti e provenienza del firmware
Scaricare un file con il nome giusto non dimostra che sia autentico.
Un buon meccanismo di aggiornamento dovrebbe poter verificare che il pacchetto:
- provenga da una fonte autorizzata;
- sia destinato all’hardware corretto;
- non sia stato modificato;
- sia accettabile secondo le policy del dispositivo.
In molti sistemi questo controllo coinvolge firme crittografiche, catene di fiducia o meccanismi equivalenti.
L’obiettivo non è soltanto impedire un errore dell’utente. È evitare che un attaccante possa trasformare il processo di update in un modo per installare codice non autorizzato.
La provenienza conta quindi quanto il numero di versione.
Per l’utente la regola pratica è semplice: usa canali ufficiali o procedure esplicitamente previste dal produttore.
Dispositivi IoT e hardware fuori supporto: il problema del lifecycle
Il problema diventa particolarmente evidente nell’Internet of Things.
Un dispositivo può restare fisicamente funzionante per molti anni, ma diventare progressivamente più difficile da difendere se il produttore interrompe gli aggiornamenti.
Questo crea una differenza importante tra:
hardware ancora funzionante
e
prodotto ancora supportato e ragionevolmente mantenibile
Per un sensore isolato il rischio può essere limitato.
Per una telecamera connessa, un router, un gateway o un componente esposto alla rete, l’assenza di patch può diventare una variabile molto più importante.
Prima di acquistare dispositivi destinati a restare operativi a lungo conviene quindi valutare anche:
- durata prevista del supporto;
- disponibilità degli aggiornamenti;
- modalità di distribuzione;
- autenticazione dei pacchetti;
- possibilità di recovery;
- comportamento del prodotto quando termina il supporto.
Il ciclo di vita del software integrato non è un dettaglio successivo all’acquisto. In molti dispositivi è parte della qualità complessiva del prodotto.
Conclusione
Il firmware non è una categoria misteriosa collocata fra hardware e software: è software strettamente legato al funzionamento di uno specifico hardware o di una piattaforma.
A volte è un piccolo programma che gira direttamente su un microcontrollore. In altri casi fa parte di un’architettura complessa con bootloader, driver, sistema operativo e applicazioni. È per questo che parlare genericamente del “firmware del dispositivo” può nascondere più livelli differenti.
La stessa prudenza vale per gli aggiornamenti.
Non serve memorizzare una procedura universale, perché non esiste. Serve invece seguire un metodo: identificare con precisione hardware e revisione, controllare la versione installata, leggere le note del produttore, utilizzare il canale ufficiale e conoscere le opzioni di recovery prima di modificare un componente così vicino all’hardware.
Con questa distinzione diventa anche più facile capire cosa stai realmente aggiornando quando una schermata parla di BIOS, UEFI, driver, sistema operativo o firmware — e soprattutto evitare di trattare questi termini come se indicassero la stessa cosa.