AOS - 21 - LINUX MODULES II

La struttura dati principale per effettuare il probing è la struct kprobe , definita in <linux/kprobes.h> . A partire dal kernel 3 c'è stata una modifica alla struttura:

• Kernel < 3

  struct kprobe
  {
    // ...
    kprobe_opcode_t addr; // Address of probe
    // ...
    const char *symbol_name; // probed function name
    kprobe_pre_handler_t pre_handler; // Addr of pre-handler
    kprobe_post_handler_t post_handler; // Addr of post-handler
    // ...
  };
  

• A partire dal kernel 3 si è poi introdotta la possibilità di aggiungere più kprobes ad una data funzione.

  struct kprobe
  {
    struct hlist_node hlist;
  
    // list of kprobes for multi-handler support
    struct list_head list;
  
    // count number of times this probe was temporarily disarmed
    unsigned long nmissed;
  
    // ....
    // ....
  };
  

Il sistema di kprobing permette di definire tre tipologie di handler, che sono

• kprobe_pre_handler(): La struct pt_regs può anche essere modificata. Possiamo quindi modificare lo stato dei registri prima di eseguire la funzione di interesse.

  typedef int (*kprobe_pre_handler t) (struct kprobe*, struct pt_regs*);
  

• kprobe_post_handler(): Per il post-handler i valori salvati in pt_regs rappresentano lo snapshot dei valori nei registri nel momento in cui la funzione di interesse esce.

  typedef int (*kprobe_post_handler t) (struct kprobe*, struct pt_regs*, unsigned long flags);
  

• kprobe_fault_handler(): Utilizzato per specificare come gestire eventuali fault all'interno del pre-handler o post-handler. I fault generati all'interno della funzione instrumentalizzata vengono gestiti come prima.

  typedef int (*kprobe_fault_handler t) (struct kprobe*, struct pt_regs*, int trapnr);
  

• kretprobe_handler(): Utilizzato nel caso in cui registriamo una kretprobe.

  typedef int (*kretprobe_handler t) (struct kretprobe_instance*, struct pt_regs *);
  

Notiamo che sia al pre-handler che al post-handler il kernel passa in input alla funzione lo stato dei registri del processore. Per il pre-handler, il valore dei registri contenuto in pt_regs rappresenta lo stato dei registri nel momento in cui è stata chiamata la INT 0x03 .

Non tutte le funzioni del kernel possono essere strumentalizzate attraverso il meccanismo di kprobing. Le funzioni del kernel che sono "blacklisted" sono inserite nel file

/sys/kernel/debug/kprobes/blacklist

Ci sono varie ragioni che possono portare una funzione ad essere "blacklisted", tra cui:

1. in-line functions;

2. functions that are indirectly triggered by probe executions, such as the page fault handler.

Opera in modo molto simile alla più nota printf() , ma printk() non può ricevere floating point values. La format string che prende in input può contenere delle macro che specificano la criticità del messaggio da loggare.

Per garantire una semantica exactly-once la stampa dei messaggi nella console viene effettuata in modo sincrono. In particolare la printk() non ritorna il controllo fino a quando il messaggio è consegnato al device-driver di interesse.

Una volta eseguita, oltre a loggare il messaggio di interesse, va anche a verificare se il thread che ha chiamato la funzione deve rilasciare la CPU. Questo significa che chiamare la printk() ci potrebbe far perdere il controllo della CPU.

Le macro per specificare i livelli di priorità sono definiti nel file include/linux/kernel.h , e sono

• KERN_EMERG: System unstable

  #define KERN_EMERG "<0>"      
  

• KERN_ALERT: Action must be taken immediately

  #define KERN_ALERT "<1>"      
  

• KERN_CRIT: Critical conditions

  #define KERN_CRIT "<2>"       
  

• KERN_ERR: Error conditions

  #define KERN_ERR "<3>" 
  

• KERN_WARNING: Warning conditions

  #define KERN_WARNING "<4>"
  

• KERN_NOTICE: Normal but significant condition

  #define KERN_NOTICE "<5>" 
  

• KERN_INFO: Informational

  #define KERN_INFO "<6>" 
  

• KERN_DEBUG: Debug-levle messages

  #define KERN_DEBUG "<7>"
  

Segue un esempio di utilizzo

printk(KERN_WARNING "message to print")

