Gestione dei moduli kernel

Descrive come ispezionare i moduli kernel caricati, regolare i parametri e controllare quali moduli vengono caricati su Oracle Linux.

Utilizzare il comando lsmod per visualizzare i moduli caricati nel kernel in esecuzione. Utilizzare il comando modinfo per trovare informazioni su un modulo kernel. Utilizzare il comando modprobe per caricare un modulo nel kernel in esecuzione o per modificare i parametri del modulo kernel. È inoltre possibile creare file di configurazione in /etc/modprobe.d/ per controllare i parametri utilizzati durante il caricamento dei moduli kernel. È inoltre possibile configurare se i moduli vengono caricati durante il boot modificando la configurazione in /etc/modules-load.d/.

Lista di informazioni sui moduli caricati

Utilizzare il comando lsmod per elencare i moduli caricati nel kernel e utilizzare il comando modinfo per ottenere ulteriori informazioni su ciascun modulo. Per ulteriori informazioni, vedere le pagine del manuale lsmod(5) e modinfo(8).

Eseguire il comando lsmod per elencare i moduli caricati nel kernel.

lsmod

Module                  Size  Used by
udp_diag               16384  0
ib_core               311296  0
tcp_diag               16384  0
inet_diag              24576  2 tcp_diag,udp_diag
nfsv3                  49152  0
nfs_acl                16384  1 nfsv3
...
dm_mirror              24576  0
dm_region_hash         20480  1 dm_mirror
dm_log                 20480  2 dm_region_hash,dm_mirror
...

L'output mostra il nome del modulo, la quantità di memoria che utilizza, il numero di processi che utilizzano il modulo e i nomi di altri moduli da cui dipende. Il modulo dm_log, ad esempio, dipende dai moduli dm_region_hash e dm_mirror. L'esempio mostra inoltre che due processi utilizzano tutti e tre i moduli.

Per visualizzare informazioni dettagliate su un modulo, usare il comando modinfo.
```
modinfo ahci
```
```
filename:       /lib/modules/6.12.0-100.28.2.el10uek.x86_64/kernel/drivers/ata/ahci.ko.xz
version:        3.0
license:        GPL
description:    AHCI SATA low-level driver
author:         Jeff Garzik
srcversion:     1DC2CDA088C5DC03187A5E0
alias:          pci:v*d*sv*sd*bc01sc06i01*
...
depends:        libata,libahci
intree:         Y
name:           ahci
retpoline:      Y
vermagic:       6.12.0-100.28.2.el10uek.x86_64 SMP preempt mod_unload modversions 
sig_id:         PKCS#7
signer:         Oracle CA Server
sig_key:        7B:38:D7:DC:38:51:E7:C7:F1:61:C5:5D:8D:CC:6B:1C:90:82:4D:05
sig_hashalgo:   sha512
signature:      64:05:FC:CC:B1:D3:88:91:B6:C9:A2:39:A3:A9:BB:8C:95:11:36:20:
                62:9C:95:D9:8B:B8:F6:5F:CC:D2:93:4E:7D:59:E1:80:DB:70:FA:4C:
                9B:8D:75:E3:98:AB:9D:BD:94:93:A7:72:0B:28:3B:15:4E:96:0D:E3:
                9F:FE:24:1A:09:B5:31:27:F2:EE:45:61:C8:4A:D3:4B:82:07:23:66:
                A1:06:F4:DF:B9:FF:D2:78:08:1D:AA:EC:DE:3C:E4:17:BD:69:6A:A5:

                ...
                64:F0:4F:E2:4E:F3:47:A5:40:E8:F7:07:68:3F:58:25:32:BA:13:E9:
                00:46:7A:2F:30:73:B4:32:48:76:6B:1E
parm:           marvell_enable:Marvell SATA via AHCI (1 = enabled) (int)
parm:           mobile_lpm_policy:Default LPM policy for mobile chipsets (int)
...
```
L'output include le seguenti informazioni:

filename

Percorso assoluto del file oggetto kernel.

version

Numero di versione del modulo. Si noti che il numero di versione potrebbe non essere aggiornato per i moduli con patch e potrebbe essere mancante o rimosso nei kernel più recenti.

license

Informazioni sulla licenza per il modulo.

description

Breve descrizione del modulo.

author

Avere autore per il modulo.

srcversion

Hash del codice sorgente utilizzato per creare il modulo.

alias

Nomi alias interni per il modulo.

depends

Elenco separato da virgole di tutti i moduli da cui dipende il modulo.

retpoline

Flag che indica che il modulo è stato creato e include una mitigazione della vulnerabilità di sicurezza Spectre.

name

