DOCSLIB.ORG

Proceedings In

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Proceedings In AsiaBSDCon 2019 Proceedings March 21-24, 2019 Tokyo, Japan Copyright c 2019 BSD Research. All rights reserved. Unauthorized republication is prohibited. Published in Japan, March 2019 INDEX P01A: Adventure in DRMland Or how to write a FreeBSD ARM64 009 DRM Driver Emmanuel Vadot P01B: Removing ROP Gadgets from OpenBSD 013 Todd Mortimer P02A: Powerpc64 Architecture Support in FreeBSD Ports 023 Piotr Kubaj P02B: Design and Implementation of NetBSD Base System 031 Package Distribution Service Ken’ichi Fukamachi, Yuuki Enomoto P03A: Doubling FreeBSD Request-Response Throughputs over – TCP with PASTE Michio Honda P03B: LLVM and the state of sanitizers on BSD 041 David Carlier P04A: Monitoring FreeBSD Systems What to (Not) Monitor 047 Andrew Fengler P04B: Intel HAXM—A Hardware-Assisted Acceleration Engine in 053 the NetBSD kernel Kamil Rytarowski P05A: Managing System Images with ZFS 057 Allan Jude P05B: bhyvearm64: Generic Interrupt Controller Version 3 065 Virtualization Alexandru Elisei, Mihai Carabas P06A: BSD Unix Solutions in the Australian NFP/NGO Health 073 Sector Jason Tubnor P06B1: bhyve - Improvements to Virtual Machine State Save and 081 Restore Darius Mihai, Mihai Carabas P06B2: FreeBSD - Live Migration feature for bhyve 089 Maria-Elena Mih˘ailescu,Mihai Carabas P07A: Yet Another Container Migration on FreeBSD 097 Yuhei Takagawa, Katsuya Matsubara P07B: Finalizing Booting Requirements for a Guest Running Under 103 bhyvearm Nicolae-Alexandru Ivan, Mihai Carabas P08A: Parallel, Multi-Axis Regression and Performance Testing 109 with FreeBSD, OpenZFS, and bhyve Michael Dexter P08B: FreeBSD Virtualization - Improving block I/O compatibility in 115 bhyve Sergiu Weisz, Mihai Carabas P09A: ZRouter: Remote update of firmware 119 Hiroki Mori P09B: Porting Go to NetBSD/arm64 123 Maya Rashish P10A: Improving security of the FreeBSD boot process 125 Kornel Duleba, Michał Stanek P10B: Another Path for Software Quality? Automated Software 131 Verification and OpenBSD Moritz Buhl !"" 1 -0 ./ = 1 ! %) 12 1$ 57>>55 1 ?@ # 5AB5 1 9 ) : !" #$" 12 !% " %& = 1 '$( ) 1 ! !!!! % ) # 4 ;"5>-A-01 * +,- C @ .15AB-!" 1 ./ -0 %)) 1 1 !% % 1 & :%)! 1 12 " D5AB," )1 #-0 1$3 1 77-E5A!#1 12 4." 4." !" 12! *12 1 1 ! 1 1 5 # $% & ' 6# % ) " # 7 8 9 #-0 F -0 ! B! % " ! " 1 1 5! # 1 1 1 $ / $ 1 # 4 5 7! = : : !% 1# ! ;"% 1 G+$"+!- ! () & * + !, & -. * #$") 7'$( ( : !" '$( : .121C : : 6 !# 1 !% + : 1 8'#9 6 1 '41C ! ;" !%3 + '41C 1C : 1 ) ! 81 ! % #$" << !% = )+"/ + & & " %& ) !# .1 = #$" H 12 6 #F # ! % 1 %1 5 !#/ '$(1 < !'$( 1 G8""#% 1 -0 3 ! @ 1 1 ! 9 % @ ; . . ! = & B ! % @ . . . ! % @ $ .= . . @./.= : 2 ! % 1!3! 6 > <! $ ./ 6 !% . % ! % %. ! 8 .= 9 . % ! 6 ./ % ./ $( ! ) .!% +-6+-6 . 6 .', :! 6 . 7" 3! = 4'# 1!-! . ! " # / % ? 6 ', "$"" &4 . 56 ! 7" !, 6. ) " # 01 6 6;% - 5! % ?; 6< % ?<! ', A(4 4 ', A(4 ! % . ( ( # ! !" #$ # # # )# ) !" # # % . 8 ! %" #$ " @ . 5 . # # . . # ! # # # > %" #$ & # & * # ! ) # ) # & # ! # %" ! ' !" ! # . . #$ " 9 & # & !% # . " # %" ! ' !" 10 = 4 - !*4 - % <8 5" ! % 5" ! - = ! - = = ' - = = 9 - - ! - ; = ! % 4 4! % = == = = #178(711: - ! 48 8"$- 5" -!% - 5" # % # - 6 - % " ' --9 # % # &'(()&**+,)&*'-(&.+/00 6 ! *4 - . . ! <4 "' + # = ! - ! # # =- - ! 2152 ),5: % -3 - ' ! ! &"#% #&" - *+! * = - ; = !% 6 - - 5" ! $ ! = / 0" ! ! * - - ; 11 12 Removing ROP Gadgets from OpenBSD Todd Mortimer [email protected] Abstract tems, including recent attacks exploiting CVE-2018-57671, CVE-2018-74452 and CVE-2018-16865/63. Return Oriented Programming (ROP) is a common exploita- Numerous techniques have been proposed to mitigate tion technique that reuses existing code fragments (gadgets) against ROP exploits, including return address verification to construct shellcode in a compromised program. Recent techniques [2] and control flow verification [1] which aim to changes in OpenBSD’s compiler have started to reduce the prevent control flow being redirected towards a ROP chain. number of gadgets in x86 and arm64 binaries, with the aim of Attempts have also been made to attempt to remove or render making ROP exploitation more difficult or impossible. This unusable ROP gadgets themselves [4]. This paper describes paper will cover how ROP gadgets emerge from legitimate ROP exploit mitigations in OpenBSD which are motivated by code, how OpenBSD’s compiler removes these gadgets, and gadget reduction and removal, though some mitigations also the effects on performance, code size, and ROP tool capabil- verify return control flow through return address verification. ities. We find that it is possible to meaningfully reduce the In order to mount a successful ROP attack against a vulner- number of ROP gadgets in programs, and to effectively hinder able binary, the attacker must first catalogue all of the gadgets ROP tool capabilities. available in a given binary, then identify a sequence of gad- gets which will result in their desired effect. This process of scanning binaries for gadgets and then constructing ROP 1 Background chains which have a desired outcome is somewhat tedious and error prone, so numerous tools exist to make this easy, such 4 5 6 7 Return oriented programming (ROP) [5] is an exploitation as ROPGadget , ropper , angrop , or pwntools . In this paper technique that uses fragments of existing programs in unin- we will rely on the output from one of these tools, ROPGad- tended ways to effect control over a compromised process. In get, to measure our effectiveness. Specifically, we will use contrast to traditional shellcode injection, ROP attacks inject the number of unique gadgets found by this tool to measure a series of return addresses - a ROP Chain - into memory the effectiveness of gadget removal in the OpenBSD kernel and which, when execution returns to the first address in the and libc, which we have chosen because they are large and chain, cause execution to iterate through a series of small code diverse binary objects, and are popular exploitation targets. fragments which have the same effect as traditional shellcode. ROPGadget also includes an option to generate a ROP chain ROP is a powerful technique in environments which disable that results in an exploited program executing a command simultaneous writable and executable memory (W⊕X), since shell. Obtaining a command shell is a common exploitation it does not rely on injecting executable code into program goal, since once an attacker has a command shell they can memory, but instead relies only on program fragments that execute arbitrary other commands on the compromised sys- already exist. These program fragments are called gadgets, tem. We will use this feature to estimate the effectiveness and each gadget consists of a (typically small) sequence of of our efforts to impede mounting successful ROP attacks instructions followed by a return. On aligned architectures, 1https://www.fidusinfosec.com/remote-code-execution-cve-2018-5767/ these returns are part of the intended instruction stream that 2https://www.secureauth.com/labs/advisories/mikrotik-routeros-smb- make up the program, but on unaligned architectures such buffer-overflow 3https://www.openwall.com/lists/oss-security/2019/01/09/3 as x86, these returns can also emerge from jumping into the 4 instruction stream at unintended offsets and causing the exist- https://github.com/JonathanSalwan/ROPgadget 5https://github.com/sashs/ropper ing code to be interpreted differently from what was intended. 6https://github.com/salls/angrop ROP techniques have been used in attacks on real world sys- 7http://docs.pwntools.com/en/stable/ 13 against OpenBSD binaries. The output from the ROPGadget to the intended stream of instructions. These polymorphic
Load more

