DOCSLIB.ORG

Roee Shimon Leon

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Roee Shimon Leon JYU DISSERTATIONS 132 Roee Shimon Leon Applications of Hypervisors in Security JYU DISSERTATIONS 132 Roee Shimon Leon Applications of Hypervisors in Security Esitetään Jyväskylän yliopiston informaatioteknologian tiedekunnan suostumuksella julkisesti tarkastettavaksi yliopiston vanhassa juhlasalissa S212 lokakuun 24. päivänä 2019 kello 10. Academic dissertation to be publicly discussed, by permission of the Faculty of Information Technology of the University of Jyväskylä, in building Seminarium, auditorium S212, on October 24, 2019 at 10 o’clock. JYVÄSKYLÄ 2019 Editors Timo Männikkö Faculty of Information Technology, University of Jyväskylä Ville Korkiakangas Open Science Centre, University of Jyväskylä Copyright © 2019, by University of Jyväskylä Permanent link to this publication: http://urn.fi/URN:ISBN:978-951-39-7854-9 ISBN 978-951-39-7854-9 (PDF) URN:ISBN:978-951-39-7854-9 ISSN 2489-9003 ABSTRACT Leon, Roee Shimon Applications of Hypervisors in Security Jyväskylä: University of Jyväskylä, 2019, 88 p. (+ included articles) (JYU Dissertations ISSN 2489-9003; 132) ISBN 978-951-39-7854-9 (PDF) Finnish summary Diss. As malware continue to evolve, so do the countermeasures which attempt to fight them. A modern computer system typically has many security services installed on top of its operating system which include antivirus, application-control, IDS, firewall, and many more. Modern operating systems are a highly complex pieces of software which typically contains millions of lines of code. Furthermore, primarily due to endless hardware support, new code is regularly added, resulting in a security sink with an open drain. Most security services run on top of the operating system and, therefore, are subject to the security of the operating system and its applications. In case of a vulnerability, these services can be removed, thus rendering them them com- pletely useless. This thesis proposes a thin hypervisor-based architecture for a system on top of which a variety of security services can be implemented. These services run in a secure, isolated environment. Furthermore, the proposed system can hide the presence of these security services. The proposed system architec- ture provides strong security guarantees. The thesis presents four common, heavily researched security problems and proposes four solutions, which are all based on the proposed architecture. The proposed solutions can compete, and even outperform current solutions, both in terms of security and performance. Keywords: trusted computing, virtualization, hypervisor, thin hypervisor, unau- thorised execution, malware analysis, code encryption, memory foren- sics TIIVISTELMÄ (ABSTRACT IN FINNISH) Leon, Roee Shimon Hyperviisoreiden sovelluksia tietoturvassa Jyväskylä: University of Jyväskylä, 2019, 88 s. (+artikkelit) (JYU Dissertations ISSN 2489-9003; 132) ISBN 978-951-39-7854-9 (PDF) Haittaohjelmien kehittyessä, myös vastatoimet niitä vastaan kehittyvät yhä kiih- tyvällä tahdilla. Nykyaikaisessa tietokonejärjestelmässä on tyypillisesti käyttöjär- jestelmän päälle asennettu useita tietoturvapalveluita, jotka sisältävät esimerkiksi virustentorjunta-, sovellusohjaus-, IDS-, palomuuri ja muita suojausmekanisme- ja. Nykyaikaiset käyttöjärjestelmät ovat erittäin monimutkaisia ohjelmistopa- ketteja, jotka sisältävät tyypillisesti miljoonia koodirivejä. Lisäksi, pääasiassa val- tavan laitteistotuen vuoksi, uutta koodia lisätään säännöllisesti, mistä seuraa tie- toturvariskejä. Useimmat tietoturvapalvelut toimivat käyttöjärjestelmän päällä, ja siksi ne ovat käyttöjärjestelmän ja sen sovellusten turvallisuuden osia. Haavoittuvuuden vuoksi nämä palvelut voidaan poistaa, jolloin ne eivät tietenkään ole käytössä ja ovat siten täysin hyödyttömiä. Tämä opinnäyte ehdottaa ohuita hypervisori- pohjaisia arkkitehtuureja järjestelmälle, jonka päälle voidaan toteuttaa erilaisia turvallisuuspalveluita. Nämä palvelut toimivat turvallisessa, eristetyssä ympä- ristössä. Lisäksi ehdotettu järjestelmä voi piilottaa näiden tietoturvapalvelujen näkyvyyden. Ehdotettu järjestelmäarkkitehtuuri tarjoaa siten vahvat turvallisuus- takuut. Opinnäytetyössä esitetään neljä yleistä tutkittua turvallisuusongelmaa ja ehdotetaan niille neljää ratkaisuvaihtoehtoa, jotka kaikki perustuvat työssä suun- niteltuun arkkitehtuuriin. Ehdotetut ratkaisut voivat kilpailla ja toimia tehok- kaammin kuin nykyiset ratkaisut sekä turvallisuuden että suorituskyvyn kan- nalta. Avainsanat: luotettava tietojenkäsittely, virtualisointi, hypervisori (virtuaalikonemonitori), luvattomat suoritukset, haittaohjelman analyysi, koodin salaus, muistin analyysi Author Roee Shimon Leon Faculty of Information Technology University of Jyväskylä Finland Supervisors Professor Pekka Neittaanmäki Faculty of Information Technology University of Jyväskylä Finland Doctor Nezer Zaidenberg Faculty of Information Technology University of Jyväskylä Finland Reviewers Professor Vincenzo Piuri Dept. of Computer Science University of Milan Italy Associate Professor, Dr. Jalil Boukhobza Lab-STICC Lab. / Dept. of Computer Science University of Western Brittany France Opponent Associate Professor, Dr. Miguel Correia Dept. of Informatics University of Lisbon Portugal ACKNOWLEDGEMENTS First, I would like to express my sincere gratitude to my supervisors, Prof. Pekka Neittaanmäki and Docent Nezer Jacob Zaidenberg, for their guidance and sup- port throughout the process of this thesis. In addition, I would like to thank my external reviewers for their valuable insights. I am also immensely grateful to Michael Kiperberg, Anat Anatey Leon Zabag, Amit Resh, and Asaf Algawi for co-authoring the joint publications in- cluded in this thesis. I want to thank the COMAS Graduate School, which partially funded this research. Furthermore, I would like to thank the University of Jyväskylä staff for being so responsive and helpful during my years as a Ph.D. student. I wish to thank my beloved wife, Anat Anatey, without whom this thesis would not have been possible, for her continuous moral support, co-authoring, and help. Finally, I want to thank my parents, Anat and Eyal, for their love and sup- port throughout my entire life, not least during my work on this thesis. LIST OF FIGURES FIGURE 1 The Common Architecture of Our Method .............................. 22 FIGURE 2 The Transition from Guest to Host and Vice Versa.................... 28 FIGURE 3 Thin Hypervisor ................................................................... 29 FIGURE 4 Thin Hypervisor Security – Cache Eviction ............................. 36 FIGURE 5 Address Translation in the Guest and the Hypervisor............... 36 FIGURE 6 Last Level Cache Organisation Example.................................. 36 FIGURE 7 Thin Hypervisor Memory Modifications Transparency............. 38 FIGURE 8 Thin Hypervisor Performance – PCMark ................................ 40 FIGURE 9 Thin Hypervisor Performance – PassMark .............................. 40 FIGURE 10 Thin Hypervisor Performance – Novabench ............................ 41 FIGURE 11 Memory Forensics – Performance Degradation Due to Mem- ory Acquisition..................................................................... 44 FIGURE 12 Malware Analysis – NtOpenFile 3rd Parameter Information Hierarchy in an x86 Windows System ..................................... 48 FIGURE 13 Malware Analysis – Sandbox Configuration File Example for Windows 7 x86 .................................................................... 48 FIGURE 14 Malware Analysis – Windows Memory Layout After Writing to SYSENTER_EIP msr .......................................................... 50 FIGURE 15 Malware Analysis – Overhead Performance Impact ................. 53 FIGURE 16 Unauthorised Execution Prevention – Scanning of a User Space Executable Image.................................................................. 55 FIGURE 17 Unauthorised Execution Prevention – Page Verification Over- head .................................................................................... 57 FIGURE 18 Unauthorised Execution Prevention – Overall Performance Over- head .................................................................................... 58 FIGURE 19 Preventing Reverse Engineering of Software – Virtual Address Space Layouts of the Hypervisor and the Guest during Pro- tected Function Execution...................................................... 60 FIGURE 20 Preventing Reverse Engineering of Software – First Experi- ment Performance Results ..................................................... 64 FIGURE 21 Preventing Reverse Engineering of Software – Second Experi- ment Performance Results 1................................................... 65 FIGURE 22 Preventing Reverse Engineering of Software – Second Experi- ment Performance Results 2................................................... 65 FIGURE 23 Preventing Reverse Engineering of Software – Third Test Per- formance Results 1 ................................................................ 66 LIST OF TABLES TABLE 1 Preventing Reverse Engineering of Software – Third Test Per- formance Results 2 ................................................................ 66 TABLE 2 Preventing Reverse Engineering of Software – Third Test Per- formance Results 3 ................................................................ 67 LIST OF ALGORITHMS ALGORITHM 1 BIOS Memory Allocation and the Hypervisor’s Memory Map Interception Functions ............................................ 32 ALGORITHM 2 Thin Hypervisor Initialisation ........................................
Load more

