AOS - 11 - KERNEL PROGRAMMING BASICS IV

I numerical codes sono delle macro che associano ad un valore simbolico della forma __NR_<system_call_name> che rappresenta un particolare servizio offerto dal kernel un numero da 0 fino all'indice massimo della system call table. In questo modo è possibile associare ad ogni servizio offerto da kernel ed eventualmente implementato come system call, un codice numerico.

Queste macro sono definite in vari file, a seconda della particolare versione del kernel. Ad esempio troviamo,

• Nel file /usr/include/asm/unistd_32.h troviamo i codici numerici per le system call in architetture x86 a 32 bit.

         #ifndef _ASM_X86_UNISTD_32_H
         #define _ASM_X86_UNISTD_32_H 1
  
         #define __NR_restart_syscall 0
         #define __NR_exit 1
         #define __NR_fork 2
         #define __NR_read 3
         #define __NR_write 4
         #define __NR_open 5
         #define __NR_close 6
         #define __NR_waitpid 7
         #define __NR_creat 8
         #define __NR_link 9
         #define __NR_unlink 10
  

• Nel file /usr/include/asm/unistd_64.h invece troviamo i codici numerici per le system call in architetture x86 a 64 bit (x86_64).

         #ifndef _ASM_X86_UNISTD_64_H
         #define _ASM_X86_UNISTD_64_H 1
  
         #define __NR_read 0
         #define __NR_write 1
         #define __NR_open 2
         #define __NR_close 3
         #define __NR_stat 4
         #define __NR_fstat 5
         #define __NR_lstat 6
         #define __NR_poll 7
         #define __NR_lseek 8
         #define __NR_mmap 9
         #define __NR_mprotect 10
  

Notiamo che in x86 a 32 bit la system call associata al codice numero 0 è chiamata restart_syscall . Questa system call è una system call "dummy", nel senso che quando viene eseguita non fa altro che ritornare, senza fare nessun tipo di lavoro effettivo. Il codice di questa system call viene utilizzato ogni volta che nella system call table è presente un valore numerico associato ad un servizio che non è ancora stato implementato all'interno del kernel. In questo senso la system call "dummy" funzoina da stub, che blocca i buchi della system call table.

All'interno dei file menzionati prima sono anche presenti delle macro che permettono di definire dei blocchi di codice necessari per chiamare una particolare system call. In particolare abbiamo una macro per numero di argomenti, come mostrato a seguire

• _syscall0(type, name)

• _syscall1(type, name, type1, arg1)

• _syscall2(type, name, type1, arg1, type2, arg2)

