Come parte dei requisiti del kernel del modulo introdotti in Android 8.0, i kernel system-on-chip (SoC) devono supportare moduli kernel caricabili.
Opzioni di configurazione del kernel
Per supportare i moduli kernel caricabili, android-base.config in tutti i kernel comuni include la classe seguenti opzioni kernel-config (o l'equivalente della loro versione kernel):
CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y CONFIG_MODVERSIONS=y
Tutti i kernel del dispositivo devono abilitare queste opzioni. I moduli del kernel devono inoltre supportano lo scarico e il ricaricamento quando possibile.
Firma del modulo
La firma del modulo non è supportata per i moduli del fornitore GKI. Sui dispositivi necessari per
supportare l'avvio verificato, Android richiede che i moduli kernel siano nelle partizioni
con la verifica dm-verity abilitata. In questo modo non è più necessario
firmare i singoli utenti
i moduli per la loro autenticità.
Android 13 ha introdotto il concetto di moduli GKI. I moduli GKI utilizzano il tempo di build del kernel
di firma per distinguere tra GKI e altri moduli in fase di esecuzione.
I moduli non firmati possono essere caricati purché utilizzino solo i simboli presenti nella lista consentita
o forniti da altri moduli non firmati.
Per facilitare la firma dei moduli GKI durante la build GKI utilizzando la coppia di chiavi per il tempo di creazione del kernel,
La configurazione del kernel GKI ha abilitato CONFIG_MODULE_SIG_ALL=y
.
Per evitare di firmare moduli non GKI durante le build del kernel del dispositivo, devi aggiungere
# CONFIG_MODULE_SIG_ALL is not set
come parte della configurazione del kernel
di grandi dimensioni.
Posizioni dei file
Sebbene Android 7.x e versioni precedenti non richiedano l'uso di moduli kernel (e includono
supporto per insmod
e rmmod
), Android 8.x e
di usare i moduli kernel nell'ecosistema. Le seguenti
mostra il potenziale supporto periferico specifico della scheda richiesto in tre
Modalità di avvio di Android.
Modalità di avvio | Spazio di archiviazione | Display | Tastierino | Batteria | PMIC | Touchscreen | NFC, Wi-Fi, Bluetooth |
Sensori | Fotocamera |
---|---|---|---|---|---|---|---|---|---|
Ripristino | |||||||||
Caricabatterie | |||||||||
Android |
Oltre alla disponibilità nelle modalità di avvio di Android, i moduli kernel possono essere classificati in base a chi li possiede (il fornitore di SoC o l'ODM). Se i moduli kernel i requisiti per il posizionamento nel file system sono i seguenti che segue:
- Tutti i kernel devono avere il supporto integrato per l'avvio e il montaggio partizioni di Compute Engine.
- I moduli del kernel devono essere caricati da una partizione di sola lettura.
- Per i dispositivi per cui è necessario l'avvio verificato, i moduli kernel devono essere caricato da partizioni verificate.
- I moduli del kernel non devono trovarsi in
/system
. - I moduli GKI richiesti per il dispositivo devono essere caricati da
/system/lib/modules
, che è un link simbolico a/system_dlkm/lib/modules
. - Moduli del kernel del fornitore di SoC richiesti per le versioni complete
Le modalità di ricarica devono essere disponibili in
/vendor/lib/modules
. - Se esiste una partizione ODM, i moduli kernel dell'ODM che sono richiesti
per la modalità completa di Android o del caricabatterie deve essere disponibile in
/odm/lib/modules
. In caso contrario, questi moduli dovrebbero trovarsi in/vendor/lib/modules
. - Moduli del kernel del fornitore di SoC e ODM che sono richiesti per il ripristino
deve trovarsi nel
ramfs
di ripristino all'indirizzo/lib/modules
. - Moduli del kernel richiesti sia per la modalità Recovery sia per le versioni Android o
Le modalità del caricabatterie devono esistere sia nell'
rootfs
di ripristino che la partizione/vendor
o/odm
(come descritto sopra). - I moduli del kernel utilizzati in modalità di ripristino non devono dipendere dai moduli situati
solo in
/vendor
o/odm
, poiché queste partizioni non sono montato in Recovery mode. - I moduli kernel del fornitore SoC non devono dipendere dai moduli kernel ODM.
In Android 7.x e versioni precedenti, /vendor
e /odm
le partizioni non vengono montate in anticipo. In Android 8.x e versioni successive,
per rendere possibile il caricamento dei moduli da queste partizioni, sono state
per montare in anticipo le partizioni
dispositivi non A/B e A/B. Anche questo
assicura che le partizioni siano montate sia in modalità Android che in modalità caricabatterie.
Supporto del sistema di build Android
In BoardConfig.mk
, la build Android definisce
Variabile BOARD_VENDOR_KERNEL_MODULES
che fornisce un elenco completo
dei moduli kernel destinati all'immagine del fornitore. I moduli elencati in
questa variabile viene copiata nell'immagine del fornitore in /lib/modules/
,
e, dopo essere stato montato in Android, appaiono in
/vendor/lib/modules
(in conformità ai requisiti di cui sopra).
Configurazione di esempio dei moduli kernel del fornitore:
vendor_lkm_dir := device/$(vendor)/lkm-4.x BOARD_VENDOR_KERNEL_MODULES := \ $(vendor_lkm_dir)/vendor_module_a.ko \ $(vendor_lkm_dir)/vendor_module_b.ko \ $(vendor_lkm_dir)/vendor_module_c.ko
In questo esempio, un repository predefinito per i moduli kernel del fornitore è mappato la build Android nella posizione indicata sopra.
L'immagine di ripristino può contenere un sottoinsieme dei moduli del fornitore. Android
nella build definisce la variabile BOARD_RECOVERY_KERNEL_MODULES
questi moduli. Esempio:
vendor_lkm_dir := device/$(vendor)/lkm-4.x BOARD_RECOVERY_KERNEL_MODULES := \ $(vendor_lkm_dir)/vendor_module_a.ko \ $(vendor_lkm_dir)/vendor_module_b.ko
La build Android si occupa di eseguire depmod
per generare
modules.dep
file richiesti in /vendor/lib/modules
e /lib/modules
(recovery ramfs
).
Caricamento del modulo e controllo delle versioni
Carica tutti i moduli kernel in un passaggio da init.rc*
richiamando
modprobe -a
. In questo modo si evita l'overhead associato all'inizializzazione ripetuta
nell'ambiente di runtime C per il programma binario modprobe
. La
L'evento early-init
può essere modificato per richiamare modprobe
:
on early-init exec u:r:vendor_modprobe:s0 -- /vendor/bin/modprobe -a -d \ /vendor/lib/modules module_a module_b module_c ...
In genere, un modulo kernel deve essere compilato con il kernel che
usato (altrimenti il kernel si rifiuta di caricare il modulo).
CONFIG_MODVERSIONS
offre una soluzione alternativa rilevando i malfunzionamenti
nell'Application Bin Interface (ABI). Questa caratteristica calcola una
del controllo di ridondanza (CRC) per il prototipo di ciascun simbolo esportato nel
il kernel e archivia i valori come parte del kernel; per i simboli utilizzati
modulo kernel, i valori sono archiviati anche nel modulo kernel. Quando
modulo viene caricato, i valori dei simboli utilizzati dal modulo vengono confrontati
a quelli nel kernel. Se i valori corrispondono, il modulo viene caricato;
altrimenti il caricamento non riesce.
Per abilitare l'aggiornamento dell'immagine del kernel separatamente dall'immagine del fornitore,
abilita CONFIG_MODVERSIONS
. In questo modo è possibile apportare piccoli aggiornamenti
(come le correzioni di bug di LTS) mantenendo la compatibilità
con i moduli kernel esistenti
nell'immagine del fornitore. Tuttavia,
CONFIG_MODVERSIONS
non risolve autonomamente un'interruzione dell'ABI. Se
un prototipo di un simbolo esportato nelle modifiche del kernel, a causa
del codice sorgente o a causa della modifica della configurazione del kernel,
interrompe la compatibilità con i moduli kernel che utilizzano quel simbolo. In questi casi,
il modulo kernel deve essere ricompilato.
Ad esempio, la struttura task_struct
nel kernel (definita in
include/linux/sched.h
) contiene molti campi in modo condizionale
a seconda della configurazione del kernel. sched_info
è presente solo se CONFIG_SCHED_INFO
è abilitato (che
si verifica quando CONFIG_SCHEDSTATS
o
CONFIG_TASK_DELAY_ACCT
abilitati). Se queste configurazioni
opzioni cambiano stato, il layout della struttura task_struct
modifiche ed eventuali interfacce esportate dal kernel che usano
task_struct
è stato modificato (ad esempio,
set_cpus_allowed_ptr
a kernel/sched/core.c
).
Compatibilità con i moduli kernel compilati in precedenza che utilizzano questi
si interrompono, richiedendo che questi moduli vengano ricreati con il nuovo kernel
configurazione.
Per maggiori dettagli su CONFIG_MODVERSIONS
, consulta le
documentazione nella struttura del kernel
Documentation/kbuild/modules.rst
.