Christian Hirsch Mai 2016

Transkript

1 1 OSUE OSUE basierend auf Slides von Bernhard Frömel - Institut für Technische Informatik Technische Universität Wien Betriebssysteme UE SS16 Mai 2016

2 2 OSUE Motivation Linux ist erweiterbar beispielsweise per Einbindung von HW: Digital Video Broadcasting (DVB) PCI card, IP over Satellite (LCD) Displays: echo Hello World! > /dev/disp

3 Überblick e und Device Drivers Build Prozess Character Devices Übungsumgebung Bonus Beispiel 3

4 4 OSUE Der Linux Appplication vs. Teil I e und Device Drivers Device Drivers

5 Der Linux Appplication vs. Device Drivers 5

6 Der Linux Komplexizität vs Fehler Wenn Bugs auftreten, dann oft trotzdem schwer zu beheben Appplication vs. Device Drivers item&px=mtg1mdc /01/08/closure-nasty-bug/ 6

7 Allgemeines ist monolithisch (gesamtes OS im Ring 0) Der Linux Appplication vs. Device Drivers Loadable e (LKM) Unterstützung erweitern den um zusätzliche Funktionalität entwickeln, laden und entfernen von en zur System-Laufzeit insbesondere gut geeignet für Device Drivers (Gerätetreiber) nur benötigte Treiber zu tatsächlich vorhandenen Geräten werden geladen vereinfachte Entwicklung (kein Reboot erforderlich) e Stacking, d.h. aufeinander aufbauende e, möglich (modprobe(3)) 7

8 A split view of the kernel The System Call Interface Der Linux Process management Memory management Filesystems Device control Networking subsystems Appplication vs. Device Drivers Concurrency, multitasking Archdependent code Virtual memory Memory manager Files and dirs: the VFS File system types Block devices Ttys & device access Character devices Connectivity Network subsystem IF drivers Features implemented Software support Hardware CPU Memory Disks & CDs Consoles, etc. Network interfaces features implemented as modules 8

9 Der Linux Appplication vs. Device Drivers (1) e sind immer serviceorientiert: Beim Ladevorgang einhängen in strukturen, bzw. Bekanntmachung, welche Services angeboten werden Danach nur noch Bearbeitung von Requests Keine externen Bibliotheken (insb. keine libc!), aber viele bekannte Funktionen trotzdem vertreten Formatierten String ausgeben: printk (linux/kernel.h) linux/string.h: strcpy, strcat, memset,... Limitierte Stackgröße: 8 KByte 9

10 Der Linux Appplication vs. Device Drivers (2) Gleichzeitigkeit (Concurrency) beachten! Sequentieller Code kann immer unterbrochen werden (schon beim Laden des s! > e Loading Races ) Scheduling/Preemption Interrupts (e.g., kernel timers) Symmetric Multi Prozessor (SMP) auf saubere Synchronisation bei shared resources (globale Variablen, Devices,...) achten! manuelle Freigabe von Ressourcen notwendig: kein Garbage Collector - auch nicht bei entfernung per rmmod(8)! Portabilität wichtig: keine Annahmen über Seiten- und Wortgröße, Endianess,... treffen. 10

11 11 OSUE (Userspace) Applikation vs. Der Linux Appplication vs. Device Drivers Kriterium Applikation Funktion task/serviceorientiert nur serviceorientiert Parameter argv Mod. Parameter Entry Point main Funktion module_init Exit Point beliebig module_exit Bibliotheken System (libc, libm,...) nur Stack Größe MByte KByte Floating Point ja nein (CPU context) Zugriffsverletz. Segmentation Fault Fault Res. Freigabe Termination keine/neustart Sprache beliebig GNU C (C99 Std)

12 Der Linux (Userspace) Applikation oder? Rule of thumb : Alles was im Userspace einfacher implementierbar ist, sollte im Userspace implementiert werden. Fails: Band netcat veröffentlicht Album als 1 Appplication vs. Device Drivers Their music sounds like one of those sleep CDs.. Charliemopps, Slashdot

13 Device Drivers (1) Der Linux Appplication vs. Device Drivers Gerät wird hinter wohldefiniertem Programmierinterface abstrahiert (File in /dev/, Ausnahme: Netzwerkgeräte in Linux nicht unter /dev/ auffindbar) Policy vs. Mechanism: Treiber soll keine (möglichst wenige) Regeln/Richtlinien bezüglich seiner Verwendung dem User aufzwingen die gesamte (möglichst komplette) Hardwarefunktionalität anbieten Hauptklassen von Device Treibern Character Device (Stream) Block Device (Blocks) Network Device (Packets) Einteilung nach Subsystem: USB, SCSI, Firewire,... 13

