Rumpkernel-Bookv2-20160802.Pdf
Total Page:16
File Type:pdf, Size:1020Kb
Load more
Recommended publications
-
Porting FUSE to L4re
Großer Beleg Porting FUSE to L4Re Florian Pester 23. Mai 2013 Technische Universit¨at Dresden Fakult¨at Informatik Institut fur¨ Systemarchitektur Professur Betriebssysteme Betreuender Hochschullehrer: Prof. Dr. rer. nat. Hermann H¨artig Betreuender Mitarbeiter: Dipl.-Inf. Carsten Weinhold Erkl¨arung Hiermit erkl¨are ich, dass ich diese Arbeit selbstst¨andig erstellt und keine anderen als die angegebenen Hilfsmittel benutzt habe. Declaration I hereby declare that this thesis is a work of my own, and that only cited sources have been used. Dresden, den 23. Mai 2013 Florian Pester Contents 1. Introduction 1 2. State of the Art 3 2.1. FUSE on Linux . .3 2.1.1. FUSE Internal Communication . .4 2.2. The L4Re Virtual File System . .5 2.3. Libfs . .5 2.4. Communication and Access Control in L4Re . .6 2.5. Related Work . .6 2.5.1. FUSE . .7 2.5.2. Pass-to-Userspace Framework Filesystem . .7 3. Design 9 3.1. FUSE Server parts . 11 4. Implementation 13 4.1. Example Request handling . 13 4.2. FUSE Server . 14 4.2.1. LibfsServer . 14 4.2.2. Translator . 14 4.2.3. Requests . 15 4.2.4. RequestProvider . 15 4.2.5. Node Caching . 15 4.3. Changes to the FUSE library . 16 4.4. Libfs . 16 4.5. Block Device Server . 17 4.6. File systems . 17 5. Evaluation 19 6. Conclusion and Further Work 25 A. FUSE operations 27 B. FUSE library changes 35 C. Glossary 37 V List of Figures 2.1. The architecture of FUSE on Linux . .3 2.2. The architecture of libfs . -
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 .................................................................... -
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). -
Index Images Download 2006 News Crack Serial Warez Full 12 Contact
index images download 2006 news crack serial warez full 12 contact about search spacer privacy 11 logo blog new 10 cgi-bin faq rss home img default 2005 products sitemap archives 1 09 links 01 08 06 2 07 login articles support 05 keygen article 04 03 help events archive 02 register en forum software downloads 3 security 13 category 4 content 14 main 15 press media templates services icons resources info profile 16 2004 18 docs contactus files features html 20 21 5 22 page 6 misc 19 partners 24 terms 2007 23 17 i 27 top 26 9 legal 30 banners xml 29 28 7 tools projects 25 0 user feed themes linux forums jobs business 8 video email books banner reviews view graphics research feedback pdf print ads modules 2003 company blank pub games copyright common site comments people aboutus product sports logos buttons english story image uploads 31 subscribe blogs atom gallery newsletter stats careers music pages publications technology calendar stories photos papers community data history arrow submit www s web library wiki header education go internet b in advertise spam a nav mail users Images members topics disclaimer store clear feeds c awards 2002 Default general pics dir signup solutions map News public doc de weblog index2 shop contacts fr homepage travel button pixel list viewtopic documents overview tips adclick contact_us movies wp-content catalog us p staff hardware wireless global screenshots apps online version directory mobile other advertising tech welcome admin t policy faqs link 2001 training releases space member static join health -
Refuse: Userspace FUSE Reimplementation Using Puffs
ReFUSE: Userspace FUSE Reimplementation Using puffs Antti Kantee Alistair Crooks Helsinki University of Technology The NetBSD Foundation [email protected].fi [email protected] Abstract for using Gmail as a file system storage backend and FUSEPod [5] which facilitaties iPod access and man- In an increasingly diverse and splintered world, agement. interoperability rules. The ability to leverage code Userspace file systems operate by attaching an in- written for another platform means more time and re- kernel file system to the kernel’s virtual file system sources for doing new and exciting research instead layer, vfs [17]. This component transforms incoming of reinventing the wheel. Interoperability requires requests into a form suitable for delivery to userspace, standards, and as the saying goes, the best part of sends the request to userspace, waits for a response, standards is that everyone can have their own. How- interprets the result and feeds it back to caller in the ever, in the userspace file system world, the Linux- kernel. The kernel file system calling conventions originated FUSE is the clear yardstick. dictate how to interface with the virtual file system In this paper we present ReFUSE, a userspace layer, but other than that the userspace file systems implementation of the FUSE interface on top of the framework is free to decide how to operate and what NetBSD native puffs (Pass-to-Userspace Framework kind of interface to provide to userspace. File System) userspace file systems framework. We While extending the operating system to userspace argue that an additional layer of indirection is the is not a new idea [12, 21], the FUSE [2] userspace right solution here, as it allows for a more natural file systems interface is the first to become a veri- export of the kernel file system interface instead of table standard. -
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 -
Unikernels: the Next Stage of Linux's Dominance
Unikernels: The Next Stage of Linux’s Dominance Ali Raza Parul Sohal James Cadden Boston University Boston University Boston University [email protected] [email protected] [email protected] Jonathan Appavoo Ulrich Drepper Richard Jones Boston University Red Hat Red Hat [email protected] [email protected] [email protected] Orran Krieger Renato Mancuso Larry Woodman Boston University Boston University Red Hat [email protected] [email protected] [email protected] Abstract 1 Introduction Unikernels have demonstrated enormous advantages over Linux is the dominant OS across nearly every imaginable Linux in many important domains, causing some to propose type of computer system today. Linux is running in billions of that the days of Linux’s dominance may be coming to an people’s pockets, in millions of our homes, in cars, in planes, end. On the contrary, we believe that unikernels’ advantages in spaceships [15], embedded throughout our networks, and represent the next natural evolution for Linux, as it can adopt on each of the top 500 supercomputers [2]. To accomplish the best ideas from the unikernel approach and, along with this, the Linux kernel has been continuously expanded to its battle-tested codebase and large open source community, support a wide range of functionality; it is a hypervisor, a real- continue to dominate. In this paper, we posit that an up- time OS, an SDN router, a container runtime, a BPF virtual streamable unikernel target is achievable from the Linux machine, and a support layer for Emacs. When considering kernel, and, through an early Linux unikernel prototype, this ever-growing set of requirements, and the complexity demonstrate that some simple changes can bring dramatic creep which ensues [26], it leads to the question: Can a single performance advantages. -
Fs-Utils: File Systems Access Tools for Userland
Fs-utils: File Systems Access Tools for Userland Arnaud Ysmal ([email protected]) and Antti Kantee ([email protected].fi) September 2009 Abstract consider the connection to the server to be the file sys- tem image. Currently, file system access is done either through File systems can be accessed by kernel drivers (what a kernel driver or a specialized userspace program. we do when using mount) or by userland tools. In this In the former case the file system is mounted with paper, we focus on the latter, or more precisely on user- the mount utility and then accessed with standard land tools using the file system code from the NetBSD userspace tools such as cat. An example of the latter kernel. This principle is implemented on NetBSD and case is the mtools utility suite which allows to access known as RUMP (Runnable Userspace Meta Program) msdos file systems. [1]. We can also use NetBSD kernel code in userspace The NetBSD Runnable Userspace Meta Program on non-NetBSD operating systems, as we show later (RUMP) framework enables the use of kernel file sys- in this paper. tem drivers as part of userspace programs. By building The rest of this paper is organized as follows. The upon RUMP and NetBSD base system utilities such as remainder of this Section will present fs-utils and ex- ls and cp, we have created the fs-utils application suite. plain what we wanted to achieve by creating this new It provides mtools-like file system access without re- set of tools. Section 2 focuses on the way it was de- quiring mount privileges or an in-kernel driver. -
A Survey of Microarchitectural Timing Attacks and Countermeasures on Contemporary Hardware
A Survey of Microarchitectural Timing Attacks and Countermeasures on Contemporary Hardware Qian Ge1, Yuval Yarom2, David Cock1,3, and Gernot Heiser1 1Data61, CSIRO and UNSW, Australia, qian.ge, [email protected] 2Data61, CSIRO and the University of Adelaide, Australia, [email protected] 3Present address: Systems Group, Department of Computer Science, ETH Zurich,¨ [email protected] Abstract Microarchitectural timing channels expose hidden hardware state though timing. We survey recent attacks that exploit microarchitectural features in shared hardware, especially as they are relevant for cloud computing. We classify types of attacks according to a taxonomy of the shared resources leveraged for such attacks. Moreover, we take a detailed look at attacks used against shared caches. We survey existing countermeasures. We finally discuss trends in the attacks, challenges to combating them, and future directions, especially with respect to hardware support. 1 Introduction Computers are increasingly handling sensitive data (banking, voting), while at the same time we consolidate more services, sensitive or not, on a single hardware platform. This trend is driven both by cost savings and convenience. The most visible example is the cloud computing—infrastructure-as-a-service (IaaS) cloud computing supports multiple virtual machines (VM) on a hardware platform managed by a virtual machine monitor (VMM) or hypervisor. These co-resident VMs are mutually distrusting: high-performance computing software may run alongside a data centre for financial markets, requiring the platform to ensure confidentiality and integrity of VMs. The cloud computing platform also has availability requirements: service providers have service-level agreements (SLAs) which specify availability targets, and malicious VMs being able to deny service to a co-resident VM could be costly to the service provider. -
Recycling RAM Content After Reboots
Wiederverwendung des RAM Inhalts nach Neustarts BACHELORARBEIT zur Erlangung des akademischen Grades Bachelor of Science im Rahmen des Studiums Software & Information Engineering eingereicht von Manuel Wiesinger Matrikelnummer 0825632 an der Fakultät für Informatik der Technischen Universität Wien Betreuung: Ao.Univ.Prof. Anton Ertl Wien, 27. Juni 2016 Manuel Wiesinger Anton Ertl Technische Universität Wien A-1040 Wien Karlsplatz 13 Tel. +43-1-58801-0 www.tuwien.ac.at Recycling RAM content after reboots BACHELOR’S THESIS submitted in partial fulfillment of the requirements for the degree of Bachelor of Science in Software & Information Engineering by Manuel Wiesinger Registration Number 0825632 to the Faculty of Informatics at the Vienna University of Technology Advisor: Ao.Univ.Prof. Anton Ertl Vienna, 27th June, 2016 Manuel Wiesinger Anton Ertl Technische Universität Wien A-1040 Wien Karlsplatz 13 Tel. +43-1-58801-0 www.tuwien.ac.at Erklärung zur Verfassung der Arbeit Manuel Wiesinger Hiermit erkläre ich, dass ich diese Arbeit selbständig verfasst habe, dass ich die verwen- deten Quellen und Hilfsmittel vollständig angegeben habe und dass ich die Stellen der Arbeit – einschließlich Tabellen, Karten und Abbildungen –, die anderen Werken oder dem Internet im Wortlaut oder dem Sinn nach entnommen sind, auf jeden Fall unter Angabe der Quelle als Entlehnung kenntlich gemacht habe. Wien, 27. Juni 2016 Manuel Wiesinger v Acknowledgements First of all, I would like to thank my supervisor Anton Ertl, for his time and ideas, and especially for patiently waiting for me to start writing. My gratitude extends to the people who contributed to the NetBSD project, and to all other free software projects essential for this thesis. -
Operating Systems
OPERATING SYSTEMS Rump Kernels No OS? No Problem! ANTTI KANTEE, JUSTIN CORMACK Antti Kantee got bitten by the n the modern world, both virtualization and plentiful hardware have OS bug when he was young, created situations where an OS is used for running a single application. and is still searching for a But some questions arise: Do we need the OS at all? And by including an patch. He has held a NetBSD I OS, are we only gaining an increased memory footprint and attack surface? commit bit for fifteen years and This article introduces rump kernels, which provide NetBSD kernel drivers for the previous seven of them he has been working on rump kernels. As a so-called day as portable components, allowing you to run applications without an operat- job, Antti runs a one-man “systems design and ing system. implementation consulting” show. There is still a reason to run an OS: Operating systems provide unparalleled driver support, [email protected] e.g., TCP/IP, SCSI, and USB stacks, file systems, POSIX system call handlers, and hardware device drivers. As the name rump kernel suggests, most of the OS functionality not related to Justin Cormack accidentally drivers is absent, thereby reducing a rump kernel’s footprint and attack surface. wandered into a room full of UNIX workstations at MIT in For example, a rump kernel does not provide support for executing binaries, scheduling the early 1990s and has been threads, or managing hardware privilege levels. Yet rump kernels can offer a complete using various flavors ever since. enough environment to support unmodified POSIXy applications on top of them (Figure He started working with rump kernels last year 1). -
Rumprun for Rump Kernels: Instant Unikernels for POSIX Applications
Rumprun for Rump Kernels: Instant Unikernels for POSIX applications Martin Lucina, @matolucina 1 / 8 So many Kernels, what are they? Monolithic kernel, Microkernel: standard stuff. Rump kernel: an existing monolithic kernel componentized into an anykernel. Mix and match kernel components any way you want. Unikernel: turns the OS into a “library” for a single application. Normally requires writing your application from the ground up for the Unikernel. Mirage OS, for example. Rump kernels Today's talk by @anttikantee has all the details, won't repeat them here. Many different use cases: Use Rump Kernels to bootstrap a new OS quickly. Use Rump Kernel components directly in a userspace application. Use Rump Kernels as Unikernels for unmodified POSIX applications. The last point is what will be demonstrated in this talk. 2 / 8 Rump kernels as Unikernels for POSIX applications Rump kernels already provide most of the components we need: Core system calls. File systems, network stack, device drivers, ... What else do we need? 1. Threads, scheduling, memory management, locking, event handling (interrupts): Provided by the hypervisor and “firmware”. 2. A C library: We re-use the NetBSD libc with minimal modifications. 3. A magic* build system: app-tools. 4. A magic* deployment system: rumprun. * One that just works. No fiddling. 3 / 8 Rumprun We need an easy way to provision and deploy the application on the various different stacks: Configure network devices. Configure block devices and mount filesystems. Platform-specific launching (Xen, KVM, ...). The rumprun tool and rumpconfig module which I have been working on is the beginning of this: rumprun xen -di -n inet,static,10.10.10.10/16 \ -b images/stubetc.iso,/etc \ -b images/data.iso,data \ .../mathopd -n -f /data/mathopd.conf The Xen version uses Xenstore to communicate configuration to the application.