Andando ad analizzare la macro _syscall0(type, name) , che permette di chiamare una qualsiasi system call con \(0\) argomenti, troviamo il seguente codice

     #define _syscall0(type, name)                      \
       type name(void)                          \
       {                                                \
         long __res;                                    \
         __asm__ volatile ("int $0x80"          \
                           : "=a" (__res)               \
                           : "0" (__NR_##name));        \
         __syscall_return(type, __res);         \
       }

Tale codice non fa altro che chiamare una software trap indicizzanto il GATE 0x80 , che contiene il codice necessario per far partire il dispatcher. Al dispatcher poi passiamo in input tramite il registro RAX il codice numerico della sys call da utilizzare. Infine, si prende l'output risultante dalla sys call e lo si inserisce nella variabile __res . Il contenuto di questa variabile è poi controllato attraverso la macro __syscall_return .

Nelle varie macro che chiamano sys call con diversi argomenti alla fine è sempre presente la macro __syscall_return(type, __res) . Il compito di questa macro è gestire il valore di ritorno in modo corretto. In particolare controlla se c'è stato qualche errore, e che tipo di errore c'è stato.

Nello standard POSIX si è definito che nel caso in cui una system call fallisce, il suo valore di ritorno dovrebbe essere \(-1\). Negli ambienti di esecuzione \(C\) poi in caso di fallimento si ha che tipicamente nella variabile errno è presente il particolare numero di errore, che contiene delle informazioni più specifiche sulla natura del fallimento. Il kernel però ritorna un solo valore dalla system call. Per poter dire che c'è stato un errore, e anche che tipologia di errore c'è stata, si è deciso di far ritornare al kernel un valore a segno negativo. La libreria <asm-i386/errno.h> contiene tutti gli user-visibile error numbers tra \(-1\) e \(-124\).

Il codice della macro __syscall_return(type, __res) è il seguente

     #define __syscall_return(type, res)                        \
       do {                                                     \
       if ((unsigned long)(res) >= (unsigned long)(-125)) {     \
       errno = -(res);                                  \
       res = -1;
     }               \
     return (type) (res); \
     } while 0

Notiamo come il costrutto do/while(0) viene utilizzato per definire delle macro con varie proprietà interessanti, in quanto permette di

• Definire una macro (#define) con più statements.

• Nettere un ; alla fine.

• Utilizzare la macro dentro un blocco if.

Il codice che permette di chiamare una system call a 6 parametri sulla i386 , ovvero la versione x86 a 32 bit è più complesso, in quanto non bastano i general purpose registers per passare tutti i parametri. Infatti su i386 abbiamo solamente \(4\) registri general purpose, mentre noi dobbiamo utilizzare \(7\) registri: 6 per i parametri, e uno per il codice della syscall.

Per risolvere questo problema vengono quindi utilizzati altri registri, tra cui il registro EBP. Prima di poterlo utilizzare però il registro EBP deve essere salvato nello stack, e dopo essere ritornati dalla system call il registro deve essere ripristinato con il suo vecchio valore.

Il codice per gestire la sys call è il seguente

     #define _syscall0(type, name, type1, arg1, type2, arg2, type3, arg3, type4, arg4, type5, arg5, type6, arg6) \
       type name(type1 arg1, type2 arg2, type3 arg3, type4 arg4, type5 arg5, type6 arg6) \
       {                                                                        \
         long __res;                                                            \
         __asm__ volatile ("push %%ebp; movl %%eax, %%ebp ; movl %1 %%eax ; int $0x80 ; pop %%ebp" \
                           : "=a" (__res)                                       \
                           :    "i" (__NR_##name), "b" ((long) (arg1)), "c" ((long)(arg2)), \
                             "d" ((long)(arg3)), "S" ((long)(arg4)), "D" ((long)(arg5)), \
                             "0" ((long)(arg6)));                               \
         __syscall_return(type, __res);                                 \
       }

Durante la chiamata del dispatcher, prima che il dispatcher prende il controllo, il firmware può cambiare lo stato del processore. In particolare il dispatcher e il firmware modificando la struttura dello stack che la system call si troverà una volta che viene mandata in esecuzione. Si parla quindi di stack allignment per intendere cosa si deve trovare nello stack e in che ordine i dati devono essere organizzati.

I valori che vengono inseriti nello stack da parte del firmware sono tipicamente utilizzati per gestire il ring model. Ad esempio vengono memorizzate informazioni sul code segment originale e sullo stack pointer originale.

A seconda della versione di x86, abbiamo diversi stack allignments.

Nella modalità a 64 bit, x86-64, è stato introdotto un ulteriore metodo per passare in modo kernel. Questo metodo è stato introdotto specificatamente per l'esecuzione di system call e a differenza del meccanismo delle software traps e degli interrupt, questo nuovo metodo è più performante, anche se necessita un settaggio dello stato del processore più estensivo.

Dato che abbiamo due modalità per entrare nel kernel, il modo e l'ordine in cui vengono utilizzati i vari registri cambia a seconda se stiamo utilizzando il metodo classico (quello delle trap), o il metodo veloce. Per fare un esempio il registro RCX viene utilizzato in modo diverso dai due meccanismi appena menzionati: con il vecchio metodo viene utilizzato per passare il terzo argomento (arg3), mentre nel nuovo metodo viene utilizzato per passare l'indirizzo di ritorno syscall/sysret.

Oltre a definire lo stack allignment, la ABI (Application Binary Interface) specifica anche chi deve preservare i registri del processore. Parte di questi registri devono essere infatti preservati dal "chiamato" e alcuni dal "chiamante". In particolare se il chiamato vuole utilizzare i registri RBX, RBP e da R12 a R15, sarà suo il compito di preservarli (registri callee saved). Tutti gli altri registri sono salvati dal chiamante, se è interessato a preservane i valori.

In questo blocco di codice costruiamo un meccanismo per eseguire echo senza utilizzare le tipiche system call read() e write() offerte dalla libreria C, ma andando a codificare all'interno del codice C un pezzo di codice ASM che chiama direttamente il dispatcher attraverso la software trap "int 0x80".

Il corpo principale del codice è un while loop che esegue due funzioni

     char c; // putting c here (low addresses) allows correct runs when
             // using ecx as pointer to c with -D m32 compilation

     char* newline="\n";
     char v[1024];

     void instring(char*);
     void outstring(char*);

     int _start(int argc){

       while(1){
         instring(v);
         outstring(v);
         outstring(newline);
       }

     }

Le funzioni di lettura e scrittura contengono il codice ASM necessari per comunicare al kernel di leggere e scrivere dal terminale e sono implementate come segue

• instring(v) legge una stringa da terminale un byte alla volta

         void instring(char *s){
           long  i = 0;
  
           do{
         #ifndef m32
             // In modalità x86-64 abbiamo un modo alternativo per passare in
             // lato kernel per eseguire le system call. Questo medoto si basa
             // sull'istruzione syscall. 
             asm("mov %%rbx, %%rdi; \n"
                 "mov %%rcx, %%rsi; \n"
                 "mov %%rdx, %%rdx; \n"
                 "syscall "
                 :
                 : "a" (0) ,
                   "b" (0) ,
                   "c" ((unsigned long)(&c)) ,
                   "d" ((long)(1)));
         #else
             // In modalità x86 a 32 bit l'unico modo per eseguire le sys call
             // è attraverso il GATE 0x80. Questo codice non fa altro che
             // chiamare la system call write() per leggere da STDOUT un byte e
             // scriverlo nella cella di memoria di c
             //
             //        read(0, &c, 1); 
             // 
             asm("int $0x80" :
                 : "a" (3) , // Imposta RAX a 3, che è il codice numerico della
                             // systemc all read(). 
  
                   "b" (0) , // Primo parametro della sys call, 0 = STDOUT. 
  
                   "c" ((unsigned long)(&c)) , // Secondo parametro della sys
                                               // call, indirizzo della variabile c.
  
                   "d" ((long)(1)));  // Terzo parametro della sys call, numero
                                      // di byte da scriveren nel terminale. 
         #endif
             s[i] = c; 
             i++; 
           }
           while ( (c!='\n') && (c!=' ') && (c!='\t')); // Ripeti finché non
                                                        // troviamo uno spazio,
                                                        // una newline, o una tab. 
           i--;
           s[i]='\0';
         }
  
  

• outstring(v) , che scrive a terminale.

         void outstring(char *s){
           long  i=0;
           while (s[i++]!='\0'); // compute length of string to print
           i--;
    
         #ifndef m32
           asm("mov %%rbx, %%rdi; \n"
               "mov %%rcx, %%rsi; \n"
               "mov %%rdx, %%rdx; \n"
               "syscall "
               :
               : "a" (1) ,
                 "b" (1) ,
                 "c" ((unsigned long)(s)) ,
                 "d" ((long)(i)) );
         #else
           asm("int $0x80"
               :
               : "a" (4) ,
                 "b" (1) ,
                 "c" ((unsigned long)(s)) ,
                 "d" ((long)(i)) );
         #endif
         }
  

In questo esempio abbiamo definito a mano una macro per poter definire lato user una nuova system call che effettua una fork()

     #include <unistd.h>
     #define __NR_my_fork 2

     #define _new_syscall0(name)                        \
       int name(void)                           \
       {                                                \
         asm("int $0x80" : : "a" (__NR_##my_fork) ); \
         return 0;                                      \
       }                                                \

     _new_syscall0(my_fork)

       int main(int a, char** b){
       my_fork();
       pause();
     }

This homework deals with the implementation of a TLS support standing aside of the original one offered by gcc. It should be based on a few macros with the following meaning:

• PER_THREAD_MEMORY_START and PER_THREAD_MEMORY_END are used to delimitate the variable declarations that will be part of TLS

• READ_THREAD_VARIABLE(name) is used to return the value of a TLS variable with a given name

• WRITE_THREAD_VARIABLE(name, value) is used to update the TLS variable with a given name to a given value

Essentially, the homework is tailored to implementing an interface for managing per-thread memory resembling the one offered by the Linux kernel for managing per-CPU memory.

L'idea base è quella di definire le macro di creazione della TLS in modo da wrappare le variabili che vogliamo all'interno della TLS all'interno di una struct.

     #define PER_THREAD_MEMORY_START typedef struct tls_zone {  \
       unsigned long tls_zone_address;

     #define PER_THREAD_MEMORY_END } tls_zone;

dove nel campo tls_zone_address ci andremmo ad inserire l'indirizzo della tls_zone in modo da poterlo recuperare velocemente. Così facendo se scriviamo

     PER_THREAD_MEMORY_START
     int x;
     int y;
     double z;
     PER_THREAD_MEMORY_END

La macro verrà risolta durante la compilazione nel seguente modo

     typedef struct tls_zone {      
       unsigned long tls_zone_address;
       int x;
       int y;
       double z;
     } tls_zone;

La creazone della TLS avviene nel seguente modo: nella funzione di creazione del thread ci andiamo ad allocare della memoria con mmap() , ci salviamo le informazioni sull'indirizzo della TLS zone all'interno della TLS zone, e settiamo la base del segmento puntato dal selettore GS con la funzione arch_prctl() .

     void *init(void *arg)
     {
       // Get ID info
       unsigned long me = (unsigned long)arg;
  
       // Allocate memory for TLS zone
       void *mem = mmap(NULL,
                        sizeof(struct tls_zone),
                        PROT_READ | PROT_WRITE,
                        MAP_ANONYMOUS | MAP_PRIVATE,
                        0, 
                        0);

       // Put address information in the TLS zone
       ((tls_zone *)mem)->tls_zone_address = (unsigned long) mem;

       // Set base for GS segment
       arch_prctl(ARCH_SET_GS, mem);
       printf("(%d) - Base address for GS segment is at %p\n", me, mem);  

       // Do actual work
       work(me);
  
       return NULL;
     }

Così facendo ogni volta che il thread è in esecuzione possiamo risalire all'indirizzo della TLS utilizzando l'indirisso base del segmento GS.

Al fine di definire le funzioni per la lettura la scrittura delle variabili nella nostra TLS definiamo prima la funzione che ritorna l'indirizzo base del TLS. Dato che il TLS verrà caricato all'indirizzo base del segmento puntato dal selettore GS, possiamo definire tale funzione come segue

     unsigned long get_tls_address(void)
     {
       unsigned long addr;
       asm("mov %%gs:(0), %0": "=b" (addr));
       return addr;
     }

Riportiamo quindi l'implementazione delle macro di lettura e scrittura.

     #define READ_THREAD_VARIABLE(name) \
       ((tls_zone*)(get_tls_address()))->name

     #define WRITE_THREAD_VARIABLE(name, value) \
       ((tls_zone*)(get_tls_address()))->name = value;

Per testare il codice appena scritto possiamo quindi utilizzare la funzione work()

     void work(unsigned long id)
     {
       int c;
       double d;

       printf("(%d) - Before work\n", id);
       c = READ_THREAD_VARIABLE(x);
       printf("(%d) - Variable x has value: %d\n", id, c);

       // ------
       if(id == 1) {
         WRITE_THREAD_VARIABLE(x, 10);
       } else if (id == 2) {
         WRITE_THREAD_VARIABLE(x, 20);
       }

       // ------
       printf("(%d) - After work\n", id);
       c = READ_THREAD_VARIABLE(x);
       printf("(%d) - Variable x has value: %d\n", id, c);
     }

Infine, come main() possiamo semplicemente creare due thread e vedere il risultato

     int main(int argc, char **argv)
     {
       pthread_t tid1, tid2;

       pthread_create(&tid1, NULL, init, (void*) 1);
       pthread_create(&tid2, NULL, init, (void*) 2);

       pause();
  
       return 0;
     }

Compilando ed seguendo

   gcc tls.c -lpthread
   ./a.out

otteniamo il seguente risultato

     (1) - Base address for GS segment is at 0x7f5c20f56000
     (1) - Before work
     (1) - Variable x has value: 0
     (1) - After work
     (1) - Variable x has value: 10
     (2) - Base address for GS segment is at 0x7f5c20f55000
     (2) - Before work
     (2) - Variable x has value: 0
     (2) - After work
     (2) - Variable x has value: 20

Come possiamo vedere, ogni thread ha una propria versione locale della variabile \(x\), anche se il codice utilizzato per accedere alla variabile è lo stesso: l'offset generato dal compilato non cambia, ma durante l'esecuzione l'indirizzo base associato al selettore GS utilizzato dal primo thread è diverso dall'indirizzo base associato al selettore GS utilizzando dal secondo thread.