14 14 OSUE Security Der Linux Appplication vs. Device Drivers hat max. Rechte im System, d.h. Sicherheitsprobleme im bedeuten Sicherheitsprobleme im System typische Security-Bugs: Bufferoverflows Information-Leakage Unchecked User-Input

15 Der Linux Appplication vs. Device Drivers Lizenzierung Linux lizenziert unter Version 2 der General Public License (GPL) 2 Deklarierung der Lizenz per MODULE_LICENSE Makro Proprietäre e (d.h. e die nicht GPLv2 kompatibel lizenziert sind) im toleriert Proprietäre e erhalten aber nicht das komplette API, Umgehungstaktiken: Linuxant: MODULE_LICENSE( "GPL\0 for f i l e s in the \"GPL\" directory ; for others, only LICENSE f i l e applies " ) ; Nvidia: open-source glue code, proprietärer Treibercode im closed source binary-blob 2 Free vs Open Source, R. Stallman, 15

16 Setup Beispiel Teil II Build Prozess 16

17 17 OSUE Setup Beispiel Quellen Quellen enthalten neben dem selbst Build System basierend auf Unix Make, > <kernel_source>/documentation/kbuild Interfaces für User-Space Applikationen und e (Header Files) Unterstützung für zahlreiche Architekturen Device Driver Archiv: configured -tree passend zum Laufzeitkernel (uname -a) um gebautes e laden zu können oft erhältlich als Package in Distributionen (linux-headers-...) (Symlink /usr/src/linux sollte auf quellen verweisen) Devel- & Testsystem (e.g. Virtual Machine,... ) sinnvoll

18 Setup Beispiel Compilieren eigener e out-of-tree Builds möglich dabei Makefile two-faced Bei Ausführung im quellverzeichnis: Wechsel in Source Directory und Ausführung des eigentlichen Makefiles um das zu übersetzen $(MAKE) -C $(KERNELDIR) M=$(PWD) modules Bei -Build Einbindung: wird zu Makefilefragment, das die gesamte Compile-Info für -Build Vorgang enthält obj-m := cmod1.o cmod2.o... Laden und Entfernen von en per insmod(8) und rmmod(8) als Superuser ( root ) zur Laufzeit möglich aktuelle Liste der geladenen e: lsmod(8) 18

19 19 OSUE Hello World, Makefile Setup Beispiel % (for kernel build) obj-m := hello_world.o % (for module build) KERNELDIR = /usr/src/linux all: modules modules modules_install clean: $(MAKE) V=1 ARCH=um -C ${KERNELDIR} M=$(PWD) $@

20 Setup Beispiel Hello World, hello_world.c #include <linux/init.h> #include <linux/module.h> MODULE_LICENSE("GPL"); static int mod_init(void) { printk(kern_alert "Hello World!\n"); return 0; } static void mod_exit(void) { printk(kern_alert "Bye World!\n"); } module_init(mod_init); module_exit(mod_exit); 20

21 21 OSUE Character Devices File Operationen space Lifecycle Teil III Character Devices

22 22 OSUE Character Devices Character Devices File Operationen space Lifecycle zeichenorientierte Geräte, die sich wie Files verhalten z.b. Maus, Keyboard, Serial,... implementieren meist open, close, read und write File Operationen oft nur sequentiell les/schreibbar (z.b. /dev/ttys0)

23 Major/Minor Number Character Devices File Operationen space Lifecycle Special File (mknod(1)) in /dev/ referenziert Device per Typ, Major und Minor Device Number Dynamische Anforderung (alloc_chrdev_region) od. statische Zuweisung (register_chrdev_region) möglich verwaltet Character Devices in struct cdev, die als Member struct file_operations enthält. Dabei ist struct inode die -interne Repräsentation einer Datei, und struct file die eines offenen Dateideskriptors 23

