AOS - 09 - KERNEL PROGRAMMING BASICS II

La tabella GDT è caricata in memoria durante la fase di inizializzazione del sistema e viene poi puntata dal registro gdtr . Il registro gdtr contiene quindi l'indirizzo in memoria della tabella GDT. Più precisamente il registro gdtr è una packed structure che contiene non solo l'indirizzo in memoria della tabella GDT, ma anche la grandezza della tabella.

   // struct view of gdtr register
     struct desc_ptr {
       unsigned short size;
       unsigned long address;
     } __attribute__((packed)) ;

Al fine di calcolare la posizione di una particolare entry della tabella bisogna tenere a mente che i selettori di segmento contengono solamente l'indice di una entry della GDT, e non l'indirizzo di dove si trova la particolare entry. Detto questo, sapendo l'indirizzo di base della GDT, e utilizzando il fatto che ciascuna entry occupa 8 bytes, possiamo accedere alla \(i\) esima entry della GDT lavorando in protected mode utilizzando il seguente indirizzo

\[\text{addr of i-th entry of GDT} = \text{GDT_base_addr} + 8 \cdot i\]

Infine, è importante notare che il size della tabella GDT può essere espresso con al massimo 2 byte di memoria. Questo significa che le tabelle GDT non possono essere troppo grandi.

Esempio: Se la GDT è memorizzata a partire dall'indirizzo 0x00020000 , allora l'indirizzo della entry con indice \(2\) è dato da

\[\text{0x00020000} + 2 \cdot 8 = \text{0x00020010}\]

Se invece lavoriamo in x86 long-mode, allora il registro gdtr contiene l'indirizzo della tabella espresso nella forma canonica in 64-bit assieme ai soliti 16 bit utilizzati per specificare la grandezza della tabella.

Tramite l'istruzione SGDT offerta dall'ISA x86 siamo in grado di leggere il contenuto del registro gdtr. Il seguente codice non fa altro che definire una struttura dati packed in modo da evitare l'eventuale inserimento di padding da parte del compilatore, utilizzare l'istruzione sgdt per caricare nella struttura definita prima il valore del registro gdtr, e poi andarlo a leggere tramite una printf().

     #include <stdio.h>
     #include <stdlib.h>

     // do not insert padding in the structure.
     struct desc_ptr {
             unsigned short size;
             unsigned long address;
     } __attribute__((packed)) ;

     // store the contents of the gdtr register
     #define store_gdt(ptr) asm volatile("sgdt %0":"=m"(*ptr))

     int main(void)
     {
       struct desc_ptr gdtptr;

       store_gdt(&gdtptr);
       printf("GDTR is at %p - size is %d\n", gdtptr.address, gdtptr.size);

       return 0;
     }

Tramite l'utility taskset siamo poi in grado di eseguire lo stesso programma su CPU diverse. Un esempio di esecuzione ha riportato i seguenti risultati

   # taskset 0x1 ./a.out
   GDTR is at 0xfffffe0000001000 - size is 127

   # taskset 0x2 ./a.out
   GDTR is at 0xfffffe000002c000 - size is 127

Notiamo che a seconda della CPU otteniamo indirizzi diversi. Questo vuol dire che ogni CPU core ha la propria GDT. Il fatto che ogni CPU core ha la propria GDT è collegato al fatto che la segmentazione ha un ruolo fondamentale nella programmazione di sistema multi-core.

La GDT utilizzata da LINUX nelle architetture x86 ha la seguente forma

Alcune entry importanti della GDT presente in linux in x86 sono le seguenti

Quando entriamo all'interno di un GATE il codice presente nel GATE dovrà occuparsi di aggiornare le entry della GDT con dei particolari valori per creare una determinata visione della memoria.

Abbiamo dunque due livelli in cui possiamo effettuare delle modifiche:

• Possiamo modificare i selettori per farli puntare a diverse entry della GDT. Ad esempio se stiamo eseguendo un programma applicativo il selettore CS punterà all'entry 0x73 della GDT, ovvero al segmento user code (__USER_CS). Se durante l'esecuzione andiamo a chiamare una system call, il kernel prima di iniziare la sua esecuzione dovrà cambiare il valore del selettore CS per puntarlo a una diversa entry della GDT, in particolare la entry kernel code (__KERNEL_CS).

• Possiamo modificare i valori della tabella stessa. In questo modo possiamo anche lasciare invariato il selettore utilizzato per ottenere comunque accessi alla memoria diversi. Infatti scrivere una nuova base per una entry della GDT ci permette di accedere a locazioni di memoria diverse utilizzando lo stesso codice.

Andiamo adesso a vedere come utilizzare i segmenti in modo esplicito durante la programmazione. A tale define definiamo le seguenti macro che ci permettono di utilizzare i selettori di segmento in modo esplicito

     #include <stdio.h>

     // uses the offset ptr explicitly with the segment DS (data segment)
     // to access a location in memory and loads the content into variable
     // var.
     #define load(ptr, var) volatile asm("mov %%ds:(%0), %%rax ": "=a" (var) :"a"(ptr))

     // load the values val into register RAX, and then stores this value
     // into the memory location obtained by combining the base of selector
     // DS (data segment) with offset ptr. 
     #define store(val, ptr) volatile asm("mov %0, %%ds:(%1)":: "a" (val), "b" (ptr))

L'utilizzo di queste macro è piuttosto intuitivo.

     int main(int argc, char **argv)
     {
       unsigned long x = 16;
       unsigned long y;

       load(&x, y);
       printf("variable y has value %u\n", y);

       store(y+1, &x);
       printf("variable x has value %u\n", x);
  
       return 0;
     }

Notiamo che se cambiamo l'esecuzione cambiando il selettore e utilizzando CS e GS , otteniamo lo stesso risultato. Se però utilizziamo il selettore FS otteniamo un segmentation fault. Questo comportamento segue dal fatto che i selettori CS , DS e GS hanno tutti la stessa base, ovvero 0x0 . Invece il selettore FS non è valido di default e quindi non è mappato nella GDT. Quando utilizziamo un selettore non mappato nella GDT otteniamo un segmentation fault.

Esistono istruzioni macchina per cambiare il contenuto di ogni selettore di segmento tranne che per il selettore di segmento CS. Il selettore CS infatti gioca un ruolo centrale nel ring-model, in quanto mantiene il CPL (Current Privilege Level). Per questa ragione il selettore CS viene implicitamente aggiornato dal firmware durante le variazioni di flusso.

Tutti gli altri selettori possono invece essere aggiornati da determinate istruzioni se e solo se il DPL del nuovo segmento è tale che DPL >= CPL, ovvero se e solo se il nuovo segmento a cui vogliamo accedere ha un livello di privilegio più alto. In particolare il kernel linux offre delle system call per poter cambiare il descrittore di particolari segmenti.

Nel caso in cui lavoriamo a livello 0, ovvero CPL = 0, possiamo fare qualsiasi cosa nel sistema, e quindi possiamo aggiornare qualsiasi selettore.