linux-4.1.15_CVE-2023-26607

INSTALLAZIONE del sorgente del kernel:

• Se installi i sorgenti completi, metti il tarball del kernel in una directory dove hai i permessi (es. la tua home directory) e decomprimilo:

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

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

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

• Puoi anche fare l'upgrade tra le release 4.x applicando le patch. Le patch sono distribuite in formato xz. Per installare tramite patch, scarica tutti i file di patch più recenti, entra nella directory di livello superiore del sorgente del kernel (linux-4.X) ed esegui:

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

  Sostituisci "x" per tutte le versioni successive alla versione "X" del tuo albero sorgente corrente, in ordine, e dovresti essere a posto. Potresti voler rimuovere i file di backup (some-file-name~ o some-file-name.orig) e assicurarti che non ci siano patch fallite (some-file-name# o some-file-name.rej). Se ce ne sono, o tu o io 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 4.x di base. Ad esempio, se il tuo kernel di base è 4.0 e vuoi applicare la patch 4.0.3, non devi prima applicare le patch 4.0.1 e 4.0.2. Allo stesso modo, se stai eseguendo la versione 4.0.2 del kernel e vuoi passare alla 4.0.3, devi prima annullare la patch 4.0.2 (cioè, patch -R) prima di applicare la patch 4.0.3. Puoi leggere ulteriori informazioni in Documentation/applying-patches.txt

  In alternativa, lo script patch-kernel può essere usato per automatizzare questo processo. Determina la versione corrente del kernel e applica tutte le patch trovate.

  linux/scripts/patch-kernel linux

  Il primo argomento nel comando sopra è la posizione del sorgente del kernel. Le patch vengono applicate dalla directory corrente, ma è possibile specificare una directory alternativa come secondo argomento.

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

  cd linux make mrproper

  Ora dovresti avere i sorgenti installati correttamente.

REQUISITI SOFTWARE

La compilazione e l'esecuzione dei kernel 4.x richiedono versioni aggiornate di vari pacchetti software. Consulta Documentation/Changes per i numeri di versione minimi richiesti e per sapere come ottenere gli aggiornamenti di questi pacchetti. Fai attenzione: usare 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 build o il funzionamento.

DIRECTORY di build per il kernel:

Quando si compila il kernel, tutti i file di output verranno per impostazione predefinita memorizzati insieme al codice sorgente del kernel. Usando l'opzione "make O=output/dir" puoi specificare un luogo alternativo per i file di output (incluso .config). Esempio:

Per configurare e compilare il kernel, usa:

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

CONFIGURAZIONE del kernel:

Non saltare questo passaggio anche se stai solo facendo l'upgrade di una versione minore. In ogni release vengono aggiunte nuove opzioni di configurazione e compariranno problemi strani se i file di configurazione non sono impostati come previsto. Se vuoi portare la tua configurazione esistente a una nuova versione con il minimo lavoro, usa "make oldconfig", che ti chiederà solo le risposte alle nuove domande.

• I comandi di configurazione alternativi sono:

  "make config" Interfaccia di solo testo.

  "make menuconfig" Menu colorati basati su testo, radiolist e dialoghi.

  "make nconfig" Menu colorati basati su testo migliorati.

  "make xconfig" Strumento di configurazione basato su X windows (Qt).

  "make gconfig" Strumento di configurazione basato su X windows (Gtk).

  "make oldconfig" Imposta come default tutte le domande in base al contenuto del tuo file ./.config esistente e chiede informazioni sui nuovi simboli di configurazione.

  "make silentoldconfig" Come sopra, ma evita di riempire lo schermo con domande a cui è già stato risposto. Aggiorna inoltre le dipendenze.

  "make olddefconfig" Come sopra, ma imposta i nuovi simboli ai loro valori predefiniti senza chiedere conferma.

  "make defconfig" Crea un file ./.config usando i valori predefiniti dei simboli da arch/$ARCH/defconfig o arch/$ARCH/configs/${PLATFORM}_defconfig, a seconda dell'architettura.

  "make ${PLATFORM}_defconfig" Crea un file ./.config usando i valori predefiniti dei simboli da arch/$ARCH/configs/${PLATFORM}_defconfig. Usa "make help" per ottenere un elenco di tutte le piattaforme disponibili della tua architettura.

  "make allyesconfig" Crea un file ./.config impostando i valori dei simboli a 'y' il più possibile.

  "make allmodconfig" Crea un file ./.config impostando i valori dei simboli a 'm' il più possibile.

  "make allnoconfig" Crea un file ./.config impostando i valori dei simboli a 'n' il più possibile.

  "make randconfig" Crea un file ./.config impostando i valori dei simboli a valori casuali.

  "make localmodconfig" Crea una configurazione basata sulla config corrente e sui moduli caricati (lsmod). Disabilita qualsiasi opzione di modulo che non è necessaria per i moduli caricati.

  root@kitploit:~

                      Per creare un localmodconfig per un'altra
                      macchina, salva l'lsmod di quella macchina
                      in un file e passalo come parametro LSMOD.
  
              target$ lsmod > /tmp/mylsmod
              target$ scp /tmp/mylsmod host:/tmp
  
              host$ make LSMOD=/tmp/mylsmod localmodconfig
  
                      Quanto sopra funziona anche durante la cross
                      compilation.
  

  "make localyesconfig" Simile a localmodconfig, tranne per il fatto che converte tutte le opzioni dei moduli in opzioni integrate (=y).

  Puoi trovare maggiori 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 può in alcune circostanze portare a problemi: il probing di una scheda controller inesistente può confondere gli altri controller.

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

  • Un kernel con la math-emulation compilata userà comunque il coprocessore, se presente: in quel caso la math emulation non verrà mai usata. Il kernel sarà leggermente più grande, ma funzionerà su macchine diverse a prescindere dalla presenza o meno di un coprocessore matematico.

  • I dettagli di configurazione di "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 per trovare problemi del kernel (kmalloc()). Quindi dovresti probabilmente rispondere 'n' alle domande relative alle funzionalità di "development", "experimental" o "debugging".

COMPILAZIONE del kernel:

• Assicurati di avere almeno gcc 3.2 disponibile. Per maggiori informazioni, consulta Documentation/Changes.

  Nota che puoi comunque eseguire programmi utente a.out con questo kernel.

• Esegui un "make" per creare un'immagine del kernel compressa. È anche possibile fare "make install" se hai lilo installato adatto ai makefile del kernel, ma potresti voler controllare prima la tua configurazione lilo specifica.

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

• Se hai configurato alcune parti del kernel come modules, dovrai anche fare "make modules_install".

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

  Normalmente, il sistema di build del kernel opera in modalità piuttosto silenziosa (ma non del tutto). Tuttavia, a volte tu o altri sviluppatori del kernel avete bisogno di vedere i comandi di compilazione, collegamento o altri comandi esattamente come vengono eseguiti. Per questo, usa la modalità di build "verbose". Questo si fa inserendo "V=1" nel comando "make". Es.:

  make V=1 all

  Per avere anche il motivo della ricompilazione di ogni target dal sistema di build, usa "V=2". Il default è "V=0".

• Tieni a portata di mano un kernel di backup nel caso qualcosa vada storto. Questo è particolarmente vero per le release di sviluppo, poiché ogni nuova release contiene nuovo codice che non è stato sottoposto a debug. Assicurati di conservare anche un backup dei moduli corrispondenti a quel kernel. Se stai installando un nuovo kernel con lo stesso numero di versione del kernel funzionante, fai un backup della tua directory dei moduli prima di fare un "make modules_install".

  In alternativa, prima di compilare, usa 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 tuo nuovo kernel, dovrai copiare l'immagine del kernel (es. .../linux/arch/i386/boot/bzImage dopo la compilazione) nel posto dove si trova il tuo kernel avviabile normale.

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

  Se avvii Linux dal disco rigido, è probabile che tu usi LILO, che usa l'immagine del kernel specificata nel file /etc/lilo.conf. Il file immagine del kernel è di solito /vmlinuz, /boot/vmlinuz, /bzImage o /boot/bzImage. Per usare il nuovo kernel, salva una copia della vecchia immagine e copia la nuova immagine sopra quella vecchia. Poi, DEVI RIESEGUIRE LILO per aggiornare la mappa di caricamento!! Se non lo fai, non sarai in grado di avviare la nuova immagine del kernel.

  Reinstallare LILO di solito consiste nell'eseguire /sbin/lilo. Potresti voler modificare /etc/lilo.conf per specificare una voce per la tua vecchia immagine del kernel (ad esempio, /vmlinux.old) nel caso in cui quella nuova non funzioni. Vedi i documenti di LILO per maggiori informazioni.

  Dopo aver reinstallato LILO, dovresti essere a posto. Spegni il sistema, riavvia e divertiti!

  Se mai avessi bisogno di cambiare il dispositivo root predefinito, la modalità video, la dimensione del ramdisk, ecc. nell'immagine del kernel, usa 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.

• Riavvia con il nuovo kernel e divertiti.

SE QUALCOSA VA STORTO:

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

• In tutte le segnalazioni di bug, per favore indica di quale kernel stai parlando, come duplicare il problema e qual è la tua configurazione (usa il buon senso). Se il problema è nuovo, dimmelo, e se il problema è vecchio, cerca di dirmi quando l'hai 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 di debug del kernel simili sullo schermo o nel log di sistema, per favore duplicalo esattamente. Il dump può sembrarti incomprensibile, ma contiene informazioni che possono aiutare a fare il debug del problema. Anche il testo sopra il dump è importante: dice qualcosa sul motivo per cui il kernel ha scaricato il codice (nell'esempio precedente, è dovuto a un puntatore del kernel errato). Ulteriori informazioni su come dare un senso al dump si trovano in Documentation/oops-tracing.txt

