Via Aspect-Oriented Programming Advancing Operating Systems

Total Page:16

File Type:pdf, Size:1020Kb

Via Aspect-Oriented Programming Advancing Operating Systems Advancing Operating Systems via Aspect-Oriented Programming Michael Engel 2 Philipps-Universitat¨ Marburg Fachbereich Mathematik und Informatik Advancing Operating Systems via Aspect-Oriented Programming Dissertation zur Erlangung des Doktorgrades der Naturwissenschaften (Dr. rer. nat.) vorgelegt von Michael Engel aus Zell/Mosel Marburg/Lahn 2005 vom Fachbereich Mathematik und Informatik der Philipps-Universitat¨ Marburg als Dissertation am 4. Juli 2005 angenommen. Erstgutachter: Prof. Dr. Bernd Freisleben Zweitgutachter: Prof. Dr. Wolfgang Merzenich Tag der mundlichen¨ Prufung¨ am 26. Juli 2005 Abstract Operating system kernels are among the most complex pieces of software in existence to- day. Maintaining the kernel code and developing new functionality is increasingly compli- cated, since the amount of required features has risen significantly, leading to side effects that can be introduced inadvertedly by changing a piece of code that belongs to a completely different context. Software developers try to modularize their code base into separate functional units. Some of the functionality or “concerns” required in a kernel, however, does not fit into the given modularization structure; this code may then be spread over the code base and its implementation tangled with code implementing different concerns. These so-called “crosscutting concerns” are especially difficult to handle since a change in a crosscutting concern implies that all relevant locations spread throughout the code base have to be modified. Aspect-Oriented Software Development (AOSD) is an approach to handle crosscutting concerns by factoring them out into separate modules. The “advice” code contained in these modules is woven into the original code base according to a pointcut description, a set of interaction points (joinpoints) with the code base. To be used in operating systems, AOSD requires tool support for the prevalent procedu- ral programming style as well as support for weaving aspects. Many interactions in kernel code are dynamic, so in order to implement non-static behavior and improve performance, a dynamic weaver that deploys and undeploys aspects at system runtime is required. This thesis presents an extension of the “C” programming language to support AOSD. Based on this, two dynamic weaving toolkits – TOSKANA and TOSKANA-VM – are presented to permit dynamic aspect weaving in the monolithic NetBSD kernel as well as in a virtual- machine and microkernel-based Linux kernel running on top of L4. Based on TOSKANA, applications for this dynamic aspect technology are discussed and evaluated. The thesis closes with a view on an aspect-oriented kernel structure that maintains coherency and handles crosscutting concerns using dynamic aspects while enhancing de- velopment methods through the use of domain-specific programming languages. Zusammenfassung Betriebssystem-Kernel zahlen¨ zu den komplexesten Software-Systemen, die heutzutage verwendet werden. Die Wartung des Kernel-Codes und die Entwicklung neuartiger Funk- tionalitat¨ wird zunehmend komplizierter, da die Menge an benotigten¨ Eigenschaften eines Kernels stetig steigt. Dies kann zu unabsichtlich in den Code eingebrachten Nebeneffekten fuhren,¨ wenn ein Teil des Systems geandert¨ wird, der zu einem anderen Kontext gehort.¨ Software-Entwickler modularisieren ihre Code-Basis in einzelne funktionale Einheiten. Einige Funktionalitat¨ – auch “concern” genannt – die im Kernel benotigt¨ wird, gliedert sich nicht sauber in die vorgegebene Modularisierungsstruktur ein; die zugehorigen¨ Codestucke¨ sind dann oft uber¨ das gesamte System verteilt und ihre Implementierung ist mit der Imple- mentierung anderer Funktionalitat¨ vermischt. Diese sogenannten “crosscutting concerns” (querschneidende Belange) sind besonders schwierig in der Handhabung, da Anderungen¨ an einem solchen crosscutting concern erfordern, dass alle die uber¨ die gesamte Codebasis verteilten relevanten Stellen gefunden und modifiziert werden. Aspekt-orientierte Software-Entwicklung (Aspect Oriented Software Development, AOSD) ist ein Ansatz zur einfacheren Handhabung von crosscutting concerns, der den zugehorigen¨ Code in separate Module herausfaktorisiert. Der in diesen Modulen enthaltene sogenannte ”Advice-Code” wird dann mit der ursprunglichen¨ Code-Basis nach Vorgabe einer sogenan- nten Pointcut-Beschreibung verwoben, die aus einer Menge an Interaktionspunkten mit dem ursprunglichen¨ Code, den sog. “Join Points” besteht. Um AOSD im Rahmen von Betriebssystemen zu verwenden, mussen¨ aspektorientierte Werkzeuge zur Unterstutzung¨ fur¨ den dort vorherrschenden prozeduralen Programmierstil sowie eine unterstutzende¨ Infrastruktur fur¨ das Weben von Aspekten zur Verfugung¨ ste- hen. Viele Interaktionen mit dem Kernel sind dynamisch, daher ist ein dynamischer Weber erforderlich, der Aspekte zur Laufzeit in das System einfugen¨ und wieder aus diesem ent- fernen kann. Diese Arbeit stellt eine Erweiterung der Programmiersprache “C” vor, die aspektori- entierte Programmierung unterstutzt.¨ Darauf aufbauend werden zwei Werkzeugsatze¨ fur¨ dynamisches Weben – TOSKANA und TOSKANA-VM – vorgestellt, die dynamische Aspekte im monolithischen NetBSD-Kernel bzw. in einem Linux-Kernel realisieren, die auf einer In- frastruktur aufbauen, die aus einem L4-Microkernel und einer unterstutzenden¨ virtuellen Maschine besteht. Auf der Basis von TOSKANA werden Anwendungen fur¨ diese dynami- sche Aspekttechnologie vorgestellt und bewertet. Ein Ausblick auf eine aspekt-orientierte Kernelstruktur, die mit Hilfe von dynamischen Aspekten Koharenz¨ sicherstellt und crosscutting concerns handhabt und zugleich die Sys- tementwicklung durch den Einsatz domanenspezifischer¨ Programmiersprachen erleichtert, schließt die Arbeit ab. Contents 1 Introduction 1 1.1 The State of Operating Systems Research . 1 1.2 Current Trends . 3 1.2.1 Configurability . 4 1.2.2 Ubiquituos Networking . 4 1.2.3 Virtualization . 5 1.2.4 Autonomic Computing . 5 1.3 Structure of the Thesis . 6 1.4 Acknowledgements . 8 2 NetBSD System Structure 11 2.1 Introduction . 11 2.2 Unix Kernel Structure . 11 2.3 System Evolution . 13 2.4 Layers . 19 2.4.1 Layered Networking Structure . 19 2.4.2 Virtual File System Structure . 23 2.5 Contexts . 25 2.5.1 Startup and Control . 25 2.5.2 Process Contexts . 26 2.5.3 Asynchronous (Hardware) Contexts . 27 2.6 Summary . 28 3 In-Kernel Crosscutting Concerns 29 3.1 Introduction . 29 3.2 Modularity and Concerns in Kernel Code . 29 3.3 A Definition of Crosscutting Concerns . 32 3.3.1 An Example: Telecommunications . 32 3.3.2 Scattering and Tangling . 33 Contents 3.3.3 Crosscutting in Related Research . 34 i 3.3.4 Identifying Crosscutting . 34 3.4 The Trouble with Macros . 35 3.5 OO in Kernel Mode . 36 3.5.1 Object Orientation Using Procedural Languages . 36 3.5.2 Example: Console Handling . 37 3.6 Crosscutting Concern Example: Disk Quota . 38 3.7 Summary . 41 4 Aspect-Oriented Programming 43 4.1 Introduction . 43 4.2 AOP — considered useful! . 43 4.3 Using AOP Inside the Kernel . 46 4.3.1 Join Points . 46 4.3.2 Pointcuts . 47 4.3.3 Join Point and Pointcut Types . 47 4.3.4 Advice Code . 48 4.4 Weaving . 48 4.5 Static AOP . 48 4.5.1 Link-time Weaving . 50 4.5.2 Not Quite That Static . 50 4.6 Dynamic AOP . 52 4.7 Summary . 53 5 A C Extension Supporting AOP 55 5.1 Introduction . 55 5.2 AspectC . 55 5.3 Supported Join Points and Pointcuts . 56 5.4 A Grammar for Static AspectC . 57 5.4.1 Aspect Specification . 57 5.4.2 Grammar . 57 5.5 A Real-World AspectC Example . 59 5.6 Approaches to Compiling Aspect Code . 61 5.6.1 GCC Front End . 61 Contents 5.6.2 XML-based AOP Tools . 61 ii 5.6.3 Source Code Transformation . 62 5.7 The Static AspectC Compiler . 62 5.7.1 The CIL Infrastructure . 63 5.7.2 AspectC Compiler Structure . 63 5.8 Weaving Static AspectC . 64 5.8.1 Before Advice . 65 5.8.2 After Advice . 66 5.8.3 Around Advice . 67 5.9 Support Library . 69 5.10 Extensions to the AspectC Syntax . 71 5.10.1 Init Functions for Aspects . 71 5.10.2 Local Storage for Aspects . 71 5.10.3 Use Case: A Sense of Time for Aspects . 72 5.10.4 Dynamic AspectC . 74 5.10.5 Expressing Context Dependencies Using Dynamic AOP . 74 5.10.6 Use Case: Temporal Dependencies . 74 5.11 Evaluation . 76 5.12 Summary . 77 6 Execution Interaction 79 6.1 Introduction . ..
Recommended publications
  • Copy on Write Based File Systems Performance Analysis and Implementation
    Copy On Write Based File Systems Performance Analysis And Implementation Sakis Kasampalis Kongens Lyngby 2010 IMM-MSC-2010-63 Technical University of Denmark Department Of Informatics Building 321, DK-2800 Kongens Lyngby, Denmark Phone +45 45253351, Fax +45 45882673 [email protected] www.imm.dtu.dk Abstract In this work I am focusing on Copy On Write based file systems. Copy On Write is used on modern file systems for providing (1) metadata and data consistency using transactional semantics, (2) cheap and instant backups using snapshots and clones. This thesis is divided into two main parts. The first part focuses on the design and performance of Copy On Write based file systems. Recent efforts aiming at creating a Copy On Write based file system are ZFS, Btrfs, ext3cow, Hammer, and LLFS. My work focuses only on ZFS and Btrfs, since they support the most advanced features. The main goals of ZFS and Btrfs are to offer a scalable, fault tolerant, and easy to administrate file system. I evaluate the performance and scalability of ZFS and Btrfs. The evaluation includes studying their design and testing their performance and scalability against a set of recommended file system benchmarks. Most computers are already based on multi-core and multiple processor architec- tures. Because of that, the need for using concurrent programming models has increased. Transactions can be very helpful for supporting concurrent program- ming models, which ensure that system updates are consistent. Unfortunately, the majority of operating systems and file systems either do not support trans- actions at all, or they simply do not expose them to the users.
    [Show full text]
  • Enhancing the Accuracy of Synthetic File System Benchmarks Salam Farhat Nova Southeastern University, [email protected]
    Nova Southeastern University NSUWorks CEC Theses and Dissertations College of Engineering and Computing 2017 Enhancing the Accuracy of Synthetic File System Benchmarks Salam Farhat Nova Southeastern University, [email protected] This document is a product of extensive research conducted at the Nova Southeastern University College of Engineering and Computing. For more information on research and degree programs at the NSU College of Engineering and Computing, please click here. Follow this and additional works at: https://nsuworks.nova.edu/gscis_etd Part of the Computer Sciences Commons Share Feedback About This Item NSUWorks Citation Salam Farhat. 2017. Enhancing the Accuracy of Synthetic File System Benchmarks. Doctoral dissertation. Nova Southeastern University. Retrieved from NSUWorks, College of Engineering and Computing. (1003) https://nsuworks.nova.edu/gscis_etd/1003. This Dissertation is brought to you by the College of Engineering and Computing at NSUWorks. It has been accepted for inclusion in CEC Theses and Dissertations by an authorized administrator of NSUWorks. For more information, please contact [email protected]. Enhancing the Accuracy of Synthetic File System Benchmarks by Salam Farhat A dissertation submitted in partial fulfillment of the requirements for the degree of Doctor in Philosophy in Computer Science College of Engineering and Computing Nova Southeastern University 2017 We hereby certify that this dissertation, submitted by Salam Farhat, conforms to acceptable standards and is fully adequate in scope and quality to fulfill the dissertation requirements for the degree of Doctor of Philosophy. _____________________________________________ ________________ Gregory E. Simco, Ph.D. Date Chairperson of Dissertation Committee _____________________________________________ ________________ Sumitra Mukherjee, Ph.D. Date Dissertation Committee Member _____________________________________________ ________________ Francisco J.
    [Show full text]
  • Ebook - Informations About Operating Systems Version: August 15, 2006 | Download
    eBook - Informations about Operating Systems Version: August 15, 2006 | Download: www.operating-system.org AIX Internet: AIX AmigaOS Internet: AmigaOS AtheOS Internet: AtheOS BeIA Internet: BeIA BeOS Internet: BeOS BSDi Internet: BSDi CP/M Internet: CP/M Darwin Internet: Darwin EPOC Internet: EPOC FreeBSD Internet: FreeBSD HP-UX Internet: HP-UX Hurd Internet: Hurd Inferno Internet: Inferno IRIX Internet: IRIX JavaOS Internet: JavaOS LFS Internet: LFS Linspire Internet: Linspire Linux Internet: Linux MacOS Internet: MacOS Minix Internet: Minix MorphOS Internet: MorphOS MS-DOS Internet: MS-DOS MVS Internet: MVS NetBSD Internet: NetBSD NetWare Internet: NetWare Newdeal Internet: Newdeal NEXTSTEP Internet: NEXTSTEP OpenBSD Internet: OpenBSD OS/2 Internet: OS/2 Further operating systems Internet: Further operating systems PalmOS Internet: PalmOS Plan9 Internet: Plan9 QNX Internet: QNX RiscOS Internet: RiscOS Solaris Internet: Solaris SuSE Linux Internet: SuSE Linux Unicos Internet: Unicos Unix Internet: Unix Unixware Internet: Unixware Windows 2000 Internet: Windows 2000 Windows 3.11 Internet: Windows 3.11 Windows 95 Internet: Windows 95 Windows 98 Internet: Windows 98 Windows CE Internet: Windows CE Windows Family Internet: Windows Family Windows ME Internet: Windows ME Seite 1 von 138 eBook - Informations about Operating Systems Version: August 15, 2006 | Download: www.operating-system.org Windows NT 3.1 Internet: Windows NT 3.1 Windows NT 4.0 Internet: Windows NT 4.0 Windows Server 2003 Internet: Windows Server 2003 Windows Vista Internet: Windows Vista Windows XP Internet: Windows XP Apple - Company Internet: Apple - Company AT&T - Company Internet: AT&T - Company Be Inc. - Company Internet: Be Inc. - Company BSD Family Internet: BSD Family Cray Inc.
    [Show full text]
  • Ext4 File System and Crash Consistency
    1 Ext4 file system and crash consistency Changwoo Min 2 Summary of last lectures • Tools: building, exploring, and debugging Linux kernel • Core kernel infrastructure • Process management & scheduling • Interrupt & interrupt handler • Kernel synchronization • Memory management • Virtual file system • Page cache and page fault 3 Today: ext4 file system and crash consistency • File system in Linux kernel • Design considerations of a file system • History of file system • On-disk structure of Ext4 • File operations • Crash consistency 4 File system in Linux kernel User space application (ex: cp) User-space Syscalls: open, read, write, etc. Kernel-space VFS: Virtual File System Filesystems ext4 FAT32 JFFS2 Block layer Hardware Embedded Hard disk USB drive flash 5 What is a file system fundamentally? int main(int argc, char *argv[]) { int fd; char buffer[4096]; struct stat_buf; DIR *dir; struct dirent *entry; /* 1. Path name -> inode mapping */ fd = open("/home/lkp/hello.c" , O_RDONLY); /* 2. File offset -> disk block address mapping */ pread(fd, buffer, sizeof(buffer), 0); /* 3. File meta data operation */ fstat(fd, &stat_buf); printf("file size = %d\n", stat_buf.st_size); /* 4. Directory operation */ dir = opendir("/home"); entry = readdir(dir); printf("dir = %s\n", entry->d_name); return 0; } 6 Why do we care EXT4 file system? • Most widely-deployed file system • Default file system of major Linux distributions • File system used in Google data center • Default file system of Android kernel • Follows the traditional file system design 7 History of file system design 8 UFS (Unix File System) • The original UNIX file system • Design by Dennis Ritche and Ken Thompson (1974) • The first Linux file system (ext) and Minix FS has a similar layout 9 UFS (Unix File System) • Performance problem of UFS (and the first Linux file system) • Especially, long seek time between an inode and data block 10 FFS (Fast File System) • The file system of BSD UNIX • Designed by Marshall Kirk McKusick, et al.
    [Show full text]
  • Proceedings of the Linux Symposium
    Proceedings of the Linux Symposium Volume One June 27th–30th, 2007 Ottawa, Ontario Canada Contents The Price of Safety: Evaluating IOMMU Performance 9 Ben-Yehuda, Xenidis, Mostrows, Rister, Bruemmer, Van Doorn Linux on Cell Broadband Engine status update 21 Arnd Bergmann Linux Kernel Debugging on Google-sized clusters 29 M. Bligh, M. Desnoyers, & R. Schultz Ltrace Internals 41 Rodrigo Rubira Branco Evaluating effects of cache memory compression on embedded systems 53 Anderson Briglia, Allan Bezerra, Leonid Moiseichuk, & Nitin Gupta ACPI in Linux – Myths vs. Reality 65 Len Brown Cool Hand Linux – Handheld Thermal Extensions 75 Len Brown Asynchronous System Calls 81 Zach Brown Frysk 1, Kernel 0? 87 Andrew Cagney Keeping Kernel Performance from Regressions 93 T. Chen, L. Ananiev, and A. Tikhonov Breaking the Chains—Using LinuxBIOS to Liberate Embedded x86 Processors 103 J. Crouse, M. Jones, & R. Minnich GANESHA, a multi-usage with large cache NFSv4 server 113 P. Deniel, T. Leibovici, & J.-C. Lafoucrière Why Virtualization Fragmentation Sucks 125 Justin M. Forbes A New Network File System is Born: Comparison of SMB2, CIFS, and NFS 131 Steven French Supporting the Allocation of Large Contiguous Regions of Memory 141 Mel Gorman Kernel Scalability—Expanding the Horizon Beyond Fine Grain Locks 153 Corey Gough, Suresh Siddha, & Ken Chen Kdump: Smarter, Easier, Trustier 167 Vivek Goyal Using KVM to run Xen guests without Xen 179 R.A. Harper, A.N. Aliguori & M.D. Day Djprobe—Kernel probing with the smallest overhead 189 M. Hiramatsu and S. Oshima Desktop integration of Bluetooth 201 Marcel Holtmann How virtualization makes power management different 205 Yu Ke Ptrace, Utrace, Uprobes: Lightweight, Dynamic Tracing of User Apps 215 J.
    [Show full text]
  • The Linux Device File-System
    The Linux Device File-System Richard Gooch EMC Corporation [email protected] Abstract 1 Introduction All Unix systems provide access to hardware via de- vice drivers. These drivers need to provide entry points for user-space applications and system tools to access the hardware. Following the \everything is a file” philosophy of Unix, these entry points are ex- posed in the file name-space, and are called \device The Device File-System (devfs) provides a power- special files” or \device nodes". ful new device management mechanism for Linux. Unlike other existing and proposed device manage- This paper discusses how these device nodes are cre- ment schemes, it is powerful, flexible, scalable and ated and managed in conventional Unix systems and efficient. the limitations this scheme imposes. An alternative mechanism is then presented. It is an alternative to conventional disc-based char- acter and block special devices. Kernel device drivers can register devices by name rather than de- vice numbers, and these device entries will appear in the file-system automatically. 1.1 Device numbers Devfs provides an immediate benefit to system ad- ministrators, as it implements a device naming scheme which is more convenient for large systems Conventional Unix systems have the concept of a (providing a topology-based name-space) and small \device number". Each instance of a driver and systems (via a device-class based name-space) alike. hardware component is assigned a unique device number. Within the kernel, this device number is Device driver authors can benefit from devfs by used to refer to the hardware and driver instance.
    [Show full text]
  • Virtual File System (VFS) Implementation in Linux
    Virtual File System (VFS) Implementation in Linux Tushar B. Kute, http://tusharkute.com Virtual File System • The Linux kernel implements the concept of Virtual File System (VFS, originally Virtual Filesystem Switch), so that it is (to a large degree) possible to separate actual "low-level" filesystem code from the rest of the kernel. • This API was designed with things closely related to the ext2 filesystem in mind. For very different filesystems, like NFS, there are all kinds of problems. Virtual File System- Main Objects • The kernel keeps track of files using in-core inodes ("index nodes"), usually derived by the low-level filesystem from on-disk inodes. • A file may have several names, and there is a layer of dentries ("directory entries") that represent pathnames, speeding up the lookup operation. • Several processes may have the same file open for reading or writing, and file structures contain the required information such as the current file position. • Access to a filesystem starts by mounting it. This operation takes a filesystem type (like ext2, vfat, iso9660, nfs) and a device and produces the in-core superblock that contains the information required for operations on the filesystem; a third ingredient, the mount point, specifies what pathname refers to the root of the filesystem. Virtual File System The /proc filesystem • The /proc filesystem contains a illusionary filesystem. • It does not exist on a disk. Instead, the kernel creates it in memory. • It is used to provide information about the system (originally about processes, hence the name). • The proc filesystem is a pseudo-filesystem which provides an interface to kernel data structures.
    [Show full text]
  • Container-Based Virtualization for Byte-Addressable NVM Data Storage
    2016 IEEE International Conference on Big Data (Big Data) Container-Based Virtualization for Byte-Addressable NVM Data Storage Ellis R. Giles Rice University Houston, Texas [email protected] Abstract—Container based virtualization is rapidly growing Storage Class Memory, or SCM, is an exciting new in popularity for cloud deployments and applications as a memory technology with the potential of replacing hard virtualization alternative due to the ease of deployment cou- drives and SSDs as it offers high-speed, byte-addressable pled with high-performance. Emerging byte-addressable, non- volatile memories, commonly called Storage Class Memory or persistence on the main memory bus. Several technologies SCM, technologies are promising both byte-addressability and are currently under research and development, each with dif- persistence near DRAM speeds operating on the main memory ferent performance, durability, and capacity characteristics. bus. These new memory alternatives open up a new realm of These include a ReRAM by Micron and Sony, a slower, but applications that no longer have to rely on slow, block-based very large capacity Phase Change Memory or PCM by Mi- persistence, but can rather operate directly on persistent data using ordinary loads and stores through the cache hierarchy cron and others, and a fast, smaller spin-torque ST-MRAM coupled with transaction techniques. by Everspin. High-speed, byte-addressable persistence will However, SCM presents a new challenge for container-based give rise to new applications that no longer have to rely on applications, which typically access persistent data through slow, block based storage devices and to serialize data for layers of block based file isolation.
    [Show full text]
  • Research Purpose Operating Systems – a Wide Survey
    GESJ: Computer Science and Telecommunications 2010|No.3(26) ISSN 1512-1232 RESEARCH PURPOSE OPERATING SYSTEMS – A WIDE SURVEY Pinaki Chakraborty School of Computer and Systems Sciences, Jawaharlal Nehru University, New Delhi – 110067, India. E-mail: [email protected] Abstract Operating systems constitute a class of vital software. A plethora of operating systems, of different types and developed by different manufacturers over the years, are available now. This paper concentrates on research purpose operating systems because many of them have high technological significance and they have been vividly documented in the research literature. Thirty-four academic and research purpose operating systems have been briefly reviewed in this paper. It was observed that the microkernel based architecture is being used widely to design research purpose operating systems. It was also noticed that object oriented operating systems are emerging as a promising option. Hence, the paper concludes by suggesting a study of the scope of microkernel based object oriented operating systems. Keywords: Operating system, research purpose operating system, object oriented operating system, microkernel 1. Introduction An operating system is a software that manages all the resources of a computer, both hardware and software, and provides an environment in which a user can execute programs in a convenient and efficient manner [1]. However, the principles and concepts used in the operating systems were not standardized in a day. In fact, operating systems have been evolving through the years [2]. There were no operating systems in the early computers. In those systems, every program required full hardware specification to execute correctly and perform each trivial task, and its own drivers for peripheral devices like card readers and line printers.
    [Show full text]
  • Secure Cloud Storage with Client-Side Encryption Using a Trusted Execution Environment
    Secure Cloud Storage with Client-side Encryption using a Trusted Execution Environment Marciano da Rocha1 a, Dalton Cezane´ Gomes Valadares2;4 b, Angelo Perkusich3 c, Kyller Costa Gorgonio4 d, Rodrigo Tomaz Pagno1 e and Newton Carlos Will1 f 1Department of Computer Science, Federal University of Technology, Parana,´ Dois Vizinhos, Brazil 2Department of Mechanical Engineering, Federal Institute of Pernambuco, Caruaru, Brazil 3Department of Electrical Engineering, Federal University of Campina Grande, Campina Grande, Brazil 4Department of Computer Science, Federal University of Campina Grande, Campina Grande, Brazil Keywords: Intel SGX, Data Sealing, File Encryption, Confidentiality, Integrity, Secure Storage, Cloud Storage. Abstract: With the evolution of computer systems, the amount of sensitive data to be stored as well as the number of threats on these data grow up, making the data confidentiality increasingly important to computer users. Currently, with devices always connected to the Internet, the use of cloud data storage services has become practical and common, allowing quick access to such data wherever the user is. Such practicality brings with it a concern, precisely the confidentiality of the data which is delivered to third parties for storage. In the home environment, disk encryption tools have gained special attention from users, being used on personal computers and also having native options in some smartphone operating systems. The present work uses the data sealing, feature provided by the Intel Software Guard Extensions (Intel SGX) technology, for file encryption. A virtual file system is created in which applications can store their data, keeping the security guarantees provided by the Intel SGX technology, before send the data to a storage provider.
    [Show full text]
  • Detecting Exploit Code Execution in Loadable Kernel Modules
    Detecting Exploit Code Execution in Loadable Kernel Modules HaizhiXu WenliangDu SteveJ.Chapin Systems Assurance Institute Syracuse University 3-114 CST, 111 College Place, Syracuse, NY 13210, USA g fhxu02, wedu, chapin @syr.edu Abstract and pointer checks can lead to kernel-level exploits, which can jeopardize the integrity of the running kernel. Inside the In current extensible monolithic operating systems, load- kernel, exploitcode has the privilegeto interceptsystem ser- able kernel modules (LKM) have unrestricted access to vice routines, to modify interrupt handlers, and to overwrite all portions of kernel memory and I/O space. As a result, kernel data. In such cases, the behavior of the entire sys- kernel-module exploitation can jeopardize the integrity of tem may become suspect. the entire system. In this paper, we analyze the threat that Kernel-level protection is different from user space pro- comes from the implicit trust relationship between the oper- tection. Not every application-level protection mechanism ating system kernel and loadable kernel modules. We then can be applied directly to kernel code, because privileges present a specification-directed access monitoring tool— of the kernel environment is different from that of the user HECK, that detects kernel modules for malicious code ex- space. For example, non-executableuser page [21] and non- ecution. Inside the module, HECK prevents code execution executable user stack [29] use virtual memory mapping sup- on the kernel stack and the data sections; on the bound- port for pages and segments, but inside the kernel, a page ary, HECK restricts the module’s access to only those kernel or segment fault can lead to kernel panic.
    [Show full text]
  • DM-Relay - Safe Laptop Mode Via Linux Device Mapper
    ' $ DM-Relay - Safe Laptop Mode via Linux Device Mapper Study Thesis by cand. inform. Fabian Franz at the Faculty of Informatics Supervisor: Prof. Dr. Frank Bellosa Supervising Research Assistant: Dipl.-Inform. Konrad Miller Day of completion: 04/05/2010 &KIT – Universitat¨ des Landes Baden-Wurttemberg¨ und nationales Forschungszentrum in der Helmholtz-Gemeinschaft www.kit.edu % I hereby declare that this thesis is my own original work which I created without illegitimate help by others, that I have not used any other sources or resources than the ones indicated and that due acknowledgment is given where reference is made to the work of others. Karlsruhe, April 5th, 2010 Contents Deutsche Zusammenfassung xi 1 Introduction 1 1.1 Problem Definition . .1 1.2 Objectives . .1 1.3 Methodology . .1 1.4 Contribution . .2 1.5 Thesis Outline . .2 2 Background 3 2.1 Problems of Disk Power Management . .3 2.2 State of the Art . .4 2.3 Summary of this chapter . .8 3 Analysis 9 3.1 Pro and Contra . .9 3.2 A new approach . 13 3.3 Analysis of Proposal . 15 3.4 Summary of this chapter . 17 4 Design 19 4.1 Common problems . 19 4.2 System-Design . 21 4.3 Summary of this chapter . 21 5 Implementation of a dm-module for the Linux kernel 23 5.1 System-Architecture . 24 5.2 Log suitable for Flash-Storage . 28 5.3 Using dm-relay in practice . 31 5.4 Summary of this chapter . 31 vi Contents 6 Evaluation 33 6.1 Methodology . 33 6.2 Benchmarking setup .
    [Show full text]