linux-4.1.15_CVE-2017-1000371

INSTALLAZIONE del sorgente 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 scompattarlo:

  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 utilizzati dai file header delle librerie. Dovrebbero corrispondere alla libreria e non essere rovinati da qualunque kernel del giorno capiti.

• Si può anche aggiornare tra le versioni 4.x tramite patch. Le patch sono distribuite in formato xz. Per installare tramite patch, ottenere tutti i file di patch più recenti, entrare nella directory principale dei sorgenti del kernel (linux-4.X) ed eseguire:

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

  Sostituire "x" con tutte le versioni maggiori della versione "X" del proprio albero dei sorgenti, in ordine, e si dovrebbe essere a posto. Si potrebbero voler 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 (detti anche kernel -stable) non sono incrementali ma si applicano direttamente al kernel 4.x di base. Ad esempio, se il kernel di base è 4.0 e si vuole applicare la patch 4.0.3, non bisogna prima applicare le patch 4.0.1 e 4.0.2. Allo stesso modo, se si sta eseguendo la versione 4.0.2 del kernel e si vuole passare alla 4.0.3, bisogna prima annullare la patch 4.0.2 (cioè patch -R) prima di applicare la patch 4.0.3. Ulteriori informazioni sono disponibili 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.

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

  cd linux make mrproper

  Ora si dovrebbero avere i sorgenti correttamente installati.

REQUISITI SOFTWARE

Compilare ed eseguire i kernel 4.x richiede versioni aggiornate di vari pacchetti software. Consultare Documentation/Changes per i numeri di versione minimi richiesti e come ottenere aggiornamenti per 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 si presentano problemi evidenti durante la compilazione o l'esecuzione.

DIRECTORY DI BUILD per il kernel:

Quando si compila il kernel, tutti i file di output saranno per impostazione predefinita archiviati insieme al codice sorgente del kernel. Usando l'opzione "make O=output/dir" è possibile specificare un luogo alternativo 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. Nuove opzioni di configurazione vengono aggiunte in ogni rilascio e si presenteranno problemi imprevisti se i file di configurazione non sono impostati come previsto. Se si vuole portare la propria configurazione esistente a una nuova versione con il minimo sforzo, usare "make oldconfig", che chiederà solo le risposte alle nuove domande.

• I comandi di configurazione alternativi sono:

  "make config" Interfaccia di testo semplice.

  "make menuconfig" Menu a colori basati su testo, elenchi radio e finestre di dialogo.

  "make nconfig" Menu a colori 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" Risponde a tutte le domande basate sul contenuto del file ./.config esistente e chiede informazioni sui nuovi simboli di configurazione.

  "make silentoldconfig" Come sopra, ma evita di ingombrare lo schermo con domande già risposte. Inoltre aggiorna le dipendenze.

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

  "make defconfig" Crea un file ./.config utilizzando 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 utilizzando i valori predefiniti dei simboli da arch/$ARCH/configs/${PLATFORM}_defconfig. Usare "make help" per ottenere un elenco di tutte le piattaforme disponibili per la propria architettura.

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

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

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

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

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

  root@kitploit:~

                      Per creare un localmodconfig per un'altra macchina, salvare l'lsmod di quella macchina in un file e passarlo 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-compilazione.
  

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

  Ulteriori informazioni sull'uso degli strumenti di configurazione del kernel Linux sono disponibili 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 rilevamento di una scheda controller inesistente può confondere gli altri controller

  • Compilare il kernel con "Tipo di processore" impostato a un valore superiore a 386 produrrà un kernel che NON funziona su un 386. Il kernel lo rileverà all'avvio e si arrenderà.

  • Un kernel con emulazione matematica compilata userà comunque il coprocessore se presente: in tal caso l'emulazione matematica non verrà mai utilizzata. Il kernel sarà leggermente più grande, ma funzionerà su macchine diverse indipendentemente dalla presenza o meno di un coprocessore matematico.

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

COMPILAZIONE del kernel:

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

  Nota: è ancora possibile eseguire programmi utente a.out con questo kernel.

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

  Per eseguire l'installazione effettiva, bisogna essere root, ma nessuna delle normali operazioni di build dovrebbe richiederlo. Non invocare il nome di root invano.

• Se si sono configurate alcune parti del kernel come `modules', si dovrà anche eseguire "make modules_install".

• Output verbose della compilazione/build del kernel:

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

  make V=1 all

  Per fare in modo che il sistema di build indichi anche la ragione della ricostruzione di ogni target, usare "V=2". Il valore predefinito è "V=0".

• Tenere a portata di mano un kernel di backup nel caso qualcosa vada storto. Questo è particolarmente vero per i rilasci di sviluppo, poiché ogni nuovo rilascio contiene codice nuovo che non è stato ancora sottoposto a debug. Assicurarsi di conservare anche un backup dei moduli corrispondenti a quel kernel. Se si sta installando 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 luogo in cui si trova il kernel avviabile regolare.

• L'avvio di un kernel direttamente da un 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 come specificato nel file /etc/lilo.conf. Il file immagine del kernel è di solito /vmlinuz, /boot/vmlinuz, /bzImage o /boot/bzImage. Per usare il nuovo kernel, salvare una copia dell'immagine vecchia e copiare la nuova immagine sopra quella vecchia. Quindi, è NECESSARIO RIESEGUIRE LILO per aggiornare la mappa di caricamento!! Altrimenti, non si sarà in grado di avviare la nuova immagine del kernel.

  Reinstallare LILO di solito significa eseguire /sbin/lilo. Si potrebbe voler modificare /etc/lilo.conf per specificare una voce per la vecchia immagine del kernel (ad es. /vmlinux.old) nel caso quella nuova non funzioni. Consultare 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 è necessario 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 essere dovuti a bug del kernel, controllare il file MAINTAINERS per vedere se c'è una persona particolare associata alla parte del kernel con cui si hanno problemi. Se non c'è nessuno elencato lì, la seconda migliore cosa è 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 indicate di quale kernel state parlando, come riprodurre il problema e qual è la vostra configurazione (usate il buon senso). Se il problema è nuovo, ditemelo, e se è 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 di debug simili del kernel sullo schermo o nel log di sistema, si prega di riprodurle esattamente. Il dump può sembrare incomprensibile, ma contiene informazioni che possono aiutare a risolvere il 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 kernel errato). Ulteriori informazioni su come interpretare il dump sono in Documentation/oops-tracing.txt

• Se avete compilato il kernel con CONFIG_KALLSYMS potete inviare il dump così com'è, altrimenti dovrete usare il programma "ksymoops" per interpretare il 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, potete fare la ricerca del dump a mano:

• Nel debug di dump come quello sopra, è di grande aiuto se si può cercare cosa significa il valore EIP. Il valore esadecimale in sé non aiuta molto me o chiunque altro: dipenderà dalla vostra particolare configurazione del kernel. Quello che dovreste fare è prendere il valore esadecimale dalla riga EIP (ignorare 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, è necessario 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, 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 (anzi, è molto improbabile), quindi non si può semplicemente fare 'grep' dell'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 che si sta cercando 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" nel rapporto sul problema, fornendo alcune righe attorno a quella interessante.

  Se per qualche motivo non si riesce a fare quanto sopra (si ha un'immagine del kernel precompilata o simile), fornire quante più informazioni possibili sulla configurazione sarà d'aiuto. Leggere il documento REPORTING-BUGS per i dettagli.

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

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

  Usare gdb su un kernel non in esecuzione al momento fallisce perché gdb (erroneamente) ignora l'offset di partenza per cui il kernel è compilato.