Il nome del modulo.

intree

Un flag che indica che il modulo è costruito dalla sorgente del kernel in-tree e non è contaminato.

vermagic

Versione del kernel utilizzata per compilare il modulo, che viene controllata rispetto al kernel corrente quando il modulo viene caricato.

sig_id

Metodo utilizzato per memorizzare le chiavi di firma che potrebbero essere state utilizzate per firmare un modulo per Secure Boot, in genere PKCS#7

signer

Nome della chiave di firma utilizzata per firmare un modulo per Secure Boot.

sig_key

Identificativo della chiave di firma per la chiave utilizzata per firmare il modulo.

sig_hashalgo

Algoritmo utilizzato per generare l'hash della firma per un modulo firmato.

signature

Dati della firma per un modulo firmato.

parm

Parametri e descrizioni del modulo.
Usare il comando modinfo -n per trovare il percorso del file del modulo sul file system.
I moduli vengono caricati nel kernel dai file oggetto del kernel (/lib/modules/kernel_version/kernel/*ko*). Per visualizzare il percorso assoluto di un file oggetto kernel, specificare l'opzione -n, ad esempio:
```
modinfo -n parport
```
```
/lib/modules/6.12.0-100.28.2.el10uek.x86_64/kernel/drivers/parport/parport.ko.xz
```

Caricamento e scaricamento dei moduli

I moduli vengono caricati e scaricati utilizzando il comando modprobe. Per ulteriori informazioni, vedere le pagine del manuale modprobe(8) e modules.dep(5).

Caricare un modulo kernel utilizzando il comando modprobe.

Il comando modprobe carica i moduli kernel, ad esempio:

sudo modprobe nfs
sudo lsmod | grep nfs

nfs                   266415  0 
lockd                  66530  1 nfs
fscache                41704  1 nfs
nfs_acl                 2477  1 nfs
auth_rpcgss            38976  1 nfs
sunrpc                204268  5 nfs,lockd,nfs_acl,auth_rpcgss

Includere l'opzione -v (verbose) per indicare se vengono caricati altri moduli per risolvere le dipendenze.

sudo modprobe -v nfs

insmod /lib/modules/6.12.0-100.28.2.el10uek.x86_64/kernel/net/sunrpc/auth_gss/auth_rpcgss.ko 
insmod /lib/modules/6.12.0-100.28.2.el10uek.x86_64/kernel/fs/nfs_common/nfs_acl.ko 
insmod /lib/modules/6.12.0-100.28.2.el10uek.x86_64/kernel/fs/fscache/fscache.ko 
...

Nota

Il comando modprobe non ricarica i moduli già caricati. È necessario scaricare un modulo prima di poterlo caricare di nuovo.

Scaricare un modulo utilizzando il comando modprobe -r.
Utilizzare l'opzione -r per scaricare i moduli kernel:
```
sudo modprobe -rv nfs
```
```
rmmod /lib/modules/6.12.0-100.28.2.el10uek.x86_64/kernel/fs/nfs/nfs.ko
rmmod /lib/modules/6.12.0-100.28.2.el10uek.x86_64/kernel/fs/lockd/lockd.ko
rmmod /lib/modules/6.12.0-100.28.2.el10uek.x86_64/kernel/fs/fscache/fscache.ko
...
```
I moduli vengono scaricati in ordine inverso in cui sono stati caricati per la prima volta. I moduli non vengono scaricati se un processo o un altro modulo caricato li richiede.

Modifica dei parametri del modulo Kernel

I moduli kernel, come i driver hardware, spesso dispongono di parametri personalizzati che possono essere impostati per modificare il comportamento del driver o del modulo. Sono disponibili diversi meccanismi per aggiornare i parametri del modulo.

Utilizzare sysfs per aggiornare immediatamente i parametri del modulo.
È possibile modificare i valori di alcuni parametri per i moduli caricati e i driver incorporati scrivendo il nuovo valore in un file in /sys/module/module_name/parameters, ad esempio:
```
echo 0 | sudo tee /sys/module/ahci/parameters/skip_host_reset
```
Vedere Informazioni sul file system virtuale /sys e riferimento alla directory sysfs.

Si noti che le modifiche non sono persistenti e non si applicano automaticamente dopo il riavvio.
Utilizzare il comando modprobe per modificare la configurazione in esecuzione di un modulo.
Per modificare il comportamento di un modulo, specificare i parametri per il modulo nel comando modprobe:
```
sudo modprobe module_name parameter=value ...
```
Separare le coppie di parametri e valori con spazi. I valori dell'array sono rappresentati da una lista separata da virgole, ad esempio:
```
sudo modprobe foo parm=bar arrayparm=1,2,3,4
```
Aggiornare la configurazione modprobe per apportare ulteriori modifiche alla configurazione del modulo permanente.
I file di configurazione (/etc/modprobe.d/*.conf) specificano le opzioni del modulo, creano alias per i moduli e sostituiscono il normale funzionamento di modprobe per i moduli con requisiti speciali. Anche il file /etc/modprobe.conf usato con le versioni precedenti di modprobe è valido, se esiste. Le voci nei file /etc/modprobe.conf e /etc/modprobe.d/*.conf utilizzano la stessa sintassi. Per ulteriori informazioni, vedere Modprobe Configuration Reference.

Specifica dei moduli da caricare al momento del boot

Il sistema carica automaticamente la maggior parte dei moduli in fase di boot. È inoltre possibile aggiungere moduli da caricare creando un file di configurazione per il modulo nella directory /etc/modules-load.d. Il nome del file deve avere l'estensione .conf.

Le modifiche apportate alla directory /etc/modules-load.d vengono mantenute durante il reboot.

Per forzare il caricamento di un modulo in fase di boot, creare un file di configurazione in /etc/modules-load.d per il modulo.
Ad esempio, per forzare il caricamento di bnxt_en.conf in fase di boot, eseguire il comando seguente:
```
echo bnxt_en | sudo tee /etc/modules-load.d/bnxt_en.conf
```
Verificare che il file esista e contenga il nome del modulo.
```
cat /etc/modules-load.d/bnxt_en.conf
```
Se il modulo non è già stato caricato, è possibile caricarlo manualmente utilizzando il comando modprobe oppure eseguire il reboot del sistema e caricarlo automaticamente utilizzando la configurazione fornita.

Impedire il caricamento dei moduli in fase di boot

È possibile impedire il caricamento dei moduli in fase di boot aggiungendo una regola di negazione in un file di configurazione nella directory /etc/modprobe.d e quindi ricreando il ramdisk iniziale utilizzato per caricare il kernel in fase di boot.

Avvertenza

La disabilitazione dei moduli può avere conseguenze involontarie e impedire il boot di un sistema o la piena funzionalità dopo il boot. Come best practice, creare un'immagine ramdisk di backup prima di apportare modifiche e assicurarsi che la configurazione sia corretta.

Creare un file di configurazione per impedire il caricamento del modulo.

Ad esempio:

sudo tee /etc/modprobe.d/bnxt_en-deny.conf <<'EOF'
#DENY bnxt_en
blacklist bnxt_en
install bnxt_en /bin/false
EOF

Ricreare l'immagine del ramdisk iniziale.
```
sudo dracut -f -v
```
Effettuare il reboot del sistema per rendere effettive le modifiche.
```
sudo reboot
```

Rimozione dei moduli di aggiornamento deboli

In alcuni casi, è possibile rimuovere i moduli di aggiornamento deboli al posto di un kernel più recente, ad esempio nel caso in cui un problema con un driver fornito sia stato risolto in un kernel più recente. In questo caso, potrebbe essere preferibile utilizzare il nuovo driver anziché il modulo esterno installato come parte di un aggiornamento del driver. Per ulteriori informazioni, vedere Informazioni sui moduli di aggiornamento deboli.

È possibile utilizzare due approcci diversi per rimuovere un modulo di aggiornamento debole.

Rimuovere manualmente il collegamento simbolico.
Poiché i moduli di aggiornamento deboli sono collegati simbolicamente per ogni versione del kernel nel sistema, è possibile rimuovere il collegamento simbolico per il modulo da ogni kernel in cui non si desidera che venga applicato. Ad esempio:
```
sudo rm -rf /lib/modules/6.12.0-100.28.2.el10uek.x86_64/weak-updates/kmod-kvdo
```
In questo esempio, il modulo di aggiornamento debole, kmod-kvdo, viene rimosso dal kernel, 6.12.0-100.28.2.el10uek.x86_64.
Utilizzare il comando weak-modules per rimuovere il modulo.
È possibile utilizzare il comando weak-modules per rimuovere un modulo di aggiornamento debole specificato per tutti i kernel compatibili oppure utilizzare il comando per rimuovere il modulo di aggiornamento debole per il kernel corrente. È anche possibile utilizzare il comando moduli deboli in modo simile per aggiungere moduli di aggiornamento deboli. Per ulteriori informazioni su questo comando, eseguire:
```
weak-modules -h
```
È anche possibile utilizzare il comando moduli deboli con l'opzione dry-run per eseguire il test dei risultati senza apportare modifiche effettive, ad esempio:
```
weak-modules --remove-kernel --dry-run --verbose
```