OSUELinux Kernel
ModulBonusbeispiel
Frömel
OSUELinux Kernel Modul Bonusbeispiel
Bernhard Frömel <[email protected]>
Institut für Technische InformatikTechnische Universität Wien
-182.709 Betriebssysteme UE
SS15
Mai 2015
1/41
OSUELinux Kernel
ModulBonusbeispiel
Frömel
MotivationLinux ist erweiterbar – beispielsweise per Einbindung von HW:
I Digital Video Broadcasting (DVB) PCI card, IP over Satellite
I Time-Triggered Ethernet, Time-Triggered System-on-ChipFrontend
I Apple MacBook Pro Retina, apple-gmux1
1https://groups.google.com/forum/#!topic/linux.kernel/rlC-NG3Yv3Q
2/41
OSUELinux Kernel
ModulBonusbeispiel
Frömel
Überblick
I Kernel Module und Device Drivers
I Kernel Modul Build Prozess
I Character Devices
I Übungsumgebung
I Bonus Beispiel
3/41
OSUELinux Kernel
ModulBonusbeispiel
Frömel
Der LinuxKernel
KernelModul
Appplicationvs. KernelModul
DeviceDrivers
Teil I
Kernel Module und Device Drivers
4/41
OSUELinux Kernel
ModulBonusbeispiel
Frömel
Der LinuxKernel
KernelModul
Appplicationvs. KernelModul
DeviceDrivers
Quelle: http://www.makelinux.net/kernel_map5/41
OSUELinux Kernel
ModulBonusbeispiel
Frömel
Der LinuxKernel
KernelModul
Appplicationvs. KernelModul
DeviceDrivers
Komplexizität vs Fehler
Wenn Bugs auftreten, dann oft trotzdem schwer zu beheben
http://www.phoronix.com/scan.php?page=news_item&px=MTg1MDc http://codemonkey.org.uk/2015/01/08/closure-nasty-bug/
6/41
OSUELinux Kernel
ModulBonusbeispiel
Frömel
Der LinuxKernel
KernelModul
Appplicationvs. KernelModul
DeviceDrivers
Allgemeines
I Linux Kernel ist monolithisch (dh. Kernel und Treiber inRing 0)
I Loadable Kernel Module (LKM) UnterstützungI erweitern den Kernel um zusätzliche FunktionalitätI entwickeln, laden und entfernen von Modulen zur
System-LaufzeitI insbesondere gut geeignet für Device Drivers
(Gerätetreiber)I nur benötigte Treiber zu tatsächlich vorhandenen Geräten
werden geladenI vereinfachte Entwicklung (kein Reboot erforderlich)
I ”Module Stacking”, d.h. aufeinander aufbauende Module,möglich (modprobe(3))
7/41
OSUELinux Kernel
ModulBonusbeispiel
Frömel
Der LinuxKernel
KernelModul
Appplicationvs. KernelModul
DeviceDrivers
A split view of the kernel
This is the Title of the Book, eMatter EditionCopyright © 2005 O’Reilly & Associates, Inc. All rights reserved.
6 | Chapter 1: An Introduction to Device Drivers
The three classes are:
Character devicesA character (char) device is one that can be accessed as a stream of bytes (like afile); a char driver is in charge of implementing this behavior. Such a driver usu-ally implements at least the open, close, read, and write system calls. The textconsole (/dev/console) and the serial ports (/dev/ttyS0 and friends) are examplesof char devices, as they are well represented by the stream abstraction. Chardevices are accessed by means of filesystem nodes, such as /dev/tty1 and /dev/lp0.The only relevant difference between a char device and a regular file is that youcan always move back and forth in the regular file, whereas most char devicesare just data channels, which you can only access sequentially. There exist,nonetheless, char devices that look like data areas, and you can move back andforth in them; for instance, this usually applies to frame grabbers, where theapplications can access the whole acquired image using mmap or lseek.
Figure 1-1. A split view of the kernel
features implemented as modules
Processmanagement
Memorymanagement
Filesystems Devicecontrol
Networking
Arch-dependent
code
Memorymanager
Characterdevices
Networksubsystem
CPU Memory
Concurrency,multitasking
Virtualmemory
Files and dirs:the VFS
Kernelsubsystems
Featuresimplemented
Softwaresupport
Hardware
IF driversBlock devices
File systemtypes
Ttys &device access Connectivity
Disks & CDs Consoles,etc.
Networkinterfaces
The System Call Interface
,ch01.2168 Page 6 Thursday, January 20, 2005 9:21 AM
8/41
OSUELinux Kernel
ModulBonusbeispiel
Frömel
Der LinuxKernel
KernelModul
Appplicationvs. KernelModul
DeviceDrivers
Kernel Modul (1)I Kernel Module sind immer
serviceorientiert:I Beim Ladevorgang
”einhängen” inKernelstrukturen, bzw.Bekanntmachung, welcheServices angeboten werden
I Danach nur noch Bearbeitungvon Requests
I Keine externen Bibliotheken(insb. keine libc!), aber viele”bekannte” Funktionen trotzdemvertreten
I Formatierten String ausgeben:printk (linux/kernel.h)
I linux/string.h: strcpy, strcat,memset, ...
I Limitierte Stackgröße: 4-8 KBytebei 32-bit, 16 Kbyte bei 64-bitx86 Architekturen
9/41
OSUELinux Kernel
ModulBonusbeispiel
Frömel
Der LinuxKernel
KernelModul
Appplicationvs. KernelModul
DeviceDrivers
Kernel Modul (2)
I Gleichzeitigkeit (Concurrency) beachten!I Sequentieller Code kann immer unterbrochen werden
(schon beim Laden des Moduls! –> ”Module LoadingRaces”)
I Scheduling/PreemptionI InterruptsI Symmetric Multi Prozessor (SMP)
I auf saubere Synchronisation bei shared resources (globaleVariablen, Devices, ...) achten!
I ”manuelle” Freigabe von Ressourcen notwendig: kein”Garbage Collector” - auch nicht bei Modulentfernung perrmmod(8)!
I Portabilität wichtig: keine Annahmen über Seiten- undWortgröße, Endianess, . . . treffen.
10/41
OSUELinux Kernel
ModulBonusbeispiel
Frömel
Der LinuxKernel
KernelModul
Appplicationvs. KernelModul
DeviceDrivers
(Userspace) Applikation vs. Kernel Modul
Kriterium Applikation Kernel Modul
Funktion task/serviceorientiert nur serviceorientiertParameter argv Mod. Parameter”Entry Point” main Funktion module_init”Exit Point” ”beliebig” module_exitBibliotheken System (libc, libm, ...) nur KernelStack Größe MByte KByteFloating Point ja nein (CPU context)Zugriffsverletz. Segmentation Fault Kernel FaultRes. Freigabe Termination keine/NeustartSprache ”beliebig” GNU C (C99 Std)
11/41
OSUELinux Kernel
ModulBonusbeispiel
Frömel
Der LinuxKernel
KernelModul
Appplicationvs. KernelModul
DeviceDrivers
(Userspace) Applikation oder Kernel Modul?’Rule of thumb’: Alles was im Userspace einfacherimplementierbar ist, sollte im Userspace implementiertwerden. Fails:
I Band ’netcat’ veröffentlicht Album als Linux Kernel Modul2
Their ”music” sounds like one of those sleep CDsyou hear them playing at incense shops that sellquartz ”power crystals” [..]
Charliemopps, SlashdotI fbrcapi: TCP Socket Client im Kernelspace . . .2http://entertainment.slashdot.org/story/14/04/23/2241209/band-
releases-album-as-linux-kernel-module12/41
OSUELinux Kernel
ModulBonusbeispiel
Frömel
Der LinuxKernel
KernelModul
Appplicationvs. KernelModul
DeviceDrivers
Device Drivers (1)
I Gerät wird hinter wohldefiniertem Programmierinterfaceabstrahiert (File in /dev/, Ausnahme: Netzwerkgeräte inLinux nicht unter /dev/ auffindbar)
I Policy vs. Mechanism: Treiber sollI keine (möglichst wenige) Regeln/Richtlinien bezüglich
seiner Verwendung dem User aufzwingenI die gesamte (möglichst komplette) Hardwarefunktionalität
anbieten
I Hauptklassen von Device TreibernI Character Device (Stream)I Block Device (Blocks)I Network Device (Packets)
I Einteilung nach Subsystem: USB, SCSI, Firewire, . . .
13/41
OSUELinux Kernel
ModulBonusbeispiel
Frömel
Der LinuxKernel
KernelModul
Appplicationvs. KernelModul
DeviceDrivers
Device Drivers (2)I Security
I Kernel hat ”max. Rechte” im System, d.h.Sicherheitsprobleme im Kernel bedeutenSicherheitsprobleme im System
I typische Security-Bugs:I BufferoverflowsI Information-LeakageI Unchecked User-Input
I LizenzierungI Linux lizenziert unter Version 2 der General Public License
(GPL)3
I Deklarierung der Lizenz per MODULE_LICENSE MakroI Proprietäre Module (d.h. Module die nicht GPLv2
kompatibel lizenziert sind) im Kernel ”toleriert”I Proprietäre Module erhalten aber nicht das komplette
Kernel API, Umgehungstaktiken:I Linuxant:
MODULE_LICENSE( "GPL\0 for f i l e s in the \"GPL\" di rectory ; for others ,only LICENSE f i l e applies " ) ;
I Nvidia: open-source glue code, proprietärer Treibercode imclosed source binary-blob
3Free vs Open Source, R. Stallman,https://www.youtube.com/watch?v=Ag1AKIl_2GM
14/41
OSUELinux Kernel
ModulBonusbeispiel
Frömel
Setup
Beispiel Teil II
Build Prozess
15/41
OSUELinux Kernel
ModulBonusbeispiel
Frömel
Setup
Beispiel
Kernel Quellen
I Kernel Quellen enthalten neben dem Kernel selbstI Build System basierend auf Unix Make,
–> <kernel_source>/Documentation/kbuildI Interfaces für User-Space Applikationen und Kernel Module
(Header Files)I zahlreiche Architekturen und Device Driver
I Linux Kernel Archiv: www.kernel.orgI ”configured” Kernel-tree passend zum Laufzeitkernel
(uname -a) um Module laden zu könnenI oft erhältlich als Package in Distributionen (”Kernel
Headers”)I Symlink /usr/src/linux sollte auf Kernelquellen verweisen
I Devel- & Testsystem (e.g. Virtual Machine, . . . ) sinnvoll
16/41
OSUELinux Kernel
ModulBonusbeispiel
Frömel
Setup
Beispiel
Compilieren eigener Kernel Module
I “out-of-tree” Builds möglichI dabei Makefile ”two-faced”
I Bei Ausführung im Modulquellverzeichnis: Wechsel inKernel Source Directory und Ausführung des eigentlichenKernel Makefiles um das Modul zu übersetzen
$(MAKE) -C $(KERNELDIR) M=$(PWD) modules
I Bei Kernel-Build Einbindung: wird zu Makefilefragment, dasdie gesamte Compile-Info für Kernel-Build Vorgang enthält
obj-m := cmod1.o cmod2.o ...
I Laden und Entfernen von Modulen per insmod(8) undrmmod(8) als Superuser (”root”) zur Laufzeit möglich
I aktuelle Liste der geladenen Module: lsmod(8)
17/41
OSUELinux Kernel
ModulBonusbeispiel
Frömel
Setup
Beispiel
Hello World Modul, ’Makefile’
% (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) $@
18/41
OSUELinux Kernel
ModulBonusbeispiel
Frömel
Setup
Beispiel
Hello World Modul, ’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);
19/41
OSUELinux Kernel
ModulBonusbeispiel
Frömel
CharacterDevices
FileOperationen
Kernelspace
Lifecycle
Teil III
Character Devices
20/41
OSUELinux Kernel
ModulBonusbeispiel
Frömel
CharacterDevices
FileOperationen
Kernelspace
Lifecycle
Character Devices
I zeichenorientierte Geräte, die sich wie Files verhalten z.B.Maus, Keyboard, Serial, ...
I implementieren meist open, close, read und write
I oft nur sequentiell les/schreibbar (z.B. /dev/ttyS0)
21/41
OSUELinux Kernel
ModulBonusbeispiel
Frömel
CharacterDevices
FileOperationen
Kernelspace
Lifecycle
Major/Minor Number
I Special File (mknod(1)) in /dev/ referenziert Device perTyp, Major und Minor Device Number
I Dynamische Anforderung (alloc_chrdev_region) od.statische Zuweisung (register_chrdev_region) möglich
I Kernel verwaltet Character Devices in struct cdev, dieals Member struct file_operations enthält.
I Dabei ist struct inode die Kernel-interneRepräsentation einer Datei, und struct file die einesoffenen Dateideskriptors
22/41
OSUELinux Kernel
ModulBonusbeispiel
Frömel
CharacterDevices
FileOperationen
Kernelspace
Lifecycle
File Operationen
I struct file_operations (linux/fs.h) enthältFunction 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:http://lwn.net/Articles/119652/)
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);
23/41
OSUELinux Kernel
ModulBonusbeispiel
Frömel
CharacterDevices
FileOperationen
Kernelspace
Lifecycle
File OperationenI Device Treiber kann Default-Verhalten der File
Operationen ”überschreiben”I Funktionen werden bei den jeweiligen Operationen (vom
Userspace) auf das Character Device aufgerufenI Ausführung im Kernelspace, im Kontext des aufrufenden
Userspace ProzessesI Setzen des struct module *owner Members wichtig,
sodass Modul 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,};
24/41
OSUELinux Kernel
ModulBonusbeispiel
Frömel
CharacterDevices
FileOperationen
Kernelspace
Lifecycle
openstruct my_dev{struct cdev cdev;/* other
members neededfor 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 vonstruct my_devcontainer_of:http://www.kroah.com/log/linux/container_of.html 25/41
OSUELinux Kernel
ModulBonusbeispiel
Frömel
CharacterDevices
FileOperationen
Kernelspace
Lifecycle
read/write
This is the Title of the Book, eMatter EditionCopyright © 2005 O’Reilly & Associates, Inc. All rights reserved.
read and write | 65
check the user-space pointer you can invoke __copy_to_user and __copy_from_userinstead. This is useful, for example, if you know you already checked the argument.Be careful, however; if, in fact, you do not check a user-space pointer that you pass tothese functions, then you can create kernel crashes and/or security holes.
As far as the actual device methods are concerned, the task of the read method is tocopy data from the device to user space (using copy_to_user), while the write methodmust copy data from user space to the device (using copy_from_user). Each read orwrite system call requests transfer of a specific number of bytes, but the driver is freeto transfer less data—the exact rules are slightly different for reading and writing andare described later in this chapter.
Whatever the amount of data the methods transfer, they should generally update thefile position at *offp to represent the current file position after successful comple-tion of the system call. The kernel then propagates the file position change back intothe file structure when appropriate. The pread and pwrite system calls have differ-ent semantics, however; they operate from a given file offset and do not change thefile position as seen by any other system calls. These calls pass in a pointer to theuser-supplied position, and discard the changes that your driver makes.
Figure 3-2 represents how a typical read implementation uses its arguments.
Both the read and write methods return a negative value if an error occurs. A returnvalue greater than or equal to 0, instead, tells the calling program how many byteshave been successfully transferred. If some data is transferred correctly and then anerror happens, the return value must be the count of bytes successfully transferred,
Figure 3-2. The arguments to read
Kernel Space(nonswappable)
struct fileBuffer
(in the driver)
User Space(swappable)
Buffer
(in theapplicationor libc)
f_countf_flagsf_mode
f_pos
....
....
copy_to_user()
ssize_t dev_read(struct file *file, char *buf, size_t count, loff_t *ppos);
,ch03.22228 Page 65 Friday, January 21, 2005 1:32 PM
26/41
OSUELinux Kernel
ModulBonusbeispiel
Frömel
CharacterDevices
FileOperationen
Kernelspace
Lifecycle
Synchronisation
I Zugriff auf shared resources muss synchronisiert werdenI Semaphoren
I Initialisierung:sema_init(struct semaphore *, int);
I P Operation: z.B.int down_interruptible(struct semaphore *);
I V Operation: z.B. void up(struct semaphore *);I Als Mutex: Schutz eines kritischen Abschnitts,
Initialisierung mit 1I Prozess wird u.U. geblockt (nicht geeignet für
Interrupthandler)
I SpinlocksI Deaktiviert Interrupts, Busy Waiting (Multiprozessor)I Kann in Interruptbehandlungsroutinen verwendet werden
I atomic_* Funktionen: z.B.void atomic_inc(atomic_t *v);
27/41
OSUELinux Kernel
ModulBonusbeispiel
Frömel
CharacterDevices
FileOperationen
Kernelspace
Lifecycle
Speichermanagement
I Speicherverwaltung sehr flexibel unter Linux (siehe LDD3,Chapter 8: page-oriented, vmalloc, caches, pools, . . . );
I für die meisten Fälle geeignet:I Speicher anfordern: void *kmalloc(size_t, int);I Speicher freigeben: void kfree(void *ptr);
I angeforderter Speicher nicht initialisiert (kann beliebigenInhalt haben)
I freigegebener Speicher wird nicht automatisch gelöscht
int *data = kmalloc(DATA_SIZE, GFP_KERNEL);/* Fehlerbehandlung und
Verwendung von angefordertem Speicher */kfree(data);
28/41
OSUELinux Kernel
ModulBonusbeispiel
Frömel
CharacterDevices
FileOperationen
Kernelspace
Lifecycle
Datenaustausch Kernelspace <-> UserspaceOft notwendig Bufferinhalte vom Kernel-Space in denUser-Space und umgekehrt zu transferieren:
I Niemals ungeprüfte Pointer im Kernel dereferenzieren!
I 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);
I wie memcpy, zusätzlich: Prüfung des User-Space Pointers
I Rückgabe enthält Anzahl der nicht kopierten Bytes (d.h.wenn nicht 0 –> Fehler).
I Kopieroperationen können jederzeit unterbrochen werden(Concurrency!) z.B. angeforderte Page nicht imHauptspeicher
29/41
OSUELinux Kernel
ModulBonusbeispiel
Frömel
CharacterDevices
FileOperationen
Kernelspace
Lifecycle
Lifecycle eines Character Devices
I InitialisierungI Registrierung/Allozierung der Character Device Region:
register_chrdev_regionI Initialisierung der Character Device Strukturstruct cdev (inkl. struct file_operations):cdev_init
I Registrierung des Character Devices im Kernel: cdev_addBemerkung: Ab diesem Zeitpunkt muss damit gerechnetwerden, dass das Device verwendet wird - auch wenn diemodule_init Funktion noch nicht fertig ist!
I EntfernungI Deregistrierung des Character Devices: cdev_delI Deregistrierung der Character Device Region:unregister_chrdev_region
30/41
OSUELinux Kernel
ModulBonusbeispiel
Frömel
Übungs-umgebung
Org
Angabe
LDD3 vs.4.0.2
Ausblickund Quellen
Teil IV
Bonusbeispiel
31/41
OSUELinux Kernel
ModulBonusbeispiel
Frömel
Übungs-umgebung
Org
Angabe
LDD3 vs.4.0.2
Ausblickund Quellen
Übungsumgebung
I Kernel 4.0.2, Debian 8, JessieI User Mode Linux (UML) Umgebung im TI-Lab installiert
I Read-only Base Image (gross)/opt/osue/uml/osue_bonus.umldisk
I Overlay im Homedirectory (nur Änderungen zum BaseImage): ~/.uml.cow
I virtuelle Maschine: Linux wird als User-Prozess ausgeführt(Architektur um)
I ”sichere” Umgebung für riskantes (und rasches) Entwickeln
I Interaktion mit Host per hostfs Filesystem (z.B.Home-Directory kann gemountet werden)
I Interaktion mit User über Pseudo Terminals in/dev/pts/ (z.B. per screen(1) verwendbar)
I weitere Details: siehe Angabe (im myTI)
32/41
OSUELinux Kernel
ModulBonusbeispiel
Frömel
Übungs-umgebung
Org
Angabe
LDD3 vs.4.0.2
Ausblickund Quellen
Organisatorisches
I Selbststudium: Linux Device Drivers 3rd Edition (LDD3) -zumindest Kapitel 1 bis 3, 5 (Semaphoren)
I Richtlinien:I Beispielabnahme ausschliesslich auf TI-Lab UmgebungI GNU C Standard, i.e. C99 Std. mit GNU Erweiterungen
(statt C89 Standard und gegebenen CFLAGS für alleanderen Beispiele)
I debug Modul Parameter (siehe Angabe)I Coding Style:/usr/src/linux/Documentation/CodingStyle
I SynchronisationI Sauberes Modul Unloading (keine Resourceleaks!)
I Abgabedeadline: 22.06.2015 23:59
I Abgabegespräche 23.06.2015 und 24.06.2015,Anmeldung via myTI, TI Labor
I Beginn: ab sofort
33/41
OSUELinux Kernel
ModulBonusbeispiel
Frömel
Übungs-umgebung
Org
Angabe
LDD3 vs.4.0.2
Ausblickund Quellen
Bonusbeispiel: Secvault - Übersicht
I Character Device Driver soll als Kernel Modulimplementiert werden
I Verwaltung von bis zu 4 Secure Vaults (Secvaults)I Größe zwischen 1 Byte und 1 MByte (konfigurierbar)I verschlüsselt nach XOR Verfahren
I Userspace Tool: svctlI anlegen und entfernen von SecvaultsI Löschung (gesamten Speicher mit 0x0 überschreiben)
eines Secvaults.
34/41
OSUELinux Kernel
ModulBonusbeispiel
Frömel
Übungs-umgebung
Org
Angabe
LDD3 vs.4.0.2
Ausblickund Quellen
Ablauf
I Einmaliges Anlegen der notwendigen Special Files permknod(1): /dev/sv_ctl, /dev/sv_data0,/dev/sv_data1, /dev/sv_data2, /dev/sv_data3
I Modul stellt nach dem Laden Control Character Device(/dev/sv_ctl) zur Verfügung
I Userspace Tool svctl kommuniziert per IOCTL Calls mitControl Device (/dev/sv_ctl) des Treibers
I Anlegen, Löschen (mit 0x0 überschreiben) und Entferneneines Secvaults
I liest Schlüssel über stdin (bis zu 10 Byte, wenn weniger:0x0).
35/41
OSUELinux Kernel
ModulBonusbeispiel
Frömel
Übungs-umgebung
Org
Angabe
LDD3 vs.4.0.2
Ausblickund Quellen
Anlegen
I Überprüfung, ob Secvault schon existiert, falls ja –> FehlerI sonst:
I Erzeugung eines neuen Character DevicesI angeforderten Speicher reservierenI Schlüssel zum Secvault speichern
36/41
OSUELinux Kernel
ModulBonusbeispiel
Frömel
Übungs-umgebung
Org
Angabe
LDD3 vs.4.0.2
Ausblickund Quellen
Lesen/Schreiben/Löschen/Entfernen
I Beim Lesen/Schreiben *): Anwendung des symmetrischenVerchlüsselungsverfahren XOR abhängig von Positioncrypt(pos, data, key) = data[pos] ⊕ key[pos mod keysize]
I Wenn über Speichergrenze des Secvaultshinausgelesen/geschrieben wird: geeigneteFehlerbehandlung
I Löschanforderung: den gesamten Secvault mit 0x0überschreiben (Operation innerhalb des Moduls!)
I Entfernung: Speicher- und Characterdevicefreigabe *)
*) hier kann auch überprüft werden, ob der Benutzer berechtigtist (siehe Fragen in Angabe)
37/41
OSUELinux Kernel
ModulBonusbeispiel
Frömel
Übungs-umgebung
Org
Angabe
LDD3 vs.4.0.2
Ausblickund Quellen
Secvaults – Relevanz?
38/41
OSUELinux Kernel
ModulBonusbeispiel
Frömel
Übungs-umgebung
Org
Angabe
LDD3 vs.4.0.2
Ausblickund Quellen
Unterschiede LDD3 und Linux 4.0.2
LDD3 für 2.6.10 - API Changes:http://lwn.net/Articles/2.6-kernel-api/zB:
LDD3 4.0.2
ioctl unlocked_ioctlinit_MUTEX(&mutex) sema_init(&mutex, 1)current->uid current_uid()uid_t kuid_tuid_a == uid_b uid_eq(uid_a, uid_b)
Weitere Änderungen ?–> mailto:[email protected]
39/41
OSUELinux Kernel
ModulBonusbeispiel
Frömel
Übungs-umgebung
Org
Angabe
LDD3 vs.4.0.2
Ausblickund Quellen
Ausblick
I Letzte Vorlesung!I Lust auf mehr Linux Kernel Entwicklung?
I Talk: ’Write and Submit your first Linux kernel Patch’4
I Linux Kernel Newbies5
I Lust auf Konzepte/Design zwischen Hardware andUserspace Software?
I Programmierung von Betriebssystemen (ProgOS) 182.710(Sommersemester)
I Live Demo
4http://www.youtube.com/watch?v=LLBrBBImJt45http://kernelnewbies.org/
40/41
OSUELinux Kernel
ModulBonusbeispiel
Frömel
Übungs-umgebung
Org
Angabe
LDD3 vs.4.0.2
Ausblickund Quellen
Quellen und Material
I ”Linux Device Drivers 3rd Edition” (LDD3) von JonathanCorbet, Alessandro Rubini, and Greg Kroah-Hartmanhttp://lwn.net/Kernel/LDD3/
I ”Linux Kernel Development 2nd Edition” von Robert Lovehttp://book.chinaunix.net/special/ebook/Linux_Kernel_Development/0672327201/toc.html
I ’Comic’: https://www.kickstarter.com/profile/1694714745
I Ramdump setup: neimod, 3ds scene
41/41