Recommended publications
  • Operating System Boot from Fully Encrypted Device
    Masaryk University Faculty of Informatics Operating system boot from fully encrypted device Bachelor’s Thesis Daniel Chromik Brno, Fall 2016 Replace this page with a copy of the official signed thesis assignment and the copy of the Statement of an Author. Declaration Hereby I declare that this paper is my original authorial work, which I have worked out by my own. All sources, references and literature used or excerpted during elaboration of this work are properly cited and listed in complete reference to the due source. Daniel Chromik Advisor: ing. Milan Brož i Acknowledgement I would like to thank my advisor, Ing. Milan Brož, for his guidance and his patience of a saint. Another round of thanks I would like to send towards my family and friends for their support. ii Abstract The goal of this work is description of existing solutions for boot- ing Linux and Windows from fully encrypted devices with Secure Boot. Before that, though, early boot process and bootloaders are de- scribed. A simple Linux distribution is then set up to boot from a fully encrypted device. And lastly, existing Windows encryption solutions are described. iii Keywords boot process, Linux, Windows, disk encryption, GRUB 2, LUKS iv Contents 1 Introduction ............................1 1.1 Thesis goals ..........................1 1.2 Thesis structure ........................2 2 Boot Process Description ....................3 2.1 Early Boot Process ......................3 2.2 Firmware interfaces ......................4 2.2.1 BIOS – Basic Input/Output System . .4 2.2.2 UEFI – Unified Extended Firmware Interface .5 2.3 Partitioning tables ......................5 2.3.1 MBR – Master Boot Record .
    [Show full text]
  • White Paper: Indestructible Firewall in a Box V1.0 Nick Mccubbins
    White Paper: Indestructible Firewall In A Box v1.0 Nick McCubbins 1.1 Credits • Nathan Yawn ([email protected]) 1.2 Acknowledgements • Firewall-HOWTO • Linux Router Project • LEM 1.3 Revision History • Version 1.0 First public release 1.4 Feedback • Send all information and/or criticisms to [email protected] 1.5 Distribution Policy 2 Abstract In this document, the procedure for creating an embedded firewall whose root filesystem is loaded from a flash disk and then executed from a RAMdisk will be illustrated. A machine such as this has uses in many environments, from corporate internet access to sharing of a cable modem or xDSL connection among many computers. It has the advantages of being very light and fast, being impervious to filesystem corruption due to power loss, and being largely impervious to malicious crackers. The type of firewall illustrated herein is a simple packet-filtering, masquerading setup. Facilities for this already exist in the Linux kernel, keeping the system's memory footprint small. As such the device lends itself to embedding very well. For a more detailed description of firewall particulars, see the Linux Firewall-HOWTO. 3 Equipment This project has minimal hardware requirements. An excellent configuration consists of: For a 100-baseT network: • SBC-554 Pentium SBC with PISA bus and on-board PCI NIC (http://www.emacinc.com/pc.htm#pentiumsbc), approx. $373 • PISA backplane, chassis, power supply (http://www.emacinc.com/sbcpc_addons/mbpc641.htm), approx. $305 • Second PCI NIC • 32 MB RAM • 4 MB M-Systems Flash Disk (minimum), approx. $45 For a 10-baseT network: • EMAC's Standard Server-in-a-Box product (http://www.emacinc.com/server_in_a_box.htm), approx.
    [Show full text]
  • Chapter 3. Booting Operating Systems
    Chapter 3. Booting Operating Systems Abstract: Chapter 3 provides a complete coverage on operating systems booting. It explains the booting principle and the booting sequence of various kinds of bootable devices. These include booting from floppy disk, hard disk, CDROM and USB drives. Instead of writing a customized booter to boot up only MTX, it shows how to develop booter programs to boot up real operating systems, such as Linux, from a variety of bootable devices. In particular, it shows how to boot up generic Linux bzImage kernels with initial ramdisk support. It is shown that the hard disk and CDROM booters developed in this book are comparable to GRUB and isolinux in performance. In addition, it demonstrates the booter programs by sample systems. 3.1. Booting Booting, which is short for bootstrap, refers to the process of loading an operating system image into computer memory and starting up the operating system. As such, it is the first step to run an operating system. Despite its importance and widespread interests among computer users, the subject of booting is rarely discussed in operating system books. Information on booting are usually scattered and, in most cases, incomplete. A systematic treatment of the booting process has been lacking. The purpose of this chapter is to try to fill this void. In this chapter, we shall discuss the booting principle and show how to write booter programs to boot up real operating systems. As one might expect, the booting process is highly machine dependent. To be more specific, we shall only consider the booting process of Intel x86 based PCs.
    [Show full text]
  • Kernel Boot-Time Tracing
    Kernel Boot-time Tracing Linux Plumbers Conference 2019 - Tracing Track Masami Hiramatsu <[email protected]> Linaro, Ltd. Speaker Masami Hiramatsu - Working for Linaro and Linaro members - Tech Lead for a Landing team - Maintainer of Kprobes and related tracing features/tools Why Kernel Boot-time Tracing? Debug and analyze boot time errors and performance issues - Measure performance statistics of kernel boot - Analyze driver init failure - Debug boot up process - Continuously tracing from boot time etc. What We Have There are already many ftrace options on kernel command line ● Setup options (trace_options=) ● Output to printk (tp_printk) ● Enable events (trace_events=) ● Enable tracers (ftrace=) ● Filtering (ftrace_filter=,ftrace_notrace=,ftrace_graph_filter=,ftrace_graph_notrace=) ● Add kprobe events (kprobe_events=) ● And other options (alloc_snapshot, traceoff_on_warning, ...) See Documentation/admin-guide/kernel-parameters.txt Example of Kernel Cmdline Parameters In grub.conf linux /boot/vmlinuz-5.1 root=UUID=5a026bbb-6a58-4c23-9814-5b1c99b82338 ro quiet splash tp_printk trace_options=”sym-addr” trace_clock=global ftrace_dump_on_oops trace_buf_size=1M trace_event=”initcall:*,irq:*,exceptions:*” kprobe_event=”p:kprobes/myevent foofunction $arg1 $arg2;p:kprobes/myevent2 barfunction %ax” What Issues? Size limitation ● kernel cmdline size is small (< 256bytes) ● A half of the cmdline is used for normal boot Only partial features supported ● ftrace has too complex features for single command line ● per-event filters/actions, instances, histograms. Solutions? 1. Use initramfs - Too late for kernel boot time tracing 2. Expand kernel cmdline - It is not easy to write down complex tracing options on bootloader (Single line options is too simple) 3. Reuse structured boot time data (Devicetree) - Well documented, structured data -> V1 & V2 series based on this. Boot-time Trace: V1 and V2 series V1 and V2 series posted at June.
    [Show full text]
  • Network Boot and Exotic Root HOWTO
    Network Boot and Exotic Root HOWTO Brieuc Jeunhomme frtest [email protected] Logilab S.A. Revision History Revision 0.3 2002−04−28 Revised by: bej Many feedback inclusions, added links to several projects Revision 0.2.2 2001−12−08 Revised by: dcm Licensed GFDL Revision 0.2.1 2001−05−21 Revised by: logilab Fixed bibliography and artheader Revision 0.2 2001−05−19 Revised by: bej Many improvements and included Ken Yap's feedback. Revision 0.1.1 2001−04−09 Revised by: logilab First public draft. Revision 0.1 2000−12−09 Revised by: bej Initial draft. This document explains how to quickly setup a linux server to provide what diskless linux clients require to get up and running, using an IP network. It includes data and partly rewritten text from the Diskless−HOWTO, the Diskless−root−NFS−HOWTO, the linux kernel documentation, the etherboot project's documentation, the linux terminal server project's homepage, and the author's personal experience, acquired when working for Logilab. Eventually this document may end up deprecating the Diskless−HOWTO and Diskless−root−NFS−HOWTO. Please note that you'll also find useful information in the From−PowerUp−to−bash−prompt−HOWTO and the Thin−Client−HOWTO, and the Claus−Justus Heine's page about NFS swapping. Network Boot and Exotic Root HOWTO Table of Contents 1. Introduction.....................................................................................................................................................1 1.1. What is this all about?.......................................................................................................................1 1.2. Thanks...............................................................................................................................................1 1.3. Diskless booting advocacy................................................................................................................1 1.3.1. Buying is cheaper than building.......................................................................................1 1.3.2.
    [Show full text]
  • Hiding Process Memory Via Anti-Forensic Techniques
    DIGITAL FORENSIC RESEARCH CONFERENCE Hiding Process Memory via Anti-Forensic Techniques By: Frank Block (Friedrich-Alexander Universität Erlangen-Nürnberg (FAU) and ERNW Research GmbH) and Ralph Palutke (Friedrich-Alexander Universität Erlangen-Nürnberg) From the proceedings of The Digital Forensic Research Conference DFRWS USA 2020 July 20 - 24, 2020 DFRWS is dedicated to the sharing of knowledge and ideas about digital forensics research. Ever since it organized the first open workshop devoted to digital forensics in 2001, DFRWS continues to bring academics and practitioners together in an informal environment. As a non-profit, volunteer organization, DFRWS sponsors technical working groups, annual conferences and challenges to help drive the direction of research and development. https://dfrws.org Forensic Science International: Digital Investigation 33 (2020) 301012 Contents lists available at ScienceDirect Forensic Science International: Digital Investigation journal homepage: www.elsevier.com/locate/fsidi DFRWS 2020 USA d Proceedings of the Twentieth Annual DFRWS USA Hiding Process Memory Via Anti-Forensic Techniques Ralph Palutke a, **, 1, Frank Block a, b, *, 1, Patrick Reichenberger a, Dominik Stripeika a a Friedrich-Alexander Universitat€ Erlangen-Nürnberg (FAU), Germany b ERNW Research GmbH, Heidelberg, Germany article info abstract Article history: Nowadays, security practitioners typically use memory acquisition or live forensics to detect and analyze sophisticated malware samples. Subsequently, malware authors began to incorporate anti-forensic techniques that subvert the analysis process by hiding malicious memory areas. Those techniques Keywords: typically modify characteristics, such as access permissions, or place malicious data near legitimate one, Memory subversion in order to prevent the memory from being identified by analysis tools while still remaining accessible.
    [Show full text]
  • Improving the Performance of Hybrid Main Memory Through System Aware Management of Heterogeneous Resources
    IMPROVING THE PERFORMANCE OF HYBRID MAIN MEMORY THROUGH SYSTEM AWARE MANAGEMENT OF HETEROGENEOUS RESOURCES by Juyoung Jung B.S. in Information Engineering, Korea University, 2000 Master in Computer Science, University of Pittsburgh, 2013 Submitted to the Graduate Faculty of the Kenneth P. Dietrich School of Arts and Sciences in partial fulfillment of the requirements for the degree of Doctor of Philosophy in Computer Science University of Pittsburgh 2016 UNIVERSITY OF PITTSBURGH KENNETH P. DIETRICH SCHOOL OF ARTS AND SCIENCES This dissertation was presented by Juyoung Jung It was defended on December 7, 2016 and approved by Rami Melhem, Ph.D., Professor at Department of Computer Science Bruce Childers, Ph.D., Professor at Department of Computer Science Daniel Mosse, Ph.D., Professor at Department of Computer Science Jun Yang, Ph.D., Associate Professor at Electrical and Computer Engineering Dissertation Director: Rami Melhem, Ph.D., Professor at Department of Computer Science ii IMPROVING THE PERFORMANCE OF HYBRID MAIN MEMORY THROUGH SYSTEM AWARE MANAGEMENT OF HETEROGENEOUS RESOURCES Juyoung Jung, PhD University of Pittsburgh, 2016 Modern computer systems feature memory hierarchies which typically include DRAM as the main memory and HDD as the secondary storage. DRAM and HDD have been extensively used for the past several decades because of their high performance and low cost per bit at their level of hierarchy. Unfortunately, DRAM is facing serious scaling and power consumption problems, while HDD has suffered from stagnant performance improvement and poor energy efficiency. After all, computer system architects have an implicit consensus that there is no hope to improve future system’s performance and power consumption unless something fundamentally changes.
    [Show full text]
  • Review Der Linux Kernel Sourcen Von 4.9 Auf 4.10
    Review der Linux Kernel Sourcen von 4.9 auf 4.10 Reviewed by: Tested by: stecan stecan Period of Review: Period of Test: From: Thursday, 11 January 2018 07:26:18 o'clock +01: From: Thursday, 11 January 2018 07:26:18 o'clock +01: To: Thursday, 11 January 2018 07:44:27 o'clock +01: To: Thursday, 11 January 2018 07:44:27 o'clock +01: Report automatically generated with: LxrDifferenceTable, V0.9.2.548 Provided by: Certified by: Approved by: Account: stecan Name / Department: Date: Friday, 4 May 2018 13:43:07 o'clock CEST Signature: Review_4.10_0_to_1000.pdf Page 1 of 793 May 04, 2018 Review der Linux Kernel Sourcen von 4.9 auf 4.10 Line Link NR. Descriptions 1 .mailmap#0140 Repo: 9ebf73b275f0 Stephen Tue Jan 10 16:57:57 2017 -0800 Description: mailmap: add codeaurora.org names for nameless email commits ----------- Some codeaurora.org emails have crept in but the names don't exist for them. Add the names for the emails so git can match everyone up. Link: http://lkml.kernel.org/r/[email protected] 2 .mailmap#0154 3 .mailmap#0160 4 CREDITS#2481 Repo: 0c59d28121b9 Arnaldo Mon Feb 13 14:15:44 2017 -0300 Description: MAINTAINERS: Remove old e-mail address ----------- The ghostprotocols.net domain is not working, remove it from CREDITS and MAINTAINERS, and change the status to "Odd fixes", and since I haven't been maintaining those, remove my address from there. CREDITS: Remove outdated address information ----------- This address hasn't been accurate for several years now.
    [Show full text]
  • Sbadmin for Linux System Recovery Guide Is a Supplement to the Sbadmin User Guide, Providing Details on Reinstalling a Linux System from a Sbadmin System Backup
    Linux System Recovery Guide Version 8.2 Trademarks and Copyrights © Copyright Storix, Inc. 1999-2021 SBAdmin is a registered trademark of Storix, Inc. SBAdmin is a trademark of Storix, Inc in the USA and other countries Intel is a registered trademark of Intel, Inc. Linux is a registered trademark of Linus Torvalds. Intel, Pentium, IA32, Itanium, Celeron and IA64 are registered trademarks of Intel Corporation. AMD, Opteron, and Athlon are registered trademarks of Advanced Micro Devices. HP Integrity servers are registered trademarks of Hewlett-Packard Development Company. Publicly Available Software This product either includes or is developed using source code that is publicly available: AESCrypt* Rijndael and Cipher Block Feedback Copyright 1999, 2000 Enhanced Software Technologies Inc. mode (CFB-128) encryption/decryption http://aescrypt.sourceforge.net/ algorithms BusyBox Single executable containing tiny Copyright 1989, 1991 Free Software Foundation, Inc. versions of common UNIX utilities http://busybox.net/cgi-bin/cvsweb/busybox/ LILO LInux boot Loader Copyright 1999-2003 John Coffman. Copyright 1992-1998 Werner Almesberger. http://freshmeat.net/projects/lilo/ Tcl Open source scripting language Copyright Regents of the University of California, Sun Microsystems, Inc. http://tcl.sourceforge.net Tk Tk graphics toolkit Copyright Regents of the University of California, Sun Microsystems, Inc. http://tcl.sourceforge.net DropBear A Smallish SSH 2 Server and Client Copyright 2002, 2003 Matt Johnston http://www.matt.ucc.asn.au/dropbear/dropbear.html GRUB Grand Unified Bootloader (GNU GRUB) Copyright 1989, 1991 Free Software Foundation, Inc. http://www.gnu.org/software/grub/grub.html Lighttpd Secure, fast, compliant and flexible Copyright 2004 Jan Kneschkle, incremental web-server http://www.lighttpd.net OpenSSL Toolkit implementing Secure Socket Copyright 1998-2008 The OpenSSL Project Layer Copyright 1995-1998 Eric A.
    [Show full text]
  • Thread Scheduling in Multi-Core Operating Systems Redha Gouicem
    Thread Scheduling in Multi-core Operating Systems Redha Gouicem To cite this version: Redha Gouicem. Thread Scheduling in Multi-core Operating Systems. Computer Science [cs]. Sor- bonne Université, 2020. English. tel-02977242 HAL Id: tel-02977242 https://hal.archives-ouvertes.fr/tel-02977242 Submitted on 24 Oct 2020 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Ph.D thesis in Computer Science Thread Scheduling in Multi-core Operating Systems How to Understand, Improve and Fix your Scheduler Redha GOUICEM Sorbonne Université Laboratoire d’Informatique de Paris 6 Inria Whisper Team PH.D.DEFENSE: 23 October 2020, Paris, France JURYMEMBERS: Mr. Pascal Felber, Full Professor, Université de Neuchâtel Reviewer Mr. Vivien Quéma, Full Professor, Grenoble INP (ENSIMAG) Reviewer Mr. Rachid Guerraoui, Full Professor, École Polytechnique Fédérale de Lausanne Examiner Ms. Karine Heydemann, Associate Professor, Sorbonne Université Examiner Mr. Etienne Rivière, Full Professor, University of Louvain Examiner Mr. Gilles Muller, Senior Research Scientist, Inria Advisor Mr. Julien Sopena, Associate Professor, Sorbonne Université Advisor ABSTRACT In this thesis, we address the problem of schedulers for multi-core architectures from several perspectives: design (simplicity and correct- ness), performance improvement and the development of application- specific schedulers.
    [Show full text]
  • Embedded Linux Conference Europe 2019
    Embedded Linux Conference Europe 2019 Linux kernel debugging: going beyond printk messages Embedded Labworks By Sergio Prado. São Paulo, October 2019 ® Copyright Embedded Labworks 2004-2019. All rights reserved. Embedded Labworks ABOUT THIS DOCUMENT ✗ This document is available under Creative Commons BY- SA 4.0. https://creativecommons.org/licenses/by-sa/4.0/ ✗ The source code of this document is available at: https://e-labworks.com/talks/elce2019 Embedded Labworks $ WHOAMI ✗ Embedded software developer for more than 20 years. ✗ Principal Engineer of Embedded Labworks, a company specialized in the development of software projects and BSPs for embedded systems. https://e-labworks.com/en/ ✗ Active in the embedded systems community in Brazil, creator of the website Embarcados and blogger (Portuguese language). https://sergioprado.org ✗ Contributor of several open source projects, including Buildroot, Yocto Project and the Linux kernel. Embedded Labworks THIS TALK IS NOT ABOUT... ✗ printk and all related functions and features (pr_ and dev_ family of functions, dynamic debug, etc). ✗ Static analysis tools and fuzzing (sparse, smatch, coccinelle, coverity, trinity, syzkaller, syzbot, etc). ✗ User space debugging. ✗ This is also not a tutorial! We will talk about a lot of tools and techniches and have fun with some demos! Embedded Labworks DEBUGGING STEP-BY-STEP 1. Understand the problem. 2. Reproduce the problem. 3. Identify the source of the problem. 4. Fix the problem. 5. Fixed? If so, celebrate! If not, go back to step 1. Embedded Labworks TYPES OF PROBLEMS ✗ We can consider as the top 5 types of problems in software: ✗ Crash. ✗ Lockup. ✗ Logic/implementation error. ✗ Resource leak. ✗ Performance.
    [Show full text]
  • Walking the Linux Kernel
    Walking the Linux Kernel Stanislav Kozina Associate Manager April 2016 AGENDA Linux Kernel in general Debugging kernel issues without crash Prepare the system for crashing Crash it with systemtap See what we can get from the crash dump 2 Linux Kernel in general – boring ● Just software… ● Written in C & asm ● List of expected features ● Boot and initialization process ● Memory and process management ● Hardware abstraction ● Files, directories, sockets, … ● Resources abstraction ● CPU, memory, … ● POSIX 3 Linux Kernel in general – BUT! ● Quite big (20mil LOC) ● No libc (many other standards functions instead) ● Special environment ● Preemptive, shared memory space ● Early boot code is tricky ● No dynamic allocator, AP, scheduler, even locks! ● Special security requirements ● Kernel should not just die and/or leak anything 4 Linux Kernel in general – development system ● Open source ● List of maintainers in MAINTAINERS ● Patches posted via email ● Documentation/SubmittingPatches ● LKML ● Usually companies care about support of their stuff ● Hardware vendors… ● “We don't break userland” 5 DIGGING IN Observing kernel is not trivial ● Hard to get a consistent picture ● If we stop it, how we observe it? ● Using Vms? ● printk() ● Statistics, /proc, perf, strace, ftrace, ... 7 8 Debugging kernel issues ● Oops messages ● Message buffer, registers, stack/backtrace ● Oops leaves the system running, but unstable! ● Current task is killed ● Printk() ● Systemtap, ftrace ● crash ● Sysrq triggers 9 Kernel oops [[ 32.580355]32.580355] SysRqSysRq :: TriggerTrigger aa crashcrash [[ 32.581331]32.581331] BUG:BUG: unableunable toto handlehandle kernelkernel NULLNULL pointerpointer dereferencedereference atat [[ 32.582703]32.582703] IP:IP: [<ffffffff813b9716>][<ffffffff813b9716>] sysrq_handle_crash+0x16/0x20sysrq_handle_crash+0x16/0x20 [[ 32.583781]32.583781] PGDPGD 3b5030673b503067 PUDPUD 3b5020673b502067 PMDPMD 00 [[ 32.584609]32.584609] Oops:Oops: 00020002 [#1][#1] SMPSMP [[ 32.585210]32.585210] ModulesModules linkedlinked in:in: ip6t_rpfilterip6t_rpfilter (...(..
    [Show full text]