linux-4.1.15_CVE-2022-3564

INSTALLAZIONE dei sorgenti del kernel:

• Se si installano i sorgenti completi, mettere il tarball del kernel in una directory in cui si hanno i permessi (ad es. la propria home directory) e decomprimerlo:

  xz -cd linux-4.X.tar.xz | tar xvf -

  Sostituire "X" con il numero di versione dell'ultimo kernel.

  NON usare l'area /usr/src/linux! Quest'area contiene un insieme (di solito incompleto) di header del kernel usati dai file header delle librerie. Devono corrispondere alla libreria, e non devono essere alterati da qualunque kernel del giorno capiti.

• Si può anche effettuare un aggiornamento tra le release 4.x applicando patch. Le patch sono distribuite in formato xz. Per installare tramite patch, procurarsi tutti i file di patch più recenti, entrare nella directory di livello superiore dei sorgenti del kernel (linux-4.X) ed eseguire:

  xz -cd ../patch-4.x.xz | patch -p1

  Sostituire "x" per tutte le versioni successive alla versione "X" del proprio albero dei sorgenti attuale, in_ordine, e non dovrebbero esserci problemi. Potrebbe essere opportuno rimuovere i file di backup (some-file-name~ o some-file-name.orig) e assicurarsi che non ci siano patch fallite (some-file-name# o some-file-name.rej). Se ce ne sono, o io o voi abbiamo commesso un errore.

  A differenza delle patch per i kernel 4.x, le patch per i kernel 4.x.y (noti anche come kernel -stable) non sono incrementali ma si applicano direttamente al kernel di base 4.x. Ad esempio, se il kernel di base è 4.0 e si vuole applicare la patch 4.0.3, non si devono prima applicare le patch 4.0.1 e 4.0.2. Analogamente, se si sta eseguendo la versione 4.0.2 del kernel e si vuole passare alla 4.0.3, si deve prima invertire la patch 4.0.2 (cioè patch -R) prima di applicare la patch 4.0.3. Si può leggere più informazioni a riguardo in Documentation/applying-patches.txt

  In alternativa, si può usare lo script patch-kernel per automatizzare questo processo. Esso determina la versione corrente del kernel e applica tutte le patch trovate.

  linux/scripts/patch-kernel linux

  Il primo argomento del comando sopra è la posizione dei sorgenti del kernel. Le patch vengono applicate dalla directory corrente, ma si può specificare una directory alternativa come secondo argomento.

• Assicurarsi di non avere file .o obsoleti e dipendenze in giro:

  cd linux make mrproper

  Ora i sorgenti dovrebbero essere installati correttamente.

REQUISITI SOFTWARE

La compilazione e l'esecuzione dei kernel 4.x richiede versioni aggiornate di vari pacchetti software. Consultare Documentation/Changes per i numeri di versione minimi richiesti e per come ottenere gli aggiornamenti di questi pacchetti. Attenzione: l'uso di versioni eccessivamente vecchie di questi pacchetti può causare errori indiretti molto difficili da rintracciare, quindi non dare per scontato di poter semplicemente aggiornare i pacchetti quando sorgono problemi evidenti durante la compilazione o l'esecuzione.

Directory di BUILD del kernel:

Quando si compila il kernel, tutti i file di output verranno per impostazione predefinita salvati insieme al codice sorgente del kernel. Usando l'opzione "make O=output/dir" si può specificare una posizione alternativa per i file di output (incluso .config). Esempio:

Per configurare e compilare il kernel, usare:

Nota: se si usa l'opzione 'O=output/dir', essa deve essere usata per tutte le invocazioni di make.

CONFIGURAZIONE del kernel:

Non saltare questo passaggio anche se si sta solo aggiornando una versione minore. In ogni release vengono aggiunte nuove opzioni di configurazione e compariranno strani problemi se i file di configurazione non sono impostati come previsto. Se si vuole trasportare la configurazione esistente a una nuova versione con uno sforzo minimo, usare "make oldconfig", che chiederà solo le risposte alle nuove domande.

• I comandi di configurazione alternativi sono:

  "make config" Plain text interface.

  "make menuconfig" Text based color menus, radiolists & dialogs.

  "make nconfig" Enhanced text based color menus.

  "make xconfig" X windows (Qt) based configuration tool.

  "make gconfig" X windows (Gtk) based configuration tool.

  "make oldconfig" Default all questions based on the contents of your existing ./.config file and asking about new config symbols.

  "make silentoldconfig" Like above, but avoids cluttering the screen with questions already answered. Additionally updates the dependencies.

  "make olddefconfig" Like above, but sets new symbols to their default values without prompting.

  "make defconfig" Create a ./.config file by using the default symbol values from either arch/$ARCH/defconfig or arch/$ARCH/configs/${PLATFORM}_defconfig, depending on the architecture.

  "make ${PLATFORM}_defconfig" Create a ./.config file by using the default symbol values from arch/$ARCH/configs/${PLATFORM}_defconfig. Use "make help" to get a list of all available platforms of your architecture.

  "make allyesconfig" Create a ./.config file by setting symbol values to 'y' as much as possible.

  "make allmodconfig" Create a ./.config file by setting symbol values to 'm' as much as possible.

  "make allnoconfig" Create a ./.config file by setting symbol values to 'n' as much as possible.

  "make randconfig" Create a ./.config file by setting symbol values to random values.

  "make localmodconfig" Create a config based on current config and loaded modules (lsmod). Disables any module option that is not needed for the loaded modules.

  root@kitploit:~

                      To create a localmodconfig for another machine,
                      store the lsmod of that machine into a file
                      and pass it in as a LSMOD parameter.
  
              target$ lsmod > /tmp/mylsmod
              target$ scp /tmp/mylsmod host:/tmp
  
              host$ make LSMOD=/tmp/mylsmod localmodconfig
  
                      The above also works when cross compiling.
  

  "make localyesconfig" Similar to localmodconfig, except it will convert all module options to built in (=y) options.

  Si possono trovare ulteriori informazioni sull'uso degli strumenti di configurazione del kernel Linux in Documentation/kbuild/kconfig.txt.

• NOTE su "make config":

  • Avere driver non necessari renderà il kernel più grande e in alcune circostanze può portare a problemi: il probing di una scheda controller inesistente può confondere gli altri controller

  • Compilare il kernel con "Processor type" impostato su un valore superiore a 386 produrrà un kernel che NON funziona su un 386. Il kernel lo rileverà all'avvio e abbandonerà.

  • Un kernel con l'emulazione matematica compilata userà comunque il coprocessore se presente: in quel caso l'emulazione matematica non verrà mai usata. Il kernel sarà leggermente più grande, ma funzionerà su macchine diverse a prescindere dal fatto che abbiano o meno un coprocessore matematico.

  • I dettagli di configurazione "kernel hacking" di solito producono un kernel più grande o più lento (o entrambi), e possono persino rendere il kernel meno stabile configurando alcune routine per cercare attivamente di rompere il codice difettoso al fine di individuare problemi del kernel (kmalloc()). Pertanto, probabilmente si dovrebbe rispondere 'n' alle domande relative alle funzionalità "development", "experimental" o "debugging".

COMPILAZIONE del kernel:

• Assicurarsi di avere almeno gcc 3.2 disponibile. Per maggiori informazioni, fare riferimento a Documentation/Changes.

  Si noti che con questo kernel si possono ancora eseguire programmi utente a.out.

• Eseguire "make" per creare un'immagine del kernel compressa. È anche possibile eseguire "make install" se si ha lilo installato in modo adatto ai makefile del kernel, ma si potrebbe voler controllare prima la propria configurazione di lilo.

  Per eseguire l'installazione vera e propria, bisogna essere root, ma nessuna delle normali operazioni di build dovrebbe richiederlo. Non nominare il nome di root invano.

• Se si è configurata una qualsiasi delle parti del kernel come `modules', si dovrà anche eseguire "make modules_install".

• Output di compilazione/build del kernel dettagliato (verbose):

  Normalmente, il sistema di build del kernel opera in una modalità abbastanza silenziosa (ma non del tutto). Tuttavia, a volte voi o altri sviluppatori del kernel avete bisogno di vedere i comandi di compilazione, collegamento o altri esattamente come vengono eseguiti. A questo scopo, usare la modalità di build "verbose". Ciò si ottiene inserendo "V=1" nel comando "make". Ad es.:

  make V=1 all

  Per avere anche il motivo della ricostruzione di ciascun target dal sistema di build, usare "V=2". Il valore predefinito è "V=0".

• Tenere a portata di mano un kernel di backup nel caso qualcosa vada storto. Questo vale soprattutto per le release di sviluppo, poiché ogni nuova release contiene nuovo codice che non è stato ancora sottoposto a debug. Assicurarsi di conservare anche un backup dei moduli corrispondenti a quel kernel. Se si installa un nuovo kernel con lo stesso numero di versione del kernel funzionante, fare un backup della directory dei moduli prima di eseguire "make modules_install".

  In alternativa, prima di compilare, usare l'opzione di configurazione del kernel "LOCALVERSION" per aggiungere un suffisso univoco alla versione regolare del kernel. LOCALVERSION può essere impostata nel menu "General Setup".

• Per avviare il nuovo kernel, sarà necessario copiare l'immagine del kernel (ad es. .../linux/arch/i386/boot/bzImage dopo la compilazione) nel punto in cui si trova il kernel avviabile abituale.

• L'avvio di un kernel direttamente da floppy senza l'assistenza di un bootloader come LILO non è più supportato.

  Se si avvia Linux dal disco rigido, è probabile che si usi LILO, che utilizza l'immagine del kernel specificata nel file /etc/lilo.conf. Il file dell'immagine del kernel è di solito /vmlinuz, /boot/vmlinuz, /bzImage o /boot/bzImage. Per usare il nuovo kernel, salvare una copia della vecchia immagine e copiare la nuova immagine sopra quella vecchia. Quindi, si DEVE RIESEGUIRE LILO per aggiornare la mappa di caricamento!! Se non lo si fa, non si sarà in grado di avviare la nuova immagine del kernel.

  Reinstallare LILO di solito è solo una questione di eseguire /sbin/lilo. Si potrebbe voler modificare /etc/lilo.conf per specificare una voce per la vecchia immagine del kernel (ad esempio /vmlinux.old) nel caso quella nuova non funzioni. Vedere la documentazione di LILO per maggiori informazioni.

  Dopo aver reinstallato LILO, si dovrebbe essere a posto. Spegnere il sistema, riavviare e godersi il risultato!

  Se mai si dovesse cambiare il dispositivo root predefinito, la modalità video, la dimensione del ramdisk, ecc. nell'immagine del kernel, usare il programma 'rdev' (o in alternativa le opzioni di avvio di LILO quando appropriato). Non c'è bisogno di ricompilare il kernel per cambiare questi parametri.

• Riavviare con il nuovo kernel e godersi il risultato.

SE QUALCOSA VA STORTO:

• Se si hanno problemi che sembrano dovuti a bug del kernel, controllare il file MAINTAINERS per vedere se c'è una persona specifica associata alla parte del kernel con cui si hanno problemi. Se non c'è nessuno elencato lì, la seconda cosa migliore è inviarli a me ([email protected]) e possibilmente a qualsiasi altra mailing-list pertinente o al newsgroup.

• In tutte le segnalazioni di bug, per favore indicate di quale kernel state parlando, come riprodurre il problema e qual è la vostra configurazione (usate il buon senso). Se il problema è nuovo, ditemelo; se il problema è vecchio, cercate di dirmi quando lo avete notato per la prima volta.

• Se il bug produce un messaggio come

  unable to handle kernel paging request at address C0000010 Oops: 0002 EIP: 0010:XXXXXXXX eax: xxxxxxxx ebx: xxxxxxxx ecx: xxxxxxxx edx: xxxxxxxx esi: xxxxxxxx edi: xxxxxxxx ebp: xxxxxxxx ds: xxxx es: xxxx fs: xxxx gs: xxxx Pid: xx, process nr: xx xx xx xx xx xx xx xx xx xx xx

  o informazioni simili di debug del kernel sullo schermo o nel log di sistema, riprodurlo esattamente. Il dump può sembrarvi incomprensibile, ma contiene informazioni che possono aiutare a fare debug del problema. Anche il testo sopra il dump è importante: dice qualcosa sul motivo per cui il kernel ha scaricato il codice (nell'esempio sopra, è dovuto a un puntatore del kernel errato). Ulteriori informazioni su come interpretare il dump sono in Documentation/oops-tracing.txt

• Se si è compilato il kernel con CONFIG_KALLSYMS si può inviare il dump così com'è, altrimenti si dovrà usare il programma "ksymoops" per dare un senso al dump (ma compilare con CONFIG_KALLSYMS è di solito preferibile). Questa utility può essere scaricata da ftp://ftp..kernel.org/pub/linux/utils/kernel/ksymoops/ . In alternativa, si può effettuare la ricerca nel dump a mano:

• Nei dump di debug come quello sopra, aiuta enormemente poter cercare cosa significa il valore EIP. Il valore esadecimale in sé non aiuta molto me né nessun altro: dipende dalla vostra particolare configurazione del kernel. Quello che si dovrebbe fare è prendere il valore esadecimale dalla riga EIP (ignorando "0010:") e cercarlo nella namelist del kernel per vedere quale funzione del kernel contiene l'indirizzo incriminato.

  Per scoprire il nome della funzione del kernel, si dovrà trovare il binario di sistema associato al kernel che ha manifestato il sintomo. Questo è il file 'linux/vmlinux'. Per estrarre la namelist e confrontarla con l'EIP del crash del kernel, eseguire:

  nm vmlinux | sort | less

  Questo fornirà un elenco di indirizzi del kernel ordinati in ordine crescente, dal quale è semplice trovare la funzione che contiene l'indirizzo incriminato. Notare che l'indirizzo fornito dai messaggi di debug del kernel non corrisponderà necessariamente esattamente agli indirizzi delle funzioni (in effetti, è molto improbabile), quindi non si può semplicemente fare 'grep' sull'elenco: l'elenco fornirà comunque il punto di partenza di ogni funzione del kernel, quindi cercando la funzione che ha un indirizzo di partenza inferiore a quello cercato ma è seguita da una funzione con un indirizzo più alto si troverà quella desiderata. In effetti, potrebbe essere una buona idea includere un po' di "contesto" nella segnalazione del problema, fornendo alcune righe attorno a quella interessante.

  Se per qualche motivo non si può fare quanto sopra (si ha un'immagine del kernel precompilata o simile), dirmi il più possibile sulla propria configurazione sarà di aiuto. Leggere il documento REPORTING-BUGS per i dettagli.

• In alternativa, si può usare gdb su un kernel in esecuzione. (in sola lettura; cioè non si possono cambiare valori o impostare punti di interruzione.) Per fare ciò, compilare prima il kernel con -g; modificare arch/i386/Makefile in modo appropriato, quindi eseguire "make clean". Sarà inoltre necessario abilitare CONFIG_PROC_FS (tramite "make config").

  Dopo aver riavviato con il nuovo kernel, eseguire "gdb vmlinux /proc/kcore". Ora si possono usare tutti i soliti comandi di gdb. Il comando per cercare il punto in cui il sistema è andato in crash è "l *0xXXXXXXXX". (Sostituire le XXX con il valore EIP.)

  L'uso di gdb su un kernel non in esecuzione attualmente fallisce perché gdb (erroneamente) ignora l'offset iniziale per il quale il kernel è compilato.