Recommended publications
  • Iocage Documentation Release 1.2
    iocage Documentation Release 1.2 Brandon Schneider and Peter Toth Sep 26, 2019 Contents 1 Documentation: 3 1.1 Install iocage...............................................3 1.2 Basic Usage...............................................6 1.3 Plugins.................................................. 10 1.4 Networking................................................ 11 1.5 Jail Types................................................. 14 1.6 Best Practices............................................... 15 1.7 Advanced Usage............................................. 16 1.8 Using Templates............................................. 20 1.9 Create a Debian Squeeze Jail (GNU/kFreeBSD)............................ 21 1.10 Known Issues............................................... 22 1.11 FAQ.................................................... 23 1.12 Indices and tables............................................ 24 Index 25 i ii iocage Documentation, Release 1.2 iocage is a jail/container manager written in Python, combining some of the best features and technologies the FreeBSD operating system has to offer. It is geared for ease of use with a simplistic and easy to learn command syntax. FEATURES: • Templates, basejails, and normal jails • Easy to use • Rapid thin provisioning within seconds • Automatic package installation • Virtual networking stacks (vnet) • Shared IP based jails (non vnet) • Dedicated ZFS datasets inside jails • Transparent ZFS snapshot management • Binary updates • Export and import • And many more! Contents 1 iocage Documentation,
    [Show full text]
  • Automated Analysis of Speculation Windows in Spectre Attacks
    Barbara Gigerl Automated Analysis of Speculation Windows in Spectre Attacks MASTER'S THESIS to achieve the university degree of Diplom-Ingenieurin Master's degree programme: Software Engineering and Management submitted to Graz University of Technology Supervisor: Daniel Gruss Institute for Applied Information Processing and Communication Graz, May 2019 i AFFIDAVIT I declare that I have authored this thesis independently, that I have not used other than the declared sources/resources, and that I have explicitly indicated all material which has been quoted either literally or by content from the sources used. The text document uploaded to TUGRAZonline is identical to the present master's thesis. Date Signature EIDESSTATTLICHE ERKLARUNG¨ Ich erkl¨arean Eides statt, dass ich die vorliegende Arbeit selbstst¨andig verfasst, andere als die angegebenen Quellen/Hilfsmittel nicht benutzt, und die den benutzten Quellen w¨ortlich und inhaltlich entnommenen Stellen als solche kenntlich gemacht habe. Das in TUGRAZonline hochgeladene Textdokument ist mit der vorliegenden Masterarbeit identisch. Datum Unterschrift Abstract Speculative execution is a feature integrated into most modern CPUs. Although intro- duced as a way to enhance the performance of processors, the release of Spectre attacks showed that it is a significant security risk. Since CPUs from various vendors, includ- ing Intel, AMD, ARM, and IBM, implement speculative execution, all different kinds of devices are affected by Spectre attacks, for example, desktop PCs and smartphones. Spectre attacks exploit the branch prediction mechanisms of the CPU and then use a cache covert channel to leak secret data. Several attack variants have been discovered since the release, including Spectre-PHT which targets the Pattern History Table of the CPU.
    [Show full text]
  • Hetfs: a Heterogeneous File System for Everyone
    HetFS: A Heterogeneous File System for Everyone Georgios Koloventzos1, Ramon Nou∗1, Alberto Miranda∗1, and Toni Cortes1;2 1 Barcelona Supercomputing Center (BSC) Barcelona, Spain 2 Universitat Polit`ecnicade Catalunya Barcelona, Spain georgios.koloventzos,ramon.nou,alberto.miranda,toni.cortes}@bsc.es Abstract Storage devices have been getting more and more diverse during the last decade. The advent of SSDs made it painfully clear that rotating devices, such as HDDs or magnetic tapes, were lacking in regards to response time. However, SSDs currently have a limited number of write cycles and a significantly larger price per capacity, which has prevented rotational technologies from begin abandoned. Additionally, Non-Volatile Memories (NVMs) have been lately gaining traction, offering devices that typically outperform NAND-based SSDs but exhibit a full new set of idiosyncrasies. Therefore, in order to appropriately support this diversity, intelligent mech- anisms will be needed in the near-future to balance the benefits and drawbacks of each storage technology available to a system. In this paper, we present a first step towards such a mechanism called HetFS, an extension to the ZFS file system that is capable of choosing the storage device a file should be kept in according to preprogrammed filters. We introduce the prototype and show some preliminary results of the effects obtained when placing specific files into different devices. 1 Introduction Storage devices have shown a significant evolution in the latest decade. As the improvements in the latencies of traditional hard disk drives (HDDs) have dimin- ished due to the mechanical limitations inherent to their design, other technolo- gies have been emerging to try and take their place.
    [Show full text]
  • Security Assurance Requirements for Linux Application Container Deployments
    NISTIR 8176 Security Assurance Requirements for Linux Application Container Deployments Ramaswamy Chandramouli This publication is available free of charge from: https://doi.org/10.6028/NIST.IR.8176 NISTIR 8176 Security Assurance Requirements for Linux Application Container Deployments Ramaswamy Chandramouli Computer Security Division Information Technology Laboratory This publication is available free of charge from: https://doi.org/10.6028/NIST.IR.8176 October 2017 U.S. Department of Commerce Wilbur L. Ross, Jr., Secretary National Institute of Standards and Technology Walter Copan, NIST Director and Under Secretary of Commerce for Standards and Technology NISTIR 8176 SECURITY ASSURANCE FOR LINUX CONTAINERS National Institute of Standards and Technology Internal Report 8176 37 pages (October 2017) This publication is available free of charge from: https://doi.org/10.6028/NIST.IR.8176 Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by NIST, nor is it intended to imply that the entities, materials, or equipment are necessarily the best available for the purpose. This p There may be references in this publication to other publications currently under development by NIST in accordance with its assigned statutory responsibilities. The information in this publication, including concepts and methodologies, may be used by federal agencies even before the completion of such companion publications. Thus, until each ublication is available free of charge from: http publication is completed, current requirements, guidelines, and procedures, where they exist, remain operative. For planning and transition purposes, federal agencies may wish to closely follow the development of these new publications by NIST.
    [Show full text]
  • Oracle Database Licensing Information, 11G Release 2 (11.2) E10594-26
    Oracle® Database Licensing Information 11g Release 2 (11.2) E10594-26 July 2012 Oracle Database Licensing Information, 11g Release 2 (11.2) E10594-26 Copyright © 2004, 2012, Oracle and/or its affiliates. All rights reserved. Contributor: Manmeet Ahluwalia, Penny Avril, Charlie Berger, Michelle Bird, Carolyn Bruse, Rich Buchheim, Sandra Cheevers, Leo Cloutier, Bud Endress, Prabhaker Gongloor, Kevin Jernigan, Anil Khilani, Mughees Minhas, Trish McGonigle, Dennis MacNeil, Paul Narth, Anu Natarajan, Paul Needham, Martin Pena, Jill Robinson, Mark Townsend This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable: U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.
    [Show full text]
  • Flexible Lustre Management
    Flexible Lustre management Making less work for Admins ORNL is managed by UT-Battelle for the US Department of Energy How do we know Lustre condition today • Polling proc / sysfs files – The knocking on the door model – Parse stats, rpc info, etc for performance deviations. • Constant collection of debug logs – Heavy parsing for common problems. • The death of a node – Have to examine kdumps and /or lustre dump Origins of a new approach • Requirements for Linux kernel integration. – No more proc usage – Migration to sysfs and debugfs – Used to configure your file system. – Started in lustre 2.9 and still on going. • Two ways to configure your file system. – On MGS server run lctl conf_param … • Directly accessed proc seq_files. – On MSG server run lctl set_param –P • Originally used an upcall to lctl for configuration • Introduced in Lustre 2.4 but was broken until lustre 2.12 (LU-7004) – Configuring file system works transparently before and after sysfs migration. Changes introduced with sysfs / debugfs migration • sysfs has a one item per file rule. • Complex proc files moved to debugfs • Moving to debugfs introduced permission problems – Only debugging files should be their. – Both debugfs and procfs have scaling issues. • Moving to sysfs introduced the ability to send uevents – Item of most interest from LUG 2018 Linux Lustre client talk. – Both lctl conf_param and lctl set_param –P use this approach • lctl conf_param can set sysfs attributes without uevents. See class_modify_config() – We get life cycle events for free – udev is now involved. What do we get by using udev ? • Under the hood – uevents are collect by systemd and then processed by udev rules – /etc/udev/rules.d/99-lustre.rules – SUBSYSTEM=="lustre", ACTION=="change", ENV{PARAM}=="?*", RUN+="/usr/sbin/lctl set_param '$env{PARAM}=$env{SETTING}’” • You can create your own udev rule – http://reactivated.net/writing_udev_rules.html – /lib/udev/rules.d/* for examples – Add udev_log="debug” to /etc/udev.conf if you have problems • Using systemd for long task.
    [Show full text]
  • Freebsd's Jail(2) Facility
    Lousy virtualization, Happy users: FreeBSD's jail(2) facility Poul-Henning Kamp [email protected] CHROOT(2) FreeBSD System Calls Manual CHROOT(2) NAME chroot -- change root directory LIBRARY Standard C Library (libc, -lc) SYNOPSIS #include <unistd.h> int chroot(const char *dirname); Calling chroot(2) in ftpd(1) implemented ”anonymous FTP” without the hazzle of file/pathname parsing and editing. ”anonymous FTP” became used as a tool to enhance network security. By inference, chroot(2) became seen as a security enhancing feature. ...The source were not strong in those. Exercise 1: List at least four ways to escape chroot(2). Then the Internet happened, ...and web-servers, ...and web-hosting Virtual hosts in Apache User get their own ”virtual apache” but do do not get your own machine. Also shared: Databases mailprograms PHP/Perl etc. Upgrading tools (PHP, mySQL etc) on virtual hosting machines is a nightmare. A really bad nightmare: Cust#1 needs mySQL version > N Cust#2 cannot use mySQL version <M (unless PHP version > K) Cust#3 does not answer telephone Cust#4 has new sysadmin Cust#5 is just about ready with new version Wanted: Lightweight virtualization Same kernel, but virtual filesystem and network address plus root limitations. Just like chroot(2) with IP numbers on top. Will pay cash. Close holes in chroot(2) Introduce ”jail” syscall + kernel struct Block jailed root in most suser(9) calls. Check ”if jail, same jail ?” in strategic places. Fiddle socket syscall arguments: INADDR_ANY -> jail.ip INADDR_LOOPBACK -> jail.ip Not part of jail(2): Resource restriction Hardware virtualization Covert channel prevention (the hard stuff) Total implementation: 350 changed source lines 400 new lines of code FreeBSD without jail usr Resources of various sorts / home var process process process process process process Kernel FreeBSD with jail usr Resources of various sorts / home var process process process process* process process Kernel error = priv_check_cred( cred, PRIV_VFS_LINK, SUSER_ALLOWJAIL); if (error) return (error); The unjailed part One jailed part of the system.
    [Show full text]
  • Sandboxing 2 Change Root: Chroot()
    Sandboxing 2 Change Root: chroot() Oldest Unix isolation mechanism Make a process believe that some subtree is the entire file system File outside of this subtree simply don’t exist Sounds good, but. Sandboxing 2 2 / 47 Chroot Sandboxing 2 3 / 47 Limitations of Chroot Only root can invoke it. (Why?) Setting up minimum necessary environment can be painful The program to execute generally needs to live within the subtree, where it’s exposed Still vulnerable to root compromise Doesn’t protect network identity Sandboxing 2 4 / 47 Root versus Chroot Suppose an ordinary user could use chroot() Create a link to the sudo command Create /etc and /etc/passwd with a known root password Create links to any files you want to read or write Besides, root can escape from chroot() Sandboxing 2 5 / 47 Escaping Chroot What is the current directory? If it’s not under the chroot() tree, try chdir("../../..") Better escape: create device files On Unix, all (non-network) devices have filenames Even physical memory has a filename Create a physical memory device, open it, and change the kernel data structures to remove the restriction Create a disk device, and mount a file system on it. Then chroot() to the real root (On Unix systems, disks other than the root file system are “mounted” as a subtree somewhere) Sandboxing 2 6 / 47 Trying Chroot # mkdir /usr/sandbox /usr/sandbox/bin # cp /bin/sh /usr/sandbox/bin/sh # chroot /usr/sandbox /bin/sh chroot: /bin/sh: Exec format error # mkdir /usr/sandbox/libexec # cp /libexec/ld.elf_so /usr/sandbox/libexec # chroot /usr/sandbox
    [Show full text]
  • Examining the Viability of MINIX 3 As a Consumer Operating
    Examining the Viability of MINIX 3 as a Consumer Operating System Joshua C. Loew March 17, 2016 Abstract The developers of the MINIX 3 operating system (OS) believe that a computer should work like a television set. You should be able to purchase one, turn it on, and have it work flawlessly for the next ten years [6]. MINIX 3 is a free and open-source microkernel-based operating system. MINIX 3 is still in development, but it is capable of running on x86 and ARM processor architectures. Such processors can be found in computers such as embedded systems, mobile phones, and laptop computers. As a light and simple operating system, MINIX 3 could take the place of the software that many people use every day. As of now, MINIX 3 is not particularly useful to a non-computer scientist. Most interactions with MINIX 3 are done through a command-line interface or an obsolete window manager. Moreover, its tools require some low-level experience with UNIX-like systems to use. This project will examine the viability of MINIX 3 from a performance standpoint to determine whether or not it is relevant to a non-computer scientist. Furthermore, this project attempts to measure how a microkernel-based operating system performs against a traditional monolithic kernel-based OS. 1 Contents 1 Introduction 5 2 Background and Related Work 6 3 Part I: The Frame Buffer Driver 7 3.1 Outline of Approach . 8 3.2 Hardware and Drivers . 8 3.3 Challenges and Strategy . 9 3.4 Evaluation . 10 4 Progress 10 4.1 Compilation and Installation .
    [Show full text]
  • Defeating Invisible Enemies:Firmware Based
    Defeating Invisible Enemies: Firmware Based Security in OpenPOWER Systems — Linux Security Summit 2017 — George Wilson IBM Linux Technology Center Linux Security Summit / Defeating Invisible Enemies / September 14, 2017 / © 2017 IBM Corporation Agenda Introduction The Case for Firmware Security What OpenPOWER Is Trusted Computing in OpenPOWER Secure Boot in OpenPOWER Current Status of Work Benefits of Open Source Software Conclusion Linux Security Summit / Defeating Invisible Enemies / September 14, 2017 / © 2017 IBM Corporation 2 Introduction Linux Security Summit / Defeating Invisible Enemies / September 14, 2017 / © 2017 IBM Corporation 3 Disclaimer These slides represent my views, not necessarily IBM’s All design points disclosed herein are subject to finalization and upstream acceptance The features described may not ultimately exist or take the described form in a product Linux Security Summit / Defeating Invisible Enemies / September 14, 2017 / © 2017 IBM Corporation 4 Background The PowerPC CPU has been around since 1990 Introduced in the RS/6000 line Usage presently spans embedded to server IBM PowerPC servers traditionally shipped with the PowerVM hypervisor and ran AIX and, later, Linux in LPARs In 2013, IBM decided to open up the server architecture: OpenPOWER OpenPOWER runs open source firmware and the KVM hypervisor with Linux guests Firmware and software designed and developed by the IBM Linux Technology Center “OpenPOWER needs secure and trusted boot!” Linux Security Summit / Defeating Invisible Enemies / September 14, 2017 / © 2017 IBM Corporation 5 The Case for Firmware Security Linux Security Summit / Defeating Invisible Enemies / September 14, 2017 / © 2017 IBM Corporation 6 Leaks Wikileaks Vault 7 Year 0 Dump NSA ANT Catalog Linux Security Summit / Defeating Invisible Enemies / September 14, 2017 / © 2017 IBM Corporation 7 Industry Surveys UEFI Firmware Rootkits: Myths and Reality – Matrosov Firmware Is the New Black – Analyzing Past Three Years of BIOS/UEFI Security Vulnerabilities – Branco et al.
    [Show full text]
  • Multicore Operating-System Support for Mixed Criticality∗
    Multicore Operating-System Support for Mixed Criticality∗ James H. Anderson, Sanjoy K. Baruah, and Bjorn¨ B. Brandenburg The University of North Carolina at Chapel Hill Abstract Different criticality levels provide different levels of assurance against failure. In current avionics designs, Ongoing research is discussed on the development of highly-critical software is kept physically separate from operating-system support for enabling mixed-criticality less-critical software. Moreover, no currently deployed air- workloads to be supported on multicore platforms. This craft uses multicore processors to host highly-critical tasks work is motivated by avionics systems in which such work- (more precisely, if multicore processors are used, and if loads occur. In the mixed-criticality workload model that is such a processor hosts highly-critical applications, then all considered, task execution costs may be determined using but one of its cores are turned off). These design decisions more-stringent methods at high criticality levels, and less- are largely driven by certification issues. For example, cer- stringent methods at low criticality levels. The main focus tifying highly-critical components becomes easier if poten- of this research effort is devising mechanisms for providing tially adverse interactions among components executing on “temporal isolation” across criticality levels: lower levels different cores through shared hardware such as caches are should not adversely “interfere” with higher levels. simply “defined” not to occur. Unfortunately, hosting an overall workload as described here clearly wastes process- ing resources. 1 Introduction In this paper, we propose operating-system infrastruc- ture that allows applications of different criticalities to be The evolution of computational frameworks for avionics co-hosted on a multicore platform.
    [Show full text]
  • The Dragonflybsd Operating System
    1 The DragonFlyBSD Operating System Jeffrey M. Hsu, Member, FreeBSD and DragonFlyBSD directories with slightly over 8 million lines of code, 2 million Abstract— The DragonFlyBSD operating system is a fork of of which are in the kernel. the highly successful FreeBSD operating system. Its goals are to The project has a number of resources available to the maintain the high quality and performance of the FreeBSD 4 public, including an on-line CVS repository with mirror sites, branch, while exploiting new concepts to further improve accessible through the web as well as the cvsup service, performance and stability. In this paper, we discuss the motivation for a new BSD operating system, new concepts being mailing list forums, and a bug submission system. explored in the BSD context, the software infrastructure put in place to explore these concepts, and their application to the III. MOTIVATION network subsystem in particular. A. Technical Goals Index Terms— Message passing, Multiprocessing, Network The DragonFlyBSD operating system has several long- operating systems, Protocols, System software. range technical goals that it hopes to accomplish within the next few years. The first goal is to add lightweight threads to the BSD kernel. These threads are lightweight in the sense I. INTRODUCTION that, while user processes have an associated thread and a HE DragonFlyBSD operating system is a fork of the process context, kernel processes are pure threads with no T highly successful FreeBSD operating system. Its goals are process context. The threading model makes several to maintain the high quality and performance of the FreeBSD guarantees with respect to scheduling to ensure high 4 branch, while exploring new concepts to further improve performance and simplify reasoning about concurrency.
    [Show full text]