Rilevazione di malfunzionamenti nei device driver del kernel Linux

Transcript

1 tesi di laurea magistrale Rilevazione di malfunzionamenti nei device driver del Anno Accademico 2012/2013 relatore Chmo prof Domenico Cotroneo relatore Ing Roberto Natella correlatore Ing Francesco Fucci candidato Luigi De Simone Matr M

2 Contesto I Sistemi Operativi sono i componenti software più critici all'interno di un sistema di elaborazione: La perdita e/o la corruzione dei dati, insieme a periodi di inutilizzabilità dei servizi, può portare a costi di gestione elevatissimi (casi Amazon, Microsoft, Google) I difetti nei Device Driver sono la causa dominante di fallimenti nei sistemi operativi: In Windows XP l'85% dei crash è dovuto a difetti nei device driver [GGP06] La densità è dalle tre alle sette volte maggiore che nel resto dei componenti del kernel [CYC+01]

3 Problemi aperti Le tecniche esistenti di fault tolerance per device driver si limitano a proteggere i dati e il codice del kernel da accessi illeciti (fault( isolation) Tuttavia, le tecniche di fault isolation non possono evitare violazioni di protocollo nella comunicazione tra driver e dispositivo e tra driver e resto del kernel Uso scorretto dei registri e invio di dati non validi Sequenza scorretta di comandi inviati Ordine delle chiamate errato per le routine che gestiscono l'inizializzazione e la registrazione del dispositivo Per tollerare difetti nell'utilizzo del dispositivo, e prevenire corruzioni di dati, è necessaria la rilevazione tempestiva di violazioni del protocollo di comunicazione

4 Contributo tesi Analisi approfondita del sottosistema di I/O del, e degli standard di I/O più utilizzati per la gestione dei dischi (gli standard ATA, SATA e AHCI) Sviluppo di una strategia di monitoraggio a run-time per i driver del disco per la rilevazione di anomalie Generazione automatica delle regole di monitoraggio Utilizzabile su driver di terze parti (approccio black-box) Basso overhead Implementazione prototipale e validazione preliminare del monitor

5 Architettura di un driver AHCI/SATA (1/2) Software Hardware Struttura Struttura AHCI AHCI TAG FIS FIS ATA cmd TAG FIS FIS ATA cmd Command 0 Command 0 Command 31 Command 31 Port 0 Port 0 SACT Register CI SACT Register Register CI Register Port 31 Port 31 I/O ops Kernel Kernel I/O subsystem VFS VFS Block Block Layer Layer request notification Driver Driver AHCI AHCI commands interrupts PCI bus Controller Controller AHCI AHCI (HBA) (HBA) ABAR ABAR REGISTRI AHCI REGISTRI AHCI IRQ IRQ FRAME FRAME SATA bus FRAME FRAME SATA disk SATA disk

6 Architettura di un driver AHCI/SATA (2/2) Accoda comando SCSI verso LLD: ata_scsi_queuecmd () Block Block Layer Layer Driver Driver stack stack Descrizione comando accodato: struct ata_queued_cmd { struct ata_port *ap; struct ata_device *dev; struct ata_taskfile *tf; unsigned int tag; unsigned long flags; }; Notifica completamento comando ATA allo SCSI subsystem: ata_scsi_qc_complete () LibATA LibATA AHCI Host driver AHCI Host driver (PCI Device driver) (PCI Device driver) PCI Core driver PCI Core driver Controller Controller AHCI AHCI PCI Bus SATA bus SATA disk SATA disk Inizializzazione e registrazione del driver: static int ahci_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) { return ata_host_activate (host, pdev->irq, ahci_interrupt, IRQF_SHARED, &ahci_sht); } Invio di un comando verso il dispositivo: ahci_qc_issue ()

7 Approccio proposto Device Device Driver Driver Trace Trace Collection Collection Phase Phase Concrete Log State State Abstraction Abstraction Phase Phase Abstract Log FSM FSM Model Model Generation Generation Phase Phase Monitor Monitor Generation Generation Phase Phase FSM Behavioral Model Monitor Trace Collection Phase: raccolta di tracce di esecuzione fault-free del driver State Abstraction Phase: astrazione delle tracce, sostituendo valori di stato concreti con delle etichette FSM Model Generator: creazione di un modello comportamentale del driver, rappresentato con una FSM Monitor Generator: generazione automatica di un componente di monitoraggio basato sul modello

8 Trace Collection Phase Utilizzo di probe per intercettare l'esecuzione delle funzioni di interfaccia ahci_qc_issue e ata_scsi_qc_complete Raccolta di variabili di stato AHCI fondamentali per la gestione del dispositivo Formato del log: [timestamp],[processo],[funzione],[p1;p2;;pn],[tipo evento] Variabili di interesse: [PxSACT; PxCI; QC_FLAGS; PROTOCOL; COMMAND_TYPE; TAG]

9 Astrazione del log Applicazione di regole per astrarre i valori dello stato corrente del driver: { QC NOT ACTIVE, QC SCSI COMPLETE, QC ACTIVE } { ATA_PROT_UNKNOWN, ATA_PROT_NODATA, ATA_PROT_PIO, ATA_PROT_DMA, ATA_PROT_NCQ, ATAPI_PROT_NODATA, ATAPI_PROT_PIO, ATAPI_PROT_DMA } { NCQ COMMAND ISSUE, NON-NCQ COMMAND ISSUED, - } { ID_ATA, FPDMA_READ FPDMA_WRITE, FLUSH_EXT, PACKET, SMART, CHK_POWER, }

10 Generazione del modello e del monitor Applicando l'approccio su un disco SATA/AHCI Seagate: 80 nodi 30 transizioni Un modulo kernel di monitoraggio (basato su probe alle interfacce del driver) confronta a run-time il comportamento del driver con il modello

11 Risultati sperimentali (1/2) Test del corretto funzionamento del monitor tramite iniezione di difetti nel codice del driver: libahcic:1803 writel (1 << qc->tag, port_mmio + PORT_SACT); CODICE ORIGINARIO writel (0, port_mmio + PORT_SACT); CODICE CON DIFETTO

12 Risultati sperimentali (2/2) Test dell'overhead utilizzando workload basato su MySQL

13 Conclusioni e sviluppi futuri Conclusioni L'approccio proposto permette di creare un monitor in grado di rilevare anomalie dovute a violazioni di protocollo driver-dispositivo Sviluppi Futuri Estendere il monitoraggio ad altri registri e strutture dati gestiti dal driver Utilizzo del monitor per diversi dispositivi e per diversi driver della stessa classe o di altre classi Analisi rigorosa dei falsi positivi e falsi negativi utilizzando workload e faultload realistici