An Implementation of Intelligent Disk Block Replication in Minix

Total Page:16

File Type:pdf, Size:1020Kb

An Implementation of Intelligent Disk Block Replication in Minix Internal Report 09-13 August 2009 Universiteit Leiden Opleiding Informatica An Implementation of Intelligent Disk Block Replication in Minix Kristian Rietveld MASTER’S THESIS Leiden Institute of Advanced Computer Science (LIACS) Leiden University Niels Bohrweg 1 2333 CA Leiden The Netherlands i Abstract With ever increasing speeds of central processing units and main memory, the speed of disks lags behind. Reading from disks such as hard disks, floppy disks and DVDs is orders of magnitude slower than the computer’s main memory. Since the capacity of the main memory is limited and we cannot do without disks for large sets of data, there is a real need to optimize reading from disks as much as possible. One way to do this is by optimizing according to the usage of the computer system by the user. We describe a way to optimize accessing disks by monitoring operations that are done on the disk thereby discovering patterns in these operations. By exploiting the fact that reading blocks that are stored on the disk in a contiguous sequence is faster than reading blocks that are scattered over the disk, we will store the blocks that make up these patterns in a contiguous sequence at another place on the disk. We will show that such replication of related disk blocks indeed leads to improvements in disk read performance in certain situations. We have modified the Minix operating system kernel to be able to discover such patterns and support the replication of blocks on its native file system. A concise overview of the full Minix kernel and our modifications to it are given. iii Voorwoord Al sinds het begin van mijn studie Informatica ben ik uitgebreid ge¨ınteresseerd geweest in besturingssystemen. Ook na het vak “Operating Systems” bleef de hebzucht bestaan om meer te leren over deze fundamenten van elk computersysteem. Onder begeleiding van Andr´eDeutz ben ik initieel begonnen met het bestuderen van de Linux broncode. Dat bleek te groot en complex te zijn om ook maar gedeeltelijk te doorgronden. Daarop zijn we verder gegaan met het compleet doorgronden van de Minix broncode. Van het begrijpen van een compleet besturingssysteem heb ik vele nieuwe inzichten in deze systemen gekregen. Als eerste zou ik Andr´eDeutz willen bedanken voor zijn begeleiding tijdens dit project. Met hem heb ik vele interessante discussies gevoerd. Het idee om met Minix aan de slag te gaan en het daarop volgende project zijn van zijn hand. Daarnaast wil ik Harry Wijshoff bedanken voor het overwegen van deze scriptie als afstudeerscriptie. Achter dit werk zit een proces van meerdere jaren. Zonder steun van vele andere mensen was dit werk waarschijnlijk nooit afgekomen. Ik zou de volgende mensen graag willen danken voor hun steun, motivatie, interesse en afleiding in de laatste jaren. Thijs, Wouter en Pieter voor de vele, interessante, vaak technisch getinte discussies in de kroeg tijdens de weekenden. Vian, Ron en anderen uit de FooBar, voor interesse en vooral mentale steun. Dankzij hun kreeg ik vaak weer extra motivatie om door te gaan met mijn studie en deze scriptie af te ronden. Mijn huidige bazen, Mikael Hallendal en Richard Hult, voor het geven van een kans om voor hun te werken. Daarbij voor alle hulp en flexibiliteit om naast mijn werk mijn studie af te kunnen maken. Mijn ouders, vanzelfsprekend, voor alle steun tijdens het studeren. Op hun kan ik altijd rekenen en terugvallen. Mijn vriendin Ginny, zij heeft mij als geen ander weten te inspireren en motiveren om mijn studie en in het bijzonder deze scriptie tot een goed einde te brengen. Een groot gedeelte van deze scriptie is geschreven bij haar in Barcelona, weg uit het drukke en soms chaotische Nederland. Haar liefde, steun en interesse zijn onge¨evenaard. Zonder haar inspiratie had het maanden langer geduurd om dit werk tot een einde te brengen. Kristian Rietveld September, 2008 1 Contents 1 Introduction 7 I Detailed study of Minix 8 2 Basics of Operating Systems 8 2.1 TheKernel ...................................... 8 2.1.1 Monolithickernels .............................. 8 2.1.2 Microkernels................................. 9 2.1.3 A mix between micro and monolithic kernels . 9 2.2 Interfacing with the hardware . 10 2.2.1 Booting up . 10 2.2.2 Handling interrupts and exceptions . 10 2.2.3 Protection . 11 2.2.4 Contextswitches ............................... 11 2.3 Process management . 12 2.3.1 Scheduling .................................. 12 2.3.2 Managing the process’ memory . 13 2.3.3 Systemcalls.................................. 13 2.3.4 Signal handling . 14 2.3.5 Passing messages . 15 2.4 Managing files . 15 2.4.1 General file system structure . 15 2.4.2 Inodes and file descriptors . 15 2.4.3 Caching . 16 3 Minix in detail 17 3.1 Origins......................................... 17 3.2 TheMinixkernel................................... 17 3.2.1 Structure ................................... 17 3.2.2 Message passing . 18 3.2.3 PIDsversusendpoints ............................ 20 3.2.4 Scheduling .................................. 21 3.2.5 Interrupt and exception handling . 22 3.2.6 Theclocktask ................................ 23 3.2.7 Thesystemtask ............................... 23 3.2.8 System call invocation . 24 3.2.9 Locking . 24 3.3 Bootprocess ..................................... 25 3.4 The process manager . 26 3.4.1 Initialization . 26 3.4.2 Managing memory . 27 3.4.3 Creating new processes . 28 3.4.4 Signal handling . 30 3.4.5 Swapping . 33 2 3.5 Thefilesystemserver ............................... 33 3.5.1 Inodes..................................... 34 3.5.2 Thesuperblock ............................... 35 3.5.3 Accessingdiskblocks ............................ 35 3.5.4 General model of operation . 35 3.5.5 Mapping between processes and file descriptors . 36 3.5.6 Disk block management . 37 3.5.7 Examples of operations . 37 3.6 Device driver interface . 41 3.6.1 Overview of the interface . 41 3.6.2 Driver mappings . 42 3.7 Improving reliability . 42 3.7.1 Message passing and system call masks . 42 3.7.2 The reincarnation server . 43 3.7.3 The data store server . 43 3.8 Conclusions...................................... 44 3.8.1 Arealmicrokernel? ............................. 44 3.8.2 Drawbacks of the micro kernel approach . 44 3.8.3 Areas which can be improved . 45 3.8.4 An option for resource-limited computers? . 46 II Implementing disk block replication in Minix 47 4 Intelligent disk block replication 47 4.1 Current performance measures . 48 4.1.1 Zones . 48 4.1.2 Read ahead . 48 4.2 Ouridea........................................ 49 4.2.1 Contiguous versus scattered disk reads . 49 4.2.2 Logging disk accesses . 50 4.2.3 Finding related blocks . 52 4.3 Howtodomeasurements?.............................. 55 4.4 Results of measurements with the proof of concept implementation . 56 5 An implementation of disk block replication 63 5.1 General overview of the implementation . 63 5.1.1 The optimization server . 63 5.1.2 Modifications to the file system server . 66 5.1.3 Communication between both servers . 71 5.1.4 Problems during implementation . 72 5.2 Performance measurements . 72 5.2.1 Testing conditions . 72 5.2.2 Testresults .................................. 73 5.2.3 Othertests .................................. 75 5.3 Conclusions and further research . 77 3 6 Conclusions 79 Glossary 80 Bibliography 82 A Source code listing of read-blocks.c 83 B Source code listing of pattern-generator.pl 86 C Source code listing of discover-pairs.pl 90 D Source code listing of simulate-minix-cache.pl 92 E Source code listing of the kernel adaptions 98 5 List of Figures 1 Simplified overview of a process’ memory layout . 13 2 General structure of the Minix system . 18 3 Thekernel’smemorymap .............................. 27 4 The different signal handling code paths . 30 5 Overview of the stack during signal handler invocation . 32 6 Overview of inodes and indirect zones . 37 7 Seconds needed to read various amounts of blocks from a floppy. 50 8 Sample sequence demonstrating neighborhoods . 52 9 Overview of the “accesses” data structure. Note that not for each subscript a hashtablehasbeendrawn. ............................. 53 10 Area with 5 points chosen and blocks in their radii in gray. Here a radius of 1 isused. ........................................ 55 11 Results of testing with the “contiguous blocks” pattern with different pattern densities........................................ 58 12 Results of testing with the “common blocks” pattern with different numbers of candidates....................................... 59 13 Results of testing with the “contiguous blocks” pattern with different pattern densities using the fixed cache simulator . 60 14 Comparison between running the tests with and without write-back enabled . 61 15 A sample sliding window, only the numbers inside the rectangle are in memory 65 16 General layout of the file system including replicated blocks . 68 17 General layout of the info block . 69 18 Results of measurements using the “contiguous blocks” pattern. 74 19 Results of measurements using the “common blocks” pattern. 75 Introduction 7 1 Introduction In computer systems an operating system is at least as important as the Central Processing Unit (CPU). Of course, you are able to run simple programs on a computer system without making use of an operating system, but you will quickly become frustrated with writing tedious code for being able to use the computer’s keyboard, showing output on the display, etc. One of the main tasks of the operating system is abstracting the hardware away from programmers, who want to get the next pressed key in the keyboard buffer with one library call instead of doing the Input/Output (I/O) operations with the keyboard themselves. Microprocessors these days are quite ubiquitous and so are operating systems. Operating systems are being developed, or derived from an existing operating system, for various kinds of electronic equipment: DVD players, televisions, cell phones, video game consoles, etc. When designing new electronic devices with a CPU, or embedded systems, thinking about your operating system design is a very important.
Recommended publications
  • Memory Protection in Embedded Systems Lanfranco Lopriore Dipartimento Di Ingegneria Dell’Informazione, Università Di Pisa, Via G
    CORE Metadata, citation and similar papers at core.ac.uk Provided by Archivio della Ricerca - Università di Pisa Memory protection in embedded systems Lanfranco Lopriore Dipartimento di Ingegneria dell’Informazione, Università di Pisa, via G. Caruso 16, 56126 Pisa, Italy E-mail: [email protected] Abstract — With reference to an embedded system featuring no support for memory manage- ment, we present a model of a protection system based on passwords and keys. At the hardware level, our model takes advantage of a memory protection unit (MPU) interposed between the processor and the complex of the main memory and the input-output devices. The MPU sup- ports both concepts of a protection context and a protection domain. A protection context is a set of access rights for the memory pages; a protection domain is a set of one or more protection contexts. Passwords are associated with protection domains. A process that holds a key match- ing a given password can take advantage of this key to activate the corresponding domain. A small set of protection primitives makes it possible to modify the composition of the domains in a strictly controlled fashion. The proposed protection model is evaluated from a number of salient viewpoints, which include key distribution, review and revocation, the memory requirements for storage of the information concerning protection, and the time necessary for key validation. Keywords: access right; embedded system; protection; revocation. 1. INTRODUCTION We shall refer to a typical embedded system architecture featuring a microprocessor inter- facing both volatile and non-volatile primary memory devices, as well as a variety of input/out- put devices including sensors and actuators.
    [Show full text]
  • Kafl: Hardware-Assisted Feedback Fuzzing for OS Kernels
    kAFL: Hardware-Assisted Feedback Fuzzing for OS Kernels Sergej Schumilo, Cornelius Aschermann, and Robert Gawlik, Ruhr-Universität Bochum; Sebastian Schinzel, Münster University of Applied Sciences; Thorsten Holz, Ruhr-Universität Bochum https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/schumilo This paper is included in the Proceedings of the 26th USENIX Security Symposium August 16–18, 2017 • Vancouver, BC, Canada ISBN 978-1-931971-40-9 Open access to the Proceedings of the 26th USENIX Security Symposium is sponsored by USENIX kAFL: Hardware-Assisted Feedback Fuzzing for OS Kernels Sergej Schumilo Cornelius Aschermann Robert Gawlik Ruhr-Universität Bochum Ruhr-Universität Bochum Ruhr-Universität Bochum Sebastian Schinzel Thorsten Holz Münster University of Applied Sciences Ruhr-Universität Bochum Abstract free vulnerabilities, are known threats for programs run- Many kinds of memory safety vulnerabilities have ning in user mode as well as for the operating system been endangering software systems for decades. (OS) core itself. Past experience has shown that attack- Amongst other approaches, fuzzing is a promising ers typically focus on user mode applications. This is technique to unveil various software faults. Recently, likely because vulnerabilities in user mode programs are feedback-guided fuzzing demonstrated its power, pro- notoriously easier and more reliable to exploit. How- ducing a steady stream of security-critical software bugs. ever, with the appearance of different kinds of exploit Most fuzzing efforts—especially feedback fuzzing—are defense mechanisms – especially in user mode, it has limited to user space components of an operating system become much harder nowadays to exploit known vul- (OS), although bugs in kernel components are more nerabilities.
    [Show full text]
  • Metro Ethernet Design Guide
    Design and Implementation Guide Juniper Networks Metro Ethernet Design Guide August 2016 ii © 2016 Juniper Networks, Inc. Design and Implementation Guide Juniper Networks, Inc. 1133 Innovation Way Sunnyvale, California 94089 USA 408-745-2000 www.juniper.net Copyright © 2016, Juniper Networks, Inc. All rights reserved. © 2016 Juniper Networks, Inc. iii Design and Implementation Guide Table of Contents Chapter 1 Introduction ............................................................................................................... 1 Using MPLS with Metro Ethernet ........................................................................................... 1 Metro Ethernet Solutions ......................................................................................................... 2 Chapter 2 Metro Ethernet Overview ......................................................................................... 3 Metro Ethernet Service Types ..................................................................................................... 5 Carrier Ethernet Overview........................................................................................................... 5 Carrier Ethernet Certification ................................................................................................... 6 Chapter 3 Architecture Overview .............................................................................................. 7 Juniper Networks Portfolio for Metro Ethernet Networks .........................................................
    [Show full text]
  • 130 Demystifying Arm Trustzone: a Comprehensive Survey
    Demystifying Arm TrustZone: A Comprehensive Survey SANDRO PINTO, Centro Algoritmi, Universidade do Minho NUNO SANTOS, INESC-ID, Instituto Superior Técnico, Universidade de Lisboa The world is undergoing an unprecedented technological transformation, evolving into a state where ubiq- uitous Internet-enabled “things” will be able to generate and share large amounts of security- and privacy- sensitive data. To cope with the security threats that are thus foreseeable, system designers can find in Arm TrustZone hardware technology a most valuable resource. TrustZone is a System-on-Chip and CPU system- wide security solution, available on today’s Arm application processors and present in the new generation Arm microcontrollers, which are expected to dominate the market of smart “things.” Although this technol- ogy has remained relatively underground since its inception in 2004, over the past years, numerous initiatives have significantly advanced the state of the art involving Arm TrustZone. Motivated by this revival ofinter- est, this paper presents an in-depth study of TrustZone technology. We provide a comprehensive survey of relevant work from academia and industry, presenting existing systems into two main areas, namely, Trusted Execution Environments and hardware-assisted virtualization. Furthermore, we analyze the most relevant weaknesses of existing systems and propose new research directions within the realm of tiniest devices and the Internet of Things, which we believe to have potential to yield high-impact contributions in the future. CCS Concepts: • Computer systems organization → Embedded and cyber-physical systems;•Secu- rity and privacy → Systems security; Security in hardware; Software and application security; Additional Key Words and Phrases: TrustZone, security, virtualization, TEE, survey, Arm ACM Reference format: Sandro Pinto and Nuno Santos.
    [Show full text]
  • Case Study: Building a Secure Operating System for Linux
    121 C H A P T E R 9 Case Study: Building a Secure Operating System for Linux The Linux operating system is a complete reimplementation of the POSIX interface initiated by Linus Torvalds [187]. Linux gained popularity throughout the 1990s, resulting in the promotion of Linux as a viable alternative to Windows, particularly for server systems (e.g., web servers). As Linux achieved acceptance, variety of efforts began to address the security problems of traditional UNIX systems (see Chapter 4). In this chapter, we describe the resulting approach for enforcing mandatory access control, the Linux Security Modules (LSM) framework. The LSM framework defines a reference monitor interface for Linux behind which a variety of reference monitor imple- mentations are possible. We also examine one of the LSM reference monitors, Security-enhanced Linux (SELinux), and evaluate how it uses the LSM framework to implement the reference monitor guarantees of Chapter 2. 9.1 LINUX SECURITY MODULES The Linux Security Modules (LSM) framework is a reference monitor system for the Linux ker- nel [342]. The LSM framework consists of two parts, a reference monitor interface integrated into the mainline Linux kernel (since version 2.6) and a reference monitor module, called an LSM, that implements reference monitor function (i.e., authorization module and policy store, see Chapter 2 for the reference monitor concept definition) behind that interface. Several independent modules have been developed for the LSM framework [228, 183, 127, 229] to implement different forms of reference monitor function (e.g., different policy modules). We examine the LSM reference monitor interface in this section, and one of its LSMs, Security-Enhanced Linux (SELinux) [229] in the subsequent section.
    [Show full text]
  • Operating Systems & Virtualisation Security Presentation Link
    CyBOK Operating Systems & Virtualisation Security Knowledge Area Herbert Bos © Crown Copyright, The National Cyber Security Centre 2020. This information is licensed under the Open Government Licence v3.0. To view this licence, visit http://www.nationalarchives.gov.uk/doc/open- government-licence/. When you use this information under the Open Government Licence, you should include the following attribution: CyBOK Operating Systems & Virtualisation Security Knowledge Area Issue 1.0 © Crown Copyright, The National Cyber Security Centre 2020, licensed under the Open Government Licence http://www.nationalarchives.gov.uk/doc/open-government-licence/. The CyBOK project would like to understand how the CyBOK is being used and its uptake. The project would like organisations using, or intending to use, CyBOK for the purposes of education, training, course development, professional development etc. to contact it at [email protected] to let the project know how they are using CyBOK. 7. Adoption 6. Related areas 5. OS hardening 4. Primitives for Isolation/mediation 3. Principles + models 2. design 1. Threats 0. Intro 0. Introduction Operating systems and VMs are old Much of the groundwork was done in the 60s and 70s Interest in security grew when multiple security domains became important We will see the origin and importance of principles and security primitives Early OSs such as Multics pioneered many of these in a working system Much has stayed the same, much has changed Old days: security mostly focused on isolating (classes of) users from each
    [Show full text]
  • OS Security Memory
    OS Security Memory Radboud University, Nijmegen, The Netherlands Winter 2016/2017 I Cannot do that for reading/writing memory I Load/store instructions are very frequent in programs I Speed of memory access largely determines the speed of many programs I System calls are expensive I A load (from cache) can nish in a few cycles I A system call has some hundred cycles overhead I OS still needs control over memory access of processes! Memory access I So far, all access to resources was handled through le-access permissions I Requesting a resource (le) is done through syscalls OS Security Memory2 I A load (from cache) can nish in a few cycles I A system call has some hundred cycles overhead I OS still needs control over memory access of processes! Memory access I So far, all access to resources was handled through le-access permissions I Requesting a resource (le) is done through syscalls I Cannot do that for reading/writing memory I Load/store instructions are very frequent in programs I Speed of memory access largely determines the speed of many programs I System calls are expensive OS Security Memory2 I OS still needs control over memory access of processes! Memory access I So far, all access to resources was handled through le-access permissions I Requesting a resource (le) is done through syscalls I Cannot do that for reading/writing memory I Load/store instructions are very frequent in programs I Speed of memory access largely determines the speed of many programs I System calls are expensive I A load (from cache) can nish in a few
    [Show full text]
  • Paravirtualizing Linux in a Real-Time Hypervisor
    Paravirtualizing Linux in a real-time hypervisor Vincent Legout and Matthieu Lemerre CEA, LIST, Embedded Real Time Systems Laboratory Point courrier 172, F-91191 Gif-sur-Yvette, FRANCE {vincent.legout,matthieu.lemerre}@cea.fr ABSTRACT applications written for a fully-featured operating system This paper describes a new hypervisor built to run Linux in a such as Linux. The Anaxagoros design prevent non real- virtual machine. This hypervisor is built inside Anaxagoros, time tasks to interfere with real-time tasks, thus providing a real-time microkernel designed to execute safely hard real- the security foundation to build a hypervisor to run existing time and non real-time tasks. This allows the execution of non real-time applications. This allows current applications hard real-time tasks in parallel with Linux virtual machines to run on Anaxagoros systems without any porting effort, without interfering with the execution of the real-time tasks. opening the access to a wide range of applications. We implemented this hypervisor and compared perfor- Furthermore, modern computers are powerful enough to mances with other virtualization techniques. Our hypervisor use virtualization, even embedded processors. Virtualiza- does not yet provide high performance but gives correct re- tion has become a trendy topic of computer science, with sults and we believe the design is solid enough to guarantee its advantages like scalability or security. Thus we believe solid performances with its future implementation. that building a real-time system with guaranteed real-time performances and dense non real-time tasks is an important topic for the future of real-time systems.
    [Show full text]
  • PC Hardware Contents
    PC Hardware Contents 1 Computer hardware 1 1.1 Von Neumann architecture ...................................... 1 1.2 Sales .................................................. 1 1.3 Different systems ........................................... 2 1.3.1 Personal computer ...................................... 2 1.3.2 Mainframe computer ..................................... 3 1.3.3 Departmental computing ................................... 4 1.3.4 Supercomputer ........................................ 4 1.4 See also ................................................ 4 1.5 References ............................................... 4 1.6 External links ............................................. 4 2 Central processing unit 5 2.1 History ................................................. 5 2.1.1 Transistor and integrated circuit CPUs ............................ 6 2.1.2 Microprocessors ....................................... 7 2.2 Operation ............................................... 8 2.2.1 Fetch ............................................. 8 2.2.2 Decode ............................................ 8 2.2.3 Execute ............................................ 9 2.3 Design and implementation ...................................... 9 2.3.1 Control unit .......................................... 9 2.3.2 Arithmetic logic unit ..................................... 9 2.3.3 Integer range ......................................... 10 2.3.4 Clock rate ........................................... 10 2.3.5 Parallelism .........................................
    [Show full text]
  • CIS 3207 - Operating Systems CPU Mode
    CIS 3207 - Operating Systems CPU Mode Professor Qiang Zeng Spring 2018 CPU Modes • Two common modes – Kernel mode • The CPU has to be in this mode to execute the kernel code – User mode • The CPU has to be in this mode to execute the user code CIS 3207 – Operating Systems 2 Important questions • How are CPU modes implemented? • Why are CPU modes needed? • Difference between Kernel mode and User mode • How are system calls implemented? • Advanced topic: Virtualization CIS 3207 – Operating Systems 3 How CPU Modes are implemented • Implemented through protection rings – A modern CPU typical provides different protection rings, which represent different privilege levels • A ring with a lower number has higher privileges – Introduced by Multics in 60’s – E.g., an X86 CPU usually provides four rings, and a Linux/Unix/Windows OS uses Ring 0 for the kernel mode and Ring 3 for the user mode CIS 3207 – Operating Systems 4 Why are Protection Rings needed? • Fault isolation: a fault (e.g., divided by 0) in the code running in a less-privileged ring can be captured and handled by code in a more-privileged ring • Privileged instructions: certain instructions can only be issued in a privileged ring; thus an OS can implement resource management and isolation here • Privileged memory space: certain memory can only be accessed in a privileged ring All these are demonstrated in the difference between the kernel mode and the user mode CIS 3207 – Operating Systems 5 Kernel Mode vs. User Mode? • A fault in the user space (e.g., divided by zero, invalid access,
    [Show full text]
  • Ciena Acronyms Guide.Pdf
    The Acronyms Guide edited by Erin Malone Chris Janson 1st edition Publisher Acknowledgement: This is the first edition of this book. Please notify us of any acronyms we may have missed by submitting them via the form at www.ciena.com/acronymsguide. We will be happy to include them in further editions of “The Acronyms Guide”. For additional information on Ciena’s Carrier Ethernet or Optical Communications Certification programs please contact [email protected]. Table of Contents Numerics ..........................1 A .......................................1 B .......................................2 C .......................................3 D .......................................5 E .......................................7 F........................................9 G .....................................10 H .....................................11 I .......................................12 J ......................................14 K .....................................14 L ......................................14 M ....................................15 N .....................................17 O.....................................18 P .....................................20 Q.....................................22 R .....................................22 S......................................23 T .....................................26 U .....................................28 V .....................................29 W ....................................29 X .....................................30 Z......................................30
    [Show full text]
  • Virtualization
    OS Security Virtualization Radboud University Nijmegen, The Netherlands Winter 2015/2016 Announcement I No lecture on January 5, 2016 I Werkcollege will take place as usual (Wednesday, January 6) I Next lecture will be on January 12 I Enjoy the holidays! 1 I Post-Snowden Crypto workshop , Dec 9-10, Brussels 2 I 32C3 , Dec 27-30, Hamburg 1https://hyperelliptic.org/PSC/ 2https://events.ccc.de/congress/2015/wiki/Main_Page OS Security – Virtualization2 A short recap I Last 2 lectures: Malware I Malware evolution from PC to smartphone I Early days: malware targeting Symbian OS users (Cabir, Pbstealer) I Popular smartphone platforms affected I Android: first proof-of-concept malware released in 2008 I iOS: WireLurker I Windows Phone: FinSpy Mobile I Blackberry: Trojans using the ‘Backstab’ technique I Intrusion detection system I NIDS, HIDS I NIDS: (i) string, (ii) port and (iii) header condition signatures I HIDS: signature- and behaviour-based I Intrusion prevention system I NIPS, HIPS I (i) signature-based detection, (ii) anomaly-based detection and (iii) protocol state analysis detection OS Security – Virtualization3 Role of the OS I A major job of the OS is to enforce protection I Prevent malicious (or buggy) programs from: I Allocating too many resources (denial of service) I Corrupting or overwriting shared resources (files, shared memory,...) I Prevent different users, groups, etc. from: I Accessing or modifying private state (files, shared memory,...) I Killing each other’s processes I Prevent viruses, worms, etc. from exploiting security
    [Show full text]