AOS - 13 - KERNEL PROGRAMMING BASICS VI

This homework deals with the implementation of a Linux kernel module that discovers at run-time the positioning of the system-call table. The simplifying assumption is that the module programmer can exploit the kernel-side name of some system-call (hence the corresponding actual address) in order to perform the discovery phase. The module should provide the current memory address of the system-call table via a kernel level message accessible via the 'dmesg' shell command.

La discovery della tabella viene fatta sfruttando la relazione tra la locazione di memoria del codice di una system call con il suo particolare indice. In particolare sappiamo che vale la seguente relazione

sys_call_table_addr[__NR_sys_call] = sys_call_address

L'idea è quindi di utilizzare il codice numero di una sys-call e l'indirizzo logico della stessa sys-call per fare uno scan della memoria. Dato un indirizzo addr della memoria, posso fare il seguente check per capire se, potenzialmente, addr punta alla sys_call_table

if (addr[__NR_sys_call] = sys_call_address) {
  // possible hit
 }

Notiamo che questo procedimento ci potrebbe dare anche dei falsi positivi, ovvero delle locazioni di memoria che rispettano il vincolo ma che non puntano alla vera syscall table. Andando ad aumentare il numero di check, ovvero controllando che la stessa relazione sussiste anche per altre syscalls, aumentiamo anche il grado di certezza che l'indirizzo trovato sia veramente l'indirizzo iniziale della sys_call_table.

Notiamo che per implementare correttamente questa idea dobbiamo partire da qualche indirizzo che si trova, nella memoria logica del kernel, prima della syscall table.

Per risolvere questa problematica è utile tenere a mente il fatto che il kernel è una tecnologia che viene tradizionalmente costruita tramite un metodo che prende il nome di incremental linking . Tale tecnica consiste nel costruire software complessi in modo incrementale, aggiungendo, di volta in volta, nuovi blocchi al software precedentemente scritto. Questi blocchi che vengono aggiunto hanno la proprietà che i loro indirizzi logici si trovano dopo gli indirizzi logici dei blocchi già presenti.

Per il nostro particolare problema, questo significa che se prendiamo l'indirizzo di una system call generica, il suo indirizzo è sempre precedente a quello della system call table.

Il pezzo di codice principale che fa la discovery è quindi il seguente

unsigned long *get_syscall_table(void)
{
  unsigned long *syscall_table;
  unsigned long int i;

  // Nei kernel <= 3.x il simbolo sys_close viene espotarto. 
  for (i = (unsigned long int)sys_close; i < ULONG_MAX; i += sizeof(void *)) {
    syscall_table = (unsigned long *)i;

    // Check di correttezza
    if (syscall_table[__NR_close] == (unsigned long)sys_close)
      return syscall_table;
  }
  
  return NULL;
}

Per terminare, notiamo che se non trovo la syscall table e continuo a scorrere la memoria fino ad arrivare alla fine della memoria andrò a generare un segmentation fault, in quanto sto tentando di accedere a una memoria che non esiste. In questo caso poi il modulo sarebbe lockato in memoria, in quanto è bloccato dal kernel per tutta l'esecuzione dell'istruzione init_module().

A seguire il codice del dispatcher che gestisce la trap 0x80 all'interno del kernel 2.4. Ricordiamo che prima dell'esecuzione di questo codice il firmware ha già cambiato lo stack utilizzando il TSS e salvato nel nuovo stack varie informazioni sullo stato del processore.

      ENTRY(system_call) 
              push %eax            // Save orig_eax = sys_call_number
              SAVE_ALL             // Macro that saves all CPU registers on stack 
              GET_CURRENT(%ebx)

              testb $0x02, tsk_ptrace(%ebx)
              jne tracesys

              // vulnerable to speculative-execution attacks
              cmpl $(NR_syscalls), %eax
              jae badsys
              call *SYMBOL_NAME(sys_call_table)(, %eax, 4)
        
              movl %eax, EAX(%esp)

              ....

Notiamo in particolare la parte del codice vulnerabile ad attacchi di tipo speculativo: Il codice controlla il registro EAX con la taglia della system call. Se il numero è più grande della taglia, allora chiamata la routine badsys , altrimenti chiama la particolare routine indicizzando l'indirizzo base della syscall table tramite il registro EAX.

Utilizzando la fast system call path tramite l'istruzione syscall il firmware non fa più nulla, ed è solo il software che imposta la stack da far vedere alla system call. Nel fast system call path utilizziamo i model specific registers per passare il controllo a questo blocco di codice.

      ENTRY(system_call)

              swapgs

              // Parte del lavoro che prima veniva fatto dal firmware adesso
              // viene fatto dal software.
              movq %rsp, PDAREF(pda_oldrp)
              movq PDAREF(pda_kernelstack), %rsp
              sti
              SAVE_ARGS 8, 1
              movq %rax, ORIG_RAX-ARGOFFSET(%rsp)
              movq %rcx, RIP-ARGOFFSET(%rsp)
              GET_CURRENT(%rcx)
        
              testl $PT_TRACESYS, tsk_ptrace(%rcx)
              jne tracesys

              // vulnerable to speculative-execution attacks. 
              cmpq $__NR_syscall_max, %rax
              ja badsys

              movq %r10, %rcx
              call *sys_call_table(, %rax, 8)
        
              movq  %rax, RAX-ARGOFFSET(%rsp)
              .globl ret_from_sys_call

              ...

Nelle vecchie versioni del kernel per eseguire una system call si andava a comparare il valore contenuto nel registro RAX con il numero massimo delle system call, e a seconda del risultato si andare a chiamare una particolare routine.

Come abbiamo già trattato nel primo modulo del corso, codice del genere è molto vulnerabile alla speculatività dell'hardware. È stato dunque necessario rendere il codice del dispatcher più sicuro.

Nel kernel 4.xx questo problema è stato sistemato. In particolare è stato introdotto un ulteriore dispatcher che non fa altro che controllare il valore nel registro RAX e impone che il suo valore sia all'interno dello schema di indicizzazione prima di chiamare le funzioni.

// Taken from
// https://github.com/torvalds/linux/blob/master/arch/x86/entry/common.c
__visible noinstr void do_syscall_64(unsigned long nr, struct pt_regs *regs)
{
        nr = syscall_enter_from_user_mode(regs, nr);

        // ....
        
        instrumentation_begin();
        if (likely(nr < NR_syscalls)) {
                nr = array_index_nospec(nr, NR_syscalls);
                regs->ax = sys_call_table[nr](regs);
        }

        // ....         
}               

Tramite la system call getauxval() possiamo ottenere l'indirizzo in memoria in cui è situato il VDSO. Possiamo leggere questo oggetto tramite objdump.

#include <sys/auxv.h>

void *vdso = (uintptr_t) getauxval(AT_SYSINFO_EHDR);

Le applicazioni non devono preoccuparsi di utilizzare il vdso, in quanto queste facility offerte dal kernel vengono utilizzate dalla standard-C library.

In questo programma leggiamo 4 pagine di memoria che contengono codice messo a disposizione dal kernel nel vDSO. Possiamo leggere il contenuto di questa memoriza utilizzando objdump.

gcc vdso.c ./a.out > vdso.bin objdump -D vdso.bin

La compilazione del kernel fa utilizzo della tecnologia dei Makefiles.

La system map contiene l'anatomia dell'immagine del kernel ottenuta dopo la compilazione. Nella system map sono presenti tutte le informazioni dei simboli presenti nella compile-time image del kernel.

Per ogni simbolo presente nella system è presente un indirizzo e un tag, che determina la sua "storage class" determinata dal processo di compilazione. Abbiamo varie storage classes, tra cui:

• 'T', denota una funzione globale (non-statica, ma non necessariamente exported);

• 't', denota una funzione locale (i.e. statica) relativa all'unità di compilazione.

• 'D', denota un dato globale.

• 'd', denota un dato locale.

• 'R', denota un dato globale che è read-only.

• 'r', denota un dato locale che è read-only.

Ricordiamo che dal kernel 4.8 di default è stato introdotta la kASLR. Se kASLR è attivato, le informazioni della system map sono inutili. In ogni caso è possibile disattivare kASLR andando ad inserire il comando nokaslr nella command line del kernel, accessibile tramite il bootloader (tipo grub).

In ogni caso, la system map è anche riportata parzialmente nello (pseudo) file /proc/kallsysm , che viene utilizzato per descrivere quali sono i simboli che i moduli nuovi possono utilizzare.