Toward Decomposing the Linux Kernel
Total Page:16
File Type:pdf, Size:1020Kb
Load more
Recommended publications
-
Linux for Zseries: Device Drivers and Installation Commands (March 4, 2002) Summary of Changes
Linux for zSeries Device Drivers and Installation Commands (March 4, 2002) Linux Kernel 2.4 LNUX-1103-07 Linux for zSeries Device Drivers and Installation Commands (March 4, 2002) Linux Kernel 2.4 LNUX-1103-07 Note Before using this document, be sure to read the information in “Notices” on page 207. Eighth Edition – (March 2002) This edition applies to the Linux for zSeries kernel 2.4 patch (made in September 2001) and to all subsequent releases and modifications until otherwise indicated in new editions. © Copyright International Business Machines Corporation 2000, 2002. All rights reserved. US Government Users Restricted Rights – Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Summary of changes .........v Chapter 5. Linux for zSeries Console || Edition 8 changes.............v device drivers............27 Edition 7 changes.............v Console features .............28 Edition 6 changes ............vi Console kernel parameter syntax .......28 Edition 5 changes ............vi Console kernel examples ..........28 Edition 4 changes ............vi Usingtheconsole............28 Edition 3 changes ............vii Console – Use of VInput ..........30 Edition 2 changes ............vii Console limitations ............31 About this book ...........ix Chapter 6. Channel attached tape How this book is organized .........ix device driver ............33 Who should read this book .........ix Tapedriverfeatures...........33 Assumptions..............ix Tape character device front-end........34 Tape block -
Capabilities
CS 261, Fall 2015 Scribe notes September 8: Capabilities Scribe: Riyaz Faizullabhoy 1 Motivation for Capabilities In The Confused Deputy, the compiler had two sets of rights: one from the user to access user files such as source code to compile, and another set granted to the compiler intended to access a special statistics file that would collect information about language feature usage. The compiler was installed in the SYSX directory, where it was granted access to write to any file in this directory. Naturally, the statistics file SYSX/STAT was also located in this directory such that the compiler (SYSX/FORT) could add language feature information. To achieve this, the compiler's privileges were set with a home files license that was allowed by the operating system to write to any file in the SYSX directory. A billing information file SYSX/BILL was also stored in SYSX { due to its sensitive nature, this billing file was not directly accessible to users. However, since the compiler was granted access to the entire SYSX directory, users could subvert their access restrictions on the billing information file by using the compiler like so: SYSX/FORT foo.f -o SYSX/BILL The above user-invoked command to the compiler would allow the compiler to first read the user's source code in foo.f, but then the compiler's privilege to SYSX would cause the SYSX/BILL file to be overwritten with the user's binary. In effect, the compiler is the confused deputy having to reconcile both its own and the user's set of privileges, but unfortunately allows for unintended behavior. -
Operating Systems & Virtualisation Security Knowledge Area
Operating Systems & Virtualisation Security Knowledge Area Issue 1.0 Herbert Bos Vrije Universiteit Amsterdam EDITOR Andrew Martin Oxford University REVIEWERS Chris Dalton Hewlett Packard David Lie University of Toronto Gernot Heiser University of New South Wales Mathias Payer École Polytechnique Fédérale de Lausanne The Cyber Security Body Of Knowledge www.cybok.org COPYRIGHT © Crown Copyright, The National Cyber Security Centre 2019. 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 © Crown Copyright, The National Cyber Security Centre 2018, li- censed 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 con- [email protected] to let the project know how they are using CyBOK. Issue 1.0 is a stable public release of the Operating Systems & Virtualisation Security Knowl- edge Area. However, it should be noted that a fully-collated CyBOK document which includes all of the Knowledge Areas is anticipated to be released by the end of July 2019. This will likely include updated page layout and formatting of the individual Knowledge Areas KA Operating Systems & Virtualisation Security j October 2019 Page 1 The Cyber Security Body Of Knowledge www.cybok.org INTRODUCTION In this Knowledge Area, we introduce the principles, primitives and practices for ensuring se- curity at the operating system and hypervisor levels. -
Runtime Data Driven Partitioning of Linux Code
This is the author's version of an article that has been published in this journal. Changes were made to this version by the publisher prior to publication. The final version of record is available at http://dx.doi.org/10.1109/TDSC.2017.2745574 1 How to Fillet a Penguin: Runtime Data Driven Partitioning of Linux Code Oliver Schwahn, Stefan Winter, Nicolas Coppik, and Neeraj Suri Abstract—In many modern operating systems (OSs), there exists no isolation between different kernel components, i.e., the failure of one component can affect the whole kernel. While microkernel OSs introduce address space separation for large parts of the OS, their improved fault isolation comes at the cost of performance. Despite significant improvements in modern microkernels, monolithic OSs like Linux are still prevalent in many systems. To achieve fault isolation in addition to high performance and code reuse in these systems, approaches to move only fractions of kernel code into user mode have been proposed. These approaches solely rely on static code analyses for deciding which code to isolate, neglecting dynamic properties like invocation frequencies. We propose to augment static code analyses with runtime data to achieve better estimates of dynamic properties for common case operation. We assess the impact of runtime data on the decision what code to isolate and the impact of that decision on the performance of such “microkernelized” systems. We extend an existing tool chain to implement automated code partitioning for existing monolithic kernel code and validate our approach in a case study of two widely used Linux device drivers and a file system. -
Assessing Unikernel Security April 2, 2019 – Version 1.0
NCC Group Whitepaper Assessing Unikernel Security April 2, 2019 – Version 1.0 Prepared by Spencer Michaels Jeff Dileo Abstract Unikernels are small, specialized, single-address-space machine images constructed by treating component applications and drivers like libraries and compiling them, along with a kernel and a thin OS layer, into a single binary blob. Proponents of unikernels claim that their smaller codebase and lack of excess services make them more efficient and secure than full-OS virtual machines and containers. We surveyed two major unikernels, Rumprun and IncludeOS, and found that this was decidedly not the case: unikernels, which in many ways resemble embedded systems, appear to have a similarly minimal level of security. Features like ASLR, W^X, stack canaries, heap integrity checks and more are either completely absent or seriously flawed. If an application running on such a system contains a memory corruption vulnerability, it is often possible for attackers to gain code execution, even in cases where the applica- tion’s source and binary are unknown. Furthermore, because the application and the kernel run together as a single process, an attacker who compromises a unikernel can immediately exploit functionality that would require privilege escalation on a regular OS, e.g. arbitrary packet I/O. We demonstrate such attacks on both Rumprun and IncludeOS unikernels, and recommend measures to mitigate them. Table of Contents 1 Introduction to Unikernels . 4 2 Threat Model Considerations . 5 2.1 Unikernel Capabilities ................................................................ 5 2.2 Unikernels Versus Containers .......................................................... 5 3 Hypothesis . 6 4 Testing Methodology . 7 4.1 ASLR ................................................................................ 7 4.2 Page Protections .................................................................... -
Capsicum Slides
Capsicum Capability-Based Sandboxing David Drysdale Google UK Features Current LXC uses the following kernel features to contain processes: ● Kernel namespaces (ipc, uts, mount, pid, network and user) ● Apparmor and SELinux profiles ● Seccomp policies ● Chroots (using pivot_root) ● Kernel capabilities ● CGroups (control groups) Agenda ● Ideas ○ Privilege Separation ○ Capabilities ● Capsicum ○ Hybrid with POSIX ○ Application changes ● Linux container features ● Status/Outlook Check Your Privileges ● Drop unnecessary privileges ○ Just because a process starts as root, doesn't have to stay that way Check Your Privileges ● Drop unnecessary privileges ○ Just because a process starts as root, doesn't have to stay that way ● Divide up software according to what privileges are needed ○ E.g. separate media processing from credentials processing Check Your Privileges ● Drop unnecessary privileges ○ Just because a process starts as root, doesn't have to stay that way ● Divide up software according to what privileges are needed ○ E.g. separate media processing from credentials processing ● Examples: ○ OpenSSH: credential checking process ○ Chrome: renderer processes ● Design impact: ○ Do privileged operations first ○ Pass resources down a privilege gradient Capability-Based Security ● Make the privileges that a process holds more explicit Capability-Based Security ● Make the privileges that a process holds more explicit ● Access objects via unforgeable token: the capability ○ Identifies the object ○ Accompanying rights give allowed operations ○ Can only reduce, not increase rights ○ Can pass capabilities around Capability-Based Security ● Make the privileges that a process holds more explicit ● Access objects via unforgeable token: the capability ○ Identifies the object ○ Accompanying rights give allowed operations ○ Can only reduce, not increase rights ○ Can pass capabilities around ● Remove other ways of accessing objects ○ No access by name, i.e. -
Semperos: a Distributed Capability System
SemperOS: A Distributed Capability System Matthias Hille† Nils Asmussen† ∗ Pramod Bhatotia‡ Hermann Härtig† ∗ †Technische Universität Dresden ‡The University of Edinburgh ∗ Barkhausen Institut Abstract systems have received renewed attention recently to provide Capabilities provide an efficient and secure mechanism for an efficient and secure mechanism for resource management fine-grained resource management and protection. However, in modern hardware architectures [5, 24, 30, 36, 44, 64, 67]. as the modern hardware architectures continue to evolve Today the main improvements in compute capacity with large numbers of non-coherent and heterogeneous cores, are achieved by either adding more cores or integrating we focus on the following research question: can capability accelerators into the system. However, the increasing core systems scale to modern hardware architectures? counts exacerbate the hardware complexity required for global In this work, we present a scalable capability system to drive cache coherence. While on-chip cache coherence is likely to future systems with many non-coherent heterogeneous cores. remain a feature of future hardware architectures [45], we see More specifically, we have designed a distributed capability characteristics of distributed systems added to the hardware system based on a HW/SW co-designed capability system. by giving up on global cache coherence across a whole We analyzed the pitfalls of distributed capability operations machine [6, 28]. Additionally, various kinds of accelerators running concurrently and built the protocols in accordance are added like the Xeon Phi Processor, the Matrix-2000 accel- with the insights. We have incorporated these distributed erator, GPUs, FPGAs, or ASICs, which are used in numerous capability management protocols in a new microkernel-based application fields [4,21,32,34,43,60]. -
Efficient Cache Attacks on AES, and Countermeasures
J. Cryptol. (2010) 23: 37–71 DOI: 10.1007/s00145-009-9049-y Efficient Cache Attacks on AES, and Countermeasures Eran Tromer Computer Science and Artificial Intelligence Laboratory, Massachusetts Institute of Technology, 32 Vassar Street, G682, Cambridge, MA 02139, USA [email protected] and Department of Computer Science and Applied Mathematics, Weizmann Institute of Science, Rehovot 76100, Israel Dag Arne Osvik Laboratory for Cryptologic Algorithms, Station 14, École Polytechnique Fédérale de Lausanne, 1015 Lausanne, Switzerland dagarne.osvik@epfl.ch Adi Shamir Department of Computer Science and Applied Mathematics, Weizmann Institute of Science, Rehovot 76100, Israel [email protected] Communicated by Lars R. Knudsen Received 20 July 2007 and revised 25 June 2009 Online publication 23 July 2009 Abstract. We describe several software side-channel attacks based on inter-process leakage through the state of the CPU’s memory cache. This leakage reveals memory access patterns, which can be used for cryptanalysis of cryptographic primitives that employ data-dependent table lookups. The attacks allow an unprivileged process to attack other processes running in parallel on the same processor, despite partitioning methods such as memory protection, sandboxing, and virtualization. Some of our meth- ods require only the ability to trigger services that perform encryption or MAC using the unknown key, such as encrypted disk partitions or secure network links. Moreover, we demonstrate an extremely strong type of attack, which requires knowledge of nei- ther the specific plaintexts nor ciphertexts and works by merely monitoring the effect of the cryptographic process on the cache. We discuss in detail several attacks on AES and experimentally demonstrate their applicability to real systems, such as OpenSSL and Linux’s dm-crypt encrypted partitions (in the latter case, the full key was recov- ered after just 800 writes to the partition, taking 65 milliseconds). -
Improvement of the Virtualization Support in the Fiasco.OC Microkernel
Technische Universität Berlin Master’s Thesis Chair for Security in Telecommunications (SecT) School IV — Electrical Engineering and Computer Science Technische Universität Berlin Improving Virtualization Support in the Fiasco.OC Microkernel Author: Julius Werner (#310341) Major: Computer Science (Informatik) Email: [email protected] Primary Advisor: Prof. Dr. Jean-Pierre Seifert Secondary Advisor: Prof. Dr. Hans-Ulrich Heiß Tutor: Dipl.-Inf. Matthias Lange April – August 2012 Abstract This thesis aims to improve the memory virtualization efficiency of the Fiasco.OC mi- crokernel on processors with the Intel VMX hardware-assisted virtualization architecture, which is plagued by severe performance degradation. After discussing possible approaches, this goal is accomplished by implementing support for Intel’s nested paging mechanism (EPT). Fiasco.OC’s memory management system is enhanced to allow a new kind of task whose address space is stored in the EPT page attribute format while staying compati- ble with the existing shared memory mapping interface through dynamic page attribute translation. This enhancement is complemented with support for tagged TLB entries (VPIDs), independently providing another minor performance increase. The kernel’s external virtualization API and the experimental userland VMM Karma are adapted to support these changes. The final implementation is evaluated and analyzed in the context of several benchmarks, achieving near-native performance on real-world workloads while only constituting a minor increase in complexity for the microkernel. Zusammenfassung Diese Arbeit zielt darauf ab die Speichervirtualisierungseffizienz des Fiasco.OC Mikro- kerns auf Prozessoren mit der hardwareunterstützten Virtualisierungsarchitektur Intel VMX zu verbessern, welche von schweren Performanzverlusten geplagt wird. Nach der Diskussion möglicher Lösungsansätze wird dieses Ziel mit der Unterstützung von Intels Mechanismus für verschachtelte Seitentabellen (EPT) umgesetzt. -
Capsicum on Linux
Capsicum on Linux David Drysdale 18 Aug 2014 Linux Security Summit Capsicum ● Pragmatic application ● of object-capability principles ● to UNIX ● and Linux in particular Google Confidential and Proprietary Capability-Based Security ● All object access needs a token: the capability ○ identifies the object ○ accompanying rights give allowed operations Google Confidential and Proprietary Capability-Based Security ● All object access needs a token: the capability ○ identifies the object ○ accompanying rights give allowed operations ● Avoid object naming & ambient authority ○ Prevent confused deputy attacks ○ Acquire capabilities ■ by inheritance ■ by creation (with subset of rights) ■ by passing Google Confidential and Proprietary Capability-Based Security ● All object access needs a token: the capability ○ identifies the object ○ accompanying rights give allowed operations ● Avoid object naming & ambient authority ○ Prevent confused deputy attacks ○ Acquire capabilities ■ by inheritance ■ by creation (with subset of rights) ■ by passing ● Note: completely different than POSIX.1e capabilities Google Confidential and Proprietary Capsicum Principles ● POSIX File Descriptor Behaviour Google Confidential and Proprietary Capsicum Principles ● POSIX File Descriptor Behaviour ● Hence Capsicum: ○ file descriptors as capabilities ○ with (new) fine-grained rights ■ policy co-located with code (ENOTCAPABLE) Google Confidential and Proprietary Capsicum Principles ● POSIX File Descriptor Behaviour ● Hence Capsicum: ○ file descriptors as capabilities ○ -
Virtualization Guide Virtualization Guide SUSE Linux Enterprise Server 15 SP2
SUSE Linux Enterprise Server 15 SP2 Virtualization Guide Virtualization Guide SUSE Linux Enterprise Server 15 SP2 Describes virtualization technology in general, and introduces libvirt—the unied interface to virtualization—and detailed information on specic hypervisors. Publication Date: September 24, 2021 SUSE LLC 1800 South Novell Place Provo, UT 84606 USA https://documentation.suse.com Copyright © 2006– 2021 SUSE LLC and contributors. All rights reserved. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or (at your option) version 1.3; with the Invariant Section being this copyright notice and license. A copy of the license version 1.2 is included in the section entitled “GNU Free Documentation License”. For SUSE trademarks, see https://www.suse.com/company/legal/ . All other third-party trademarks are the property of their respective owners. Trademark symbols (®, ™ etc.) denote trademarks of SUSE and its aliates. Asterisks (*) denote third-party trademarks. All information found in this book has been compiled with utmost attention to detail. However, this does not guarantee complete accuracy. Neither SUSE LLC, its aliates, the authors nor the translators shall be held liable for possible errors or the consequences thereof. Contents About This Manual xvi 1 Available Documentation xvi 2 Giving Feedback xviii 3 Documentation Conventions xix 4 Product Life Cycle and Support xx Support Statement for SUSE Linux Enterprise Server xxi • Technology Previews -
Rump File Systems Kernel Code Reborn
Rump File Systems Kernel Code Reborn Antti Kantee [email protected] Helsinki University of Technology USENIX Annual Technical Conference, San Diego, USA June 2009 Introduction ● kernel / userspace dichotomy – interfaces dictate environment ● make kernel file systems run in userspace in a complete and maintainable way – full stack, no code forks or #ifdef ● file system is a protocol translator – read(off,size,n) => blocks 001,476,711,999 Implementation status ● NetBSD kernel file system code runs unmodified in a userspace process ● total of 13 kernel file systems – cd9660, efs, ext2fs, fat, ffs, hfs+, lfs, nfs, ntfs, puffs, sysvbfs, tmpfs, udf – disk, memory, network, ”other” ● implementation shipped as source and binary with NetBSD 5.0 and later Terminology rump: runnable userspace meta program 1) userspace program using kernel code 2) framework which enables above rump kernel: part of rump with kernel code host (OS): system running the rump(1) Talk outline motivation use cases implementation evaluation Motivation ● original motivation: kernel development ● additional benefits: – security – code reuse in userspace tools – kernel code reuse on other systems Contrasts 1)usermode OS, emulator, virtual machine, second machine, turing machine, etc. – acknowledge that we already have an OS – vm simplifications, abstraction shortcuts, etc. – direct host service (no additional userland) 2)userspace file systems (e.g. FUSE) – reuse existing code, not write new code against another interface Talk outline motivation use cases implementation evaluation