• Se hai compilato il kernel con CONFIG_KALLSYMS puoi inviare il dump così com'è, altrimenti dovrai 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, puoi fare la ricerca del dump a mano:

• Nel fare il debug di dump come quello sopra, aiuta enormemente se puoi cercare cosa significa il valore EIP. Il valore esadecimale in sé non aiuta molto me o chiunque altro: dipenderà dalla tua configurazione particolare del kernel. Quello che dovresti fare è prendere il valore esadecimale dalla riga EIP (ignora il "0010:") e cercarlo nella namelist del kernel per vedere quale funzione del kernel contiene l'indirizzo incriminato.

  Per trovare il nome della funzione del kernel, dovrai trovare il binario di sistema associato al kernel che ha mostrato il sintomo. Questo è il file 'linux/vmlinux'. Per estrarre la namelist e confrontarla con l'EIP del crash del kernel, fai:

  nm vmlinux | sort | less

  Questo ti darà un elenco di indirizzi del kernel ordinati in ordine crescente, dal quale è semplice trovare la funzione che contiene l'indirizzo incriminato. Nota che l'indirizzo dato dai messaggi di debug del kernel non corrisponderà necessariamente esattamente agli indirizzi delle funzioni (in effetti, è molto improbabile), quindi non puoi semplicemente fare un 'grep' dell'elenco: l'elenco, tuttavia, ti darà il punto di partenza di ogni funzione del kernel, quindi cercando la funzione che ha un indirizzo di partenza inferiore a quello che stai cercando ma che è seguita da una funzione con un indirizzo più alto, troverai quella che vuoi. In effetti, potrebbe essere una buona idea includere un po' di "contesto" nella tua segnalazione di problema, dando alcune righe intorno a quella interessante.

  Se per qualche motivo non puoi fare quanto sopra (hai un'immagine del kernel precompilata o simile), dirmi il più possibile sulla tua configurazione aiuterà. Leggi il documento REPORTING-BUGS per i dettagli.

• In alternativa, puoi usare gdb su un kernel in esecuzione. (sola lettura; cioè non puoi cambiare valori o impostare punti di interruzione.) Per fare questo, prima compila il kernel con -g; modifica arch/i386/Makefile in modo appropriato, poi fai un "make clean". Dovrai anche abilitare CONFIG_PROC_FS (tramite "make config").

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

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