Esistono poi delle funzioni che chiamano printk con uno specifico livello di priorità come la pr_emerg o pr_alert o pr_crit .

Esistono quattro parametri configurabili per il sistema dei messaggi. Questi parametri possono essere trovati e modificato nella cartella

/sys/modules/printk/parameters

e sono:

• console_loglevel: Livello che specifica la soglia per andare a loggare i messaggi in console. In particolare tutti i messaggi con livello < di console_loglevel vengono loggati in console oltre ad andare sul buffer circolare.

• default_message_loglevel: Livello di priorità associato automaticamente ai messaggi che non esplicitano il loro livello di priorità.

• minimum_console_loglevel: livello minimo per accettare i messaggi del log nella console.

• default_console_loglevel: livello di default per i messaggi destinati ad andare nella console.

La system call syslog() è l'unica che ci permette di leggere i messaggi all'interno del buffer circolare.

int syslog(int type, char *bufp, int len);

A seconda del valore di 'type' possiamo effettuare azioni diverse. Tra le possibili azioni troviamo le seguenti

• SYSLOG_ACTION_CLOSE:

• SYSLOG_ACTION_OPEN:

• SYSLOG_ACTION_READ:

• ...

• SYSLOG_ACTION_SIZE_UNREAD:

• SYSLOG_ACTION_SIZE_BUFFER:

Periodicamente esiste un kernel demon, klogd , che intercetta e logga i messagi del kernel.

In questo esempio andiamo prima a compilare e caricare in memoria il modulo kprobe-usage-example

cd kprobe-usage-example
make 
sudo insmod hook.ko

subito dopo compilamo e carichiamo in memoria il modulo kernel-function-pointer-exhibition

cd ..
cd kernel-function-pointer-exhibition
make
sudo insmod function_pointer_exposer.ko

Infine, eseguiamo

cat /sys/module/function_pointer_exposer/parameters/the_hook > /sys/module/hook/parameters/hook_func

In questo esempio andiamo a vedere un modulo che intercetta le chiamate alla sys_read() .

Definiamo quindi i seguenti parametri

#define target_func "sys_read"

// show how manu times the interceptor function has been called
unsigned long audit_counter = 0; called
module_param(audit_counter, ulong, S_IRUSR | S_IRGRP | S_IROTH);

// the target process id - setup it via /sys
long target_pid = -1;
module_param(target_pid, long, S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH);

La funzione che si occupa di intercettare la read invece è la seguente

static int the_hook(struct kprobe *ri, struct pt_regs *regs)
{
  char buffer[128];
  int string_terminator;
  int i;

  atomic_int((atomic_t)&audit_counter);

  if(current->pid == (pid_t)target_pid) {
    printk("process %d read - channel is %d - address is %p - requested num bytes is %d\n",
           (int)target_pid, regs->di, (void*)regs->si, regs->dx);

    if(regs->di != 0) return 0;

    // take the already delivered bytes back from user space. 
    copy_from_user((void*) buffer, (char*)regs->si, regs->dx);

    // format correct string
    string_terminator = regs->dx;
    if(string_terminator >= 128) string_terminator = 128;
    buffer[string_terminator] = '\0';

    // KERN_CONT is used for line continuation
    printk(KERN_CONT "buffer content is: ");

    i = 0;
    while(buffer[i] != '\n' && buffer[i] != '\0') {
      printk(KERN_CONT "%c", buffer[i++]);
    }
    printk("\n");
  }

  return 0;
}

La funzione di init, come al solito, si occupa di registrare il kprobe

static struct kprobe kp = {
  .symbol_name = target_func,
  .post_handler = (kprobe_post_handler_t)the_hook,
};

static int hook_init(void)
{
  int ret;

  ret = register_kprobe(&kb);
  if(ret < 0) {
    // TODO: understand pr_info
    pr_info("hook init failed, returned %d\n", ret);
    return ret;
  }
  
  printk("hook module correctly loaded\n");
  return 0;
}

Mentre quella di exit si occupa di eliminare il kprobe registrato.

static void hook_exit(void)
{
  unregister_kprobe(&kp);
  printk("Hook invoked %lu times\n", audit_counter);
  printk("hook module unloaded\n");
}

Infine, le solite macro

module_init(hook_init);
module_exit(hook_exit);