24 24 OSUE Character Devices File Operationen space Lifecycle File Operationen struct file_operations (linux/fs.h) enthält Function Pointer als Members: z.b. int (*open)(struct inode *,struct file *); int (*release) (struct inode *, struct file *); int (*unlocked_ioctl) (struct inode *, struct file *, unsigned int, unsigned long); (ioctl vs. unlocked_ioctl: ssize_t (*read) (struct file *, char user *, size_t, loff_t *); ssize_t (*write) (struct file *, const char user *, size_t, loff_t *); loff_t (*llseek) (struct file *, loff_t, int);

25 Character Devices File Operationen space Lifecycle File Operationen Device Treiber kann Default-Verhalten der File Operationen überschreiben Funktionen werden bei den jeweiligen Operationen (vom Userspace) auf das Character Device aufgerufen Ausführung im space, im Kontext des aufrufenden Userspace Prozesses Setzen des struct module *owner Members wichtig, sodass nicht aus System entfernt werden kann, solange File Operationen ausgeführt werden. struct file_operations my_fops = {.owner = THIS_MODULE,.open = my_open,.release = my_release,.unlocked_ioctl = my_ioctl,.read = my_read,.write = my_write,.llseek = my_llseek, }; 25

26 Character Devices File Operationen space Lifecycle open struct my_dev { struct cdev cdev; /* other members needed for device */ }; int my_open(struct inode *inode, struct file *filp) { struct my_dev *dev; dev = container_of(inode->i_cdev, struct my_dev, cdev); filp->private_data = dev; return 0; } indoe->i_cdev Zeiger auf cdev Member von struct my_dev container_of: 26

27 Character Devices the file structure when appropriate. The pread and pwrite system calls have different semantics, however; they operate from a given file offset and do not change the read/write file position as seen by any other system calls. These calls pass in a pointer to the user-supplied position, and discard the changes that your driver makes. Figure 3-2 represents how a typical read implementation uses its arguments. ssize_t dev_read(struct file *file, char *buf, size_t count, loff_t *ppos); File Operationen space Lifecycle struct file f_count f_flags f_mode f_pos Buffer (in the driver) copy_to_user() Buffer (in the application or libc) Space (nonswappable) User Space (swappable) Figure 3-2. The arguments to read Both the read and write methods return a negative value if an error occurs. A return value greater than or equal to 0, instead, tells the calling program how many bytes have been successfully transferred. If some data is transferred correctly and then an 27

28 Character Devices File Operationen space Lifecycle Synchronisation Zugriff auf shared resources muss synchronisiert werden Semaphoren Initialisierung: sema_init(struct semaphore *, int); P Operation: z.b. int down_interruptible(struct semaphore *); V Operation: z.b. void up(struct semaphore *); Als Mutex: Schutz eines kritischen Abschnitts, Initialisierung mit 1 Prozess wird u.u. geblockt (nicht geeignet für Interrupthandler) Spinlocks Deaktiviert Interrupts, Busy Waiting (Multiprozessor) Kann in Interruptbehandlungsroutinen verwendet werden atomic_* Funktionen: z.b. void atomic_inc(atomic_t *v); 28

29 29 OSUE Speichermanagement Character Devices File Operationen space Lifecycle Speicherverwaltung sehr flexibel unter Linux (siehe LDD3, Chapter 8: page-oriented, vmalloc, caches, pools,... ); für die meisten Fälle geeignet: Speicher anfordern: void *kmalloc(size_t, int); Speicher freigeben: void kfree(void *ptr); angeforderter Speicher nicht initialisiert (kann beliebigen Inhalt haben) freigegebener Speicher wird nicht automatisch gelöscht int *data = kmalloc(data_size, GFP_KERNEL); /* Fehlerbehandlung und Verwendung von angefordertem Speicher */ kfree(data);

30 Character Devices File Operationen space Lifecycle Datenaustausch space <-> Userspace Oft notwendig Bufferinhalte vom -Space in den User-Space und umgekehrt zu transferieren: Niemals ungeprüfte Pointer im dereferenzieren! copy to/from user Interface (asm/uaccess.h) nutzen: unsigned long copy_to_user(void user *to, const void *from, unsigned long count); unsigned long copy_from_user(void *to, const void user *from, unsigned long count); wie memcpy, zusätzlich: Prüfung des User-Space Pointers Rückgabe enthält Anzahl der nicht kopierten Bytes (d.h. wenn nicht 0 > Fehler). Kopieroperationen können jederzeit unterbrochen werden (Concurrency!) z.b. angeforderte Page nicht im Hauptspeicher 30

31 Lifecycle eines Character Devices Character Devices File Operationen space Lifecycle Initialisierung Registrierung/Allozierung der Character Device Region: register_chrdev_region Initialisierung der Character Device Struktur struct cdev (inkl. struct file_operations): cdev_init Registrierung des Character Devices im : cdev_add Bemerkung: Ab diesem Zeitpunkt muss damit gerechnet werden, dass das Device verwendet wird - auch wenn die module_init Funktion noch nicht fertig ist! Entfernung Deregistrierung des Character Devices: cdev_del Deregistrierung der Character Device Region: unregister_chrdev_region 31

32 Übungsumgebung Org Angabe LDD3 vs Teil IV Ausblick und Quellen 32

33 Übungsumgebung Org Angabe LDD3 vs Ausblick und Quellen Übungsumgebung 4.0.2, Debian 8, Jessie User Mode Linux (UML) Umgebung im TI-Lab installiert Read-only Base Image (gross) /opt/osue/uml/osue_bonus.umldisk Overlay im Homedirectory (nur Änderungen zum Base Image): ~/.uml.cow virtuelle Maschine: Linux wird als User-Prozess ausgeführt (Architektur um) sichere Umgebung für riskantes (und rasches) Entwickeln Interaktion mit Host per hostfs Filesystem (z.b. Home-Directory kann gemountet werden) Interaktion mit User über Pseudo Terminals in /dev/pts/ (z.b. per screen(1) verwendbar) weitere Details: siehe Angabe (im myti) 33

34 Übungsumgebung Org Angabe LDD3 vs Ausblick und Quellen Organisatorisches Selbststudium: Linux Device Drivers 3rd Edition (LDD3) - zumindest Kapitel 1 bis 3, 5 (Semaphoren) Richtlinien: Beispielabnahme ausschliesslich auf TI-Lab Umgebung GNU C Standard, i.e. C99 Std. mit GNU Erweiterungen (statt C89 Standard und gegebenen CFLAGS für alle anderen Beispiele) debug Parameter (siehe Angabe) Coding Style: /usr/src/linux/documentation/codingstyle Synchronisation Sauberes Unloading (keine Resourceleaks!) Abgabedeadline: :59 Abgabegespräche (bei Bedarf ), Anmeldung via myti, TI Labor Beginn: ab sofort 34

35 : Secvault - Übersicht Übungsumgebung Org Angabe LDD3 vs Ausblick und Quellen Character Device Driver soll als implementiert werden Verwaltung von bis zu 4 Secure Vaults (Secvaults) Größe zwischen 1 Byte und 1 MByte (konfigurierbar) verschlüsselt nach XOR Verfahren Userspace Tool: svctl anlegen und entfernen von Secvaults Löschung (gesamten Speicher mit 0x0 überschreiben) eines Secvaults. 35

36 Ablauf Übungsumgebung Org Angabe LDD3 vs Ausblick und Quellen Einmaliges Anlegen der notwendigen Special Files per mknod(1): /dev/sv_ctl, /dev/sv_data0, /dev/sv_data1, /dev/sv_data2, /dev/sv_data3 stellt nach dem Laden Control Character Device (/dev/sv_ctl) zur Verfügung Userspace Tool svctl kommuniziert per IOCTL Calls mit Control Device (/dev/sv_ctl) des Treibers Anlegen, Löschen (mit 0x0 überschreiben) und Entfernen eines Secvaults liest Schlüssel über stdin (bis zu 10 Byte, wenn weniger: 0x0). 36

37 Anlegen Übungsumgebung Org Angabe LDD3 vs Ausblick und Quellen Überprüfung, ob Secvault schon existiert, falls ja > Fehler sonst: Erzeugung eines neuen Character Devices angeforderten Speicher reservieren Schlüssel zum Secvault speichern 37

38 Lesen/Schreiben/Löschen/Entfernen Übungsumgebung Org Angabe LDD3 vs Ausblick und Quellen Beim Lesen/Schreiben *): Anwendung des symmetrischen Verchlüsselungsverfahren XOR abhängig von Position crypt(pos, data, key) = data[pos] key[pos mod key size ] Wenn über Speichergrenze des Secvaults hinausgelesen/geschrieben wird: geeignete Fehlerbehandlung Löschanforderung: den gesamten Secvault mit 0x0 überschreiben (Operation innerhalb des s!) Entfernung: Speicher- und Characterdevicefreigabe *) *) hier kann auch überprüft werden, ob der Benutzer berechtigt ist (siehe Fragen in Angabe) 38

39 Secvaults Relevanz? Übungsumgebung Org Angabe LDD3 vs Ausblick und Quellen 39

40 Unterschiede LDD3 und Linux Übungsumgebung Org Angabe LDD3 vs Ausblick und Quellen LDD3 für API Changes: zb: LDD ioctl unlocked_ioctl init_mutex(&mutex) sema_init(&mutex, 1) current->uid current_uid() uid_t kuid_t uid_a == uid_b uid_eq(uid_a, uid_b) Weitere Änderungen? > mailto:christian.hirsch@tuwien.ac.at 40

41 Ausblick Übungsumgebung Org Angabe LDD3 vs Ausblick und Quellen Letzte Vorlesung! Lust auf mehr Entwicklung? Talk: Write and Submit your first Linux kernel Patch 3 Newbies 4 Lust auf Konzepte/Design zwischen Hardware and Userspace Software? Programmierung von Betriebssystemen (ProgOS) Live Demo (Sommersemester)

42 Quellen und Material Übungsumgebung Org Angabe LDD3 vs Ausblick und Quellen Linux Device Drivers 3rd Edition (LDD3) von Jonathan Corbet, Alessandro Rubini, and Greg Kroah-Hartman Development 2nd Edition von Robert Love Development/ /toc.html Comic : Ramdump setup: neimod, 3ds scene Protection rings figure: 42