Modalità utente VS modalità kernel

Come puoi vedere ha la gamma di indirizzi a cui la voce si riferisce, e i suoi attributi (permessi) come ci si aspetta.

Tabella dei descrittori locali

Tutto quello che abbiamo detto sulla GDT è vero anche per la LDT con piccole (ma grandi) differenze. Come suggerisce il nome, la GDT è applicata globalmente al sistema mentre la LDT è locale, cosa intendo per globalmente e localmente? Il GDT tiene traccia dei permessi per tutti i processi, per ogni thread e non cambia tra i cambi di contesto, l’LDT invece sì. Ha solo senso che se ogni processo ha il proprio spazio di indirizzamento, è possibile che per un processo l’indirizzo 0x10000000 sia eseguibile e per un altro sia di sola lettura/scrittura. Questo è particolarmente vero con ASLR attivo (sarà discusso più avanti). L’LDT è responsabile di mantenere i permessi che distinguono ogni processo.

Una cosa da notare è che tutto ciò che è stato detto è lo scopo della struttura, ma in realtà alcuni sistemi operativi potrebbero usare o non usare affatto alcune delle strutture. per esempio è possibile usare solo il GDT e cambiarlo tra i cambi di contesto e non usare mai l’LDT. Fa tutto parte della progettazione del sistema operativo e dei compromessi. Le voci di quella tabella sono simili a quelle del GDT.

Selettori

Come fa il processore a sapere dove guardare nel GDT o LDT quando esegue una specifica istruzione? Il processore ha registri speciali chiamati registri di segmento:

https://en.wikibooks.org/wiki/X86_Assembly/X86_Architecture

- Stack Segment (SS). Pointer to the stack. - Code Segment (CS). Pointer to the code. - Data Segment (DS). Pointer to the data. - Extra Segment (ES). Pointer to extra data ('E' stands for 'Extra'). - F Segment (FS). Pointer to more extra data ('F' comes after 'E'). - G Segment (GS). Pointer to still more extra data ('G' comes after 'F').

Ogni registro è lungo 16 bit e la sua struttura è la seguente:

http://www.c-jump.com/CIS77/ASM/Memory/M77_0290_segment_registers_protected.htm

Quindi abbiamo l’indice del GDT/LDT, abbiamo anche il bit che dice se è il LDT o il GDT, e quale modalità deve essere (RPL 0 è supervisore, 4 è utente).

Interrupt Descriptor Table

Oltre al GDT e LDT abbiamo anche l’IDT (Interrupt Descriptor Table), l’IDT è semplicemente una tabella che contiene gli indirizzi di funzioni molto importanti, alcune di esse appartengono al sistema operativo, altre ai driver e ai dispositivi fisici collegati al PC. Come il gdtr abbiamo l’idtr che, come probabilmente avrete capito, è il registro che contiene l’indirizzo dell’IDT. Cosa rende l’IDT così speciale? Quando avviamo un interrupt, la CPU passa automaticamente alla modalità supervisionata, il che significa che ogni funzione all’interno dell’IDT è in esecuzione in modalità supervisionata. Ogni thread di ogni modalità può innescare un interrupt emettendo l’istruzione ‘int’ seguita da un numero che dice alla CPU su quale indice risiede la funzione di destinazione. Detto questo, è ora ovvio che ogni funzione all’interno dell’IDT è un potenziale gateway in modalità supervisionata.

Quindi sappiamo che abbiamo il GDT/LDT che dice alla CPU i permessi per ogni indirizzo virtuale e abbiamo l’IDT che punta le funzioni ‘gateway’ al nostro amato kernel (che ovviamente risiede nella sezione supervisionata della memoria). Come si comportano queste strutture in un sistema in funzione?

Memoria virtuale

Prima di poter capire come tutto questo gioca insieme dobbiamo coprire un altro concetto – la memoria virtuale. Ricordate quando ho detto che c’è una tabella che mappa ogni indirizzo di memoria virtuale al suo indirizzo fisico? In realtà è un po’ più complicato di così. Per prima cosa non possiamo semplicemente mappare ogni indirizzo virtuale in quanto richiederebbe più spazio di quello che abbiamo effettivamente, e mettendo da parte la necessità di essere efficienti, il sistema operativo può anche scambiare pagine di memoria nel disco (per efficienza e prestazioni), è possibile che la pagina di memoria dell’indirizzo virtuale necessario non sia in memoria al momento, quindi oltre a tradurre l’indirizzo virtuale a quello fisico abbiamo anche bisogno di salvare se la memoria è in RAM e se no, dove si trova (potrebbe esserci più di un file di pagina). La MMU (Memory Management Unit) è il componente responsabile di tradurre la memoria virtuale in una fisica.

Una cosa davvero importante da capire è che ogni istruzione in ogni modalità passa attraverso il processo di traduzione dell’indirizzo virtuale, anche il codice in modalità supervisionata. Una volta che la CPU in modalità protetta, ogni istruzione che esegue utilizza l’indirizzo virtuale – mai fisico (ci sono alcuni trucchi che l’indirizzo virtuale attuale si tradurrà sempre nella stessa esatta memoria virtuale, ma questo è al di fuori dello scopo di questo post).

Quindi una volta in modalità protetta, come la CPU sa dove guardare quando ha bisogno di tradurre l’indirizzo virtuale? la risposta è il registro CR3, questo registro contiene l’indirizzo della struttura che contiene le informazioni richieste – Page directory. Il suo valore cambia con il processo in corso (di nuovo, spazio di indirizzi virtuali diverso).

Come è fatta questa Page Directory? Quando si tratta di efficienza abbiamo bisogno di essere in grado di interrogare questa “tabella” il più velocemente possibile, abbiamo anche bisogno che sia il più piccolo possibile perché questa tabella sarà creata per ogni processo. La soluzione a questo problema è niente meno che brillante. La migliore immagine che ho trovato per illustrare il processo di traduzione è questa (da wikipedia):

La MMU ha 2 input, l’indirizzo virtuale da tradurre e il CR3 (indirizzo della directory della pagina attualmente rilevante). La specifica x86 taglia l’indirizzo virtuale in 3 pezzi:

• 10 bit numero – indice della directory di pagina.
• 10 bit numero – indice della tabella di pagina.
• 12 bit numero – offset dell’indirizzo fisico stesso.

Quindi il processore prende il primo numero di 10 bit e lo usa come indice per la tabella delle pagine, per ogni voce nella tabella delle pagine abbiamo la tabella delle pagine, che poi il processore usa il successivo numero di 10 bit come indice. Ogni voce della tabella di directory punta alla pagina di memoria 4K che poi l’ultimo offset di 12bit dall’indirizzo virtuale è usato per puntare alla posizione esatta nel fisico. La genialità in questa soluzione è:

• La flessibilità che ogni indirizzo virtuale individua un indirizzo fisico completamente indipendente.
• L’efficienza nello spazio delle strutture coinvolte è sorprendente.
• Non tutte le voci di ogni tabella sono usate, solo gli indirizzi virtuali che sono effettivamente usati e mappati dal processo esistono nelle tabelle.

Sono veramente dispiaciuto per non aver spiegato questo processo in modo più dettagliato, questo è un processo ben documentato che molte persone hanno lavorato duramente per spiegarlo meglio di quanto potrei mai fare io – cercatelo su Google.

Kernel vs Utente

Ecco dove diventa interessante (e magico se posso).

Abbiamo iniziato questo articolo affermando che il SO orchestra tutto, lo fa usando il kernel. Come già detto il kernel è in esecuzione in una sezione di memoria che è mappata come modalità supervisionata solo nel GDT per tutti i processi. Sì, so che ogni processo ha il proprio spazio di indirizzi, ma il kernel sta tagliando quello spazio di indirizzi (di solito la metà superiore, dipende dal sistema operativo) per il suo uso personale, non solo tagliando lo spazio di indirizzi ma anche allo stesso indirizzo per tutti i processi. Questo è importante perché il codice del kernel è fisso e ogni riferimento a variabili e strutture deve essere nella stessa posizione per tutti i processi. Si può considerare il kernel come una libreria speciale caricata in ogni processo nella stessa posizione.

Più a fondo negli interrupt

Sappiamo che l’IDT contiene indirizzi di funzioni, queste funzioni chiamate ISR (Interrupt Service Routine), alcune vengono eseguite quando si verifica un evento hardware (pressione di un tasto sulla tastiera) e altre quando il software avvia l’interrupt, per esempio per passare alla modalità kernel.

Windows ha un bel concetto sugli interrupt e sulla loro priorità: Un interrupt particolarmente importante è il ticchettio dell’orologio. Con ogni ticchettio dell’orologio c’è un interrupt che viene gestito dal suo ISR. Lo scheduler del sistema operativo usa questo evento dell’orologio per controllare quanto tempo ogni processo è in esecuzione e se è o meno il turno di un altro. Come potete capire questo interrupt è super importante e deve essere servito non appena accade, non tutti gli ISR hanno la stessa importanza ed è qui che entrano in gioco le priorità tra gli interrupt. Prendiamo ad esempio la pressione di un tasto sulla tastiera e supponiamo che abbia la priorità 1, ho appena premuto un tasto sulla tastiera e il suo ISR è in esecuzione, mentre si esegue l’ISR della tastiera tutti gli interrupt della stessa priorità o inferiori vengono ignorati. Durante l’esecuzione dell’ISR, l’ISR dell’orologio viene attivato con priorità 2 (che è il motivo per cui non è stato disabilitato), il passaggio immediato si verifica all’ISR dell’orologio, una volta che l’orologio termina restituisce il controllo all’ISR della tastiera da dove si è fermato. Queste priorità di interrupt chiamate IRQL (Interrupt ReQuest Level), come l’IRQL dell’interrupt sale la sua priorità è maggiore. Gli interrupt con la priorità più alta non sono mai interrupt nel mezzo, vengono eseguiti fino alla fine, sempre. IRQL è specifico di Windows – l’IRQL è un numero tra 0-31, per Linux, invece, non esiste, Linux gestisce ogni interrupt con la stessa priorità e semplicemente disabilita tutti gli interrupt quando ha davvero bisogno che quella specifica routine non sia disturbata. Come potete vedere è tutta una questione di design e preferenze.

Colleghiamo il tutto al nostro amato User mode . L’ISR di quell’evento di clock sta per essere eseguito indipendentemente dal thread attualmente in esecuzione e potrebbe anche interrompere ad un altro ISR per un compito non correlato. questo è un perfetto esempio del perché il kernel è allo stesso indirizzo per tutti i processi che non vogliamo cambiare il GDT e il Page Directory (in C3) ogni volta che eseguiamo l’interrupt come accade MOLTE volte durante anche una singola funzione di qualsiasi processo in modalità utente. Un sacco di cose stanno accadendo tra quelle righe di codice che scrivete quando sviluppate la vostra applicazione in modalità utente (;)).

Un altro modo di guardare agli interrupt è come input esterni e indipendenti per il nostro sistema operativo, questa definizione non è accurata (non tutti gli interrupt sono esterni o indipendenti) ma è buona per fare un punto, gran parte del lavoro del kernel è quello di dare un senso agli eventi che si verificano tutto il tempo da ogni luogo (dispositivi di input) e da un lato per servire quegli eventi e l’altro per assicurarsi che tutto sia correlato correttamente.

Per dare un senso a tutto ciò, iniziamo con una semplice applicazione in modalità utente che esegue la seguente istruzione:

0x0000051d push ebp;

Per ogni istruzione che la CPU sta eseguendo, prima esamina l’indirizzo di quell’istruzione (in questo caso ‘0x0000051d’) rispetto al GDT/LDT usando il registro del segmento di codice (‘cs’ perché è l’istruzione da eseguire) per conoscere l’indice da cercare nella tabella (ricordate che il registro del segmento dice alla CPU esattamente dove guardare). Una volta che la CPU sa che l’istruzione è nella posizione eseguibile e che siamo nel ring giusto (modalità utente/modalità kernel) ora continua ad eseguire l’istruzione. In questo caso l’istruzione ‘push ebp’ non agisce solo sul registro ma anche sullo stack del programma (spinge sullo stack il contenuto di ebp) quindi la CPU controlla anche il GDT/LDT per l’indirizzo all’interno del registro esp (l’indirizzo della posizione corrente sullo stack, e poiché è la posizione dello stack la CPU sa di usare il registro del segmento dello stack per farlo) per assicurarsi che sia scrivibile in quello specifico anello. Notate che se questa istruzione fosse anche in lettura dalla memoria la CPU avrebbe controllato anche il relativo indirizzo per l’accesso in lettura.

Questo non è tutto, dopo che la CPU ha controllato tutti gli aspetti di sicurezza è ora necessario accedere e manipolare la memoria, come si ricorda gli indirizzi sono nel loro formato virtuale. La MMU ora traduce ogni memoria virtuale specificata dall’istruzione in un indirizzo di memoria fisica utilizzando il registro CR3 che punta al page directory (che punta alla tabella delle pagine) che ci permette di tradurre eventualmente l’indirizzo in quello fisico. Si noti che l’indirizzo potrebbe non essere in memoria al momento del bisogno, in questo caso il sistema operativo genererà un page fault (un’eccezione che genera un interrupt) e porterà i dati nella memoria fisica per noi e poi continuerà l’esecuzione (questo è trasparente per l’applicazione in modalità utente).

Dall’utente al kernel

Ogni scambio tra la modalità utente alla modalità kernel avviene utilizzando l’IDT. Dall’applicazione in modalità utente, l’istruzione ‘int <num>’ trasferisce l’esecuzione alla funzione nell’IDT all’indice num. Quando l’esecuzione è in modalità kernel molte regole cambiano, ogni thread ha stack diversi per la modalità utente e kernel, i controlli di accesso alla memoria sono molto più complicati e obbligatori, in modalità kernel c’è molto poco che non si può fare e molto che si può rompere.

ASLR e KASLR

il più delle volte è “solo” la mancanza di conoscenza che ci impedisce di raggiungere l’impossibile.

ASLR (Address Space Layout Randomization) è un concetto che viene implementato in modo diverso all’interno di ogni OS, il concetto è quello di randomizzare gli indirizzi virtuali dei processi e delle loro librerie caricate.

Prima di tuffarci volevo notare che ho deciso di includere ASLR in questo post perché è un bel modo per vedere come la modalità protetta e le sue strutture hanno abilitato questo tipo di capacità anche se non è quella che la implementa o ne è responsabile.

Perché ASLR?

Il perché è facile, per prevenire gli attacchi. Quando qualcuno è in grado di iniettare codice in un processo in esecuzione, non conoscere gli indirizzi di alcune funzioni utili è ciò che può far fallire l’attacco.

Abbiamo già diversi spazi di indirizzo per ogni processo, questo significa che senza ASLR tutti i processi avrebbero gli stessi indirizzi di base, questo perché quando ogni processo nel proprio spazio di indirizzo virtuale non dobbiamo diffidare delle collisioni tra processi. Quando colleghiamo il programma, il linker sceglie un indirizzo di base fisso su cui collegare l’eseguibile. Sulla carta tutti i file eseguibili collegati dallo stesso linker con i parametri di default (l’indirizzo di base può essere configurato se necessario) avranno lo stesso indirizzo di base. Per fare un esempio ho scritto due applicazioni una chiamata “1.exe” e la seconda “2.exe”, entrambi sono progetti diversi in Visual Studio eppure entrambi hanno lo stesso indirizzo di base (ho usato exeinfo PE per vedere l’indirizzo di base nel file PE):

Lo puoi vedere anche incluso nel formato PE sotto Caratteristiche file:

Ora eseguiamo entrambi gli eseguibili allo stesso tempo ed entrambi condividono lo stesso indirizzo di base (userò vmmap di Sysinternals per visualizzare l’immagine di base):