DOCSLIB.ORG

System Architectures for Data Confidentiality and Frameworks for Main Memory Extraction

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
System Architectures for Data Confidentiality and Frameworks for Main Memory Extraction Fakultät für Informatik der Technischen Universität München Lehrstuhl für Sicherheit in der Informatik System Architectures for Data Confidentiality and Frameworks for Main Memory Extraction Manuel Huber Dissertation Fakultät für Informatik der Technischen Universität München Lehrstuhl für Sicherheit in der Informatik System Architectures for Data Confidentiality and Frameworks for Main Memory Extraction Manuel Huber Vollständiger Abdruck der von der Fakultät für Informatik der Technischen Universität München zur Erlangung des akademischen Grades eines Doktors der Naturwissenschaften (Dr. rer. nat.) genehmigten Dissertation. Vorsitzender: Prof. Dr. Jörg Ott Prüfer der Dissertation: 1. Prof. Dr. Claudia Eckert 2. Prof. Dr. Georg Sigl Die Dissertation wurde am 25.09.2019 bei der Technischen Universität München eingereicht und durch die Fakultät für Informatik am 02.12.2019 angenommen. Abstract The sensitive data our modern computing systems process, transmit, and store poses a highly valuable target for cybercriminals and forensic investigators. Ranging from mobile devices and embedded devices in the internet of things to desktop and server environments, all systems expose characteristic vulnerabilities exploitable by remote and physical attack vectors of different sophistication. A resulting disclosure of confidential data, such as key material, passwords or classified documents, can lead to severe consequences for individuals, organizations and governmental bodies. The goal of this work is both the systematic protection of confidential data and the investigation of attack vectors to acquire confidential data. For the systematic protection, we design system architectures which assure data confidentiality on modern systems in the presence of both remote and physical adversaries. For the investigation of attack vectors, we develop sophisticated data extraction frameworks to demonstrate the potential of adversaries and to urge the need for carefully designed system architectures. We pursue a systematic approach where we first design a secure architecture to isolate system resources based on OS-level virtualization. The architecture enables different isolated execution environments, called containers, to restrict remote adversaries exploiting a vulnerable container from accessing other containers possibly processing confidential data. While the design is generally platform-independent, we first tailor the architecture to mobile devices. This enables us to operate multiple virtualized Android containers on a single device having one container run in foreground and the others in background. We further demonstrate the applicability of this architecture in real-world ecosystems by providing a holistic security concept. This concept covers identity management and device provisioning and enrollment based on a public key infrastructure and secure elements for users, such as smartcards. In the next step, we tailor the architecture to embedded use cases, such as to platforms for the internet of things or cyber-physical systems. We demonstrate how to integrate the architecture into productive environments at the example of a cross-domain data exchange platform connecting organizations. While our virtualization architectures for resource isolation defend against remote adversaries, these do not remediate physical memory attack scenarios, such as cold boot or DMA attacks. These attacks make it possible to extract the confidential data stored in main memory while circumventing OS protection mechanisms. To emphasize the urge for the protection of data against physical adversaries, we design a framework for cold boot attacks on mobile devices. Our framework enables the systematic extraction of data from the main memory of mobile devices. Since the main memory is not encrypted and thus stored in plaintext on common systems, memory extraction leveraging the cold boot attack is not only limited to mobile devices. v vi To counter the threat of memory attacks from physical attack vectors, we design main memory encryption architectures for different types of systems. For notebooks and desktop systems, we introduce an architecture to encrypt the main memory during device suspension. This makes memory attacks futile on suspended, likely unattended devices. While we also design this architecture for environments virtualized with a hypervisor, it does not apply to the different usage model of mobile devices. The operating systems of mobile devices donot fully suspend to support background activities in the absence or inactivity of the users. To also enable memory protection on mobile devices, we develop a main memory encryption architecture on the granularity of process groups. We combine our secure virtualization and main memory encryption architectures, making it possible to encrypt main memory of individual containers. We keep actively used containers in normal operation and encrypt suspended containers in background. The combination of the architectures not only protects the Android containers from remote adversaries, but also from physical attackers once suspended. For systems which do not necessarily suspend, such as embedded IoT devices, we present an alternate architecture for transparent runtime memory encryption based on a minimal hypervisor. When encrypting memory at runtime, attackers may still fully interact with the non- suspended systems. We point out that such encryption techniques require particularly careful design by developing a memory extraction framework targeting virtual machines on server systems that leverage hardware extensions for transparent runtime memory encryp- tion. Our framework makes it possible to fully extract the memory of encrypted virtual machines possibly being under heavy load, such as virtual machines hosting productive web servers open to the public. We additionally equip our framework with techniques to specifically extract targeted resources in short time, such as TLS, SSH, or disk encryption keys, requiring only minimal interaction with the system and leaving only a small footprint. Kurzfassung Die sensitiven Daten, die unsere heutigen Systeme verarbeiten, übertragen und speichern stellen für Kriminelle und Forensiker ein äußerst attraktives Ziel dar. Zu diesen Systemen zählen beispielsweise mobile Endgeräte, eingebettete Geräte für das Internet der Dinge, aber auch Desktop- und Serverumgebungen. All diese Systeme weißen charakteristische Schwachstellen auf, welche beiderseits von physischen Angreifern und Angreifern über ent- fernte Schnittstellen hinweg mittels Angriffsvektoren verschiedener Komplexität ausgenutzt werden können. Eine resultierende Enthüllung vertraulicher Daten, wie etwa Schlüssel- material, Passwörter oder klassifizierter Dokumente, kann zu starken Konsequenzen für Einzelpersonen, aber auch für Organisationen und Behörden führen. Das Ziel dieser Arbeit ist beiderseits der systematische Schutz vertraulicher Daten, als auch das Untersuchen von Angriffsvektoren, um an vertrauliche Daten zu gelangen. Für den systematischen Schutz entwerfen wir Systemarchitekturen, die die Vertraulichkeit von Daten auf modernen Rechengeräten unter der Bedrohungssituation von beiderseits entfernten und physisch präsenten Angreifern sicherstellen. Zur Untersuchung von Angriffsvektoren entwickeln wir fortgeschrittene Rahmenwerke zur Extrahierung von Daten, um das Potential von An- greifern zu demonstrieren und um den Bedarf für sorgfältig entworfene Systemarchitekturen zu motivieren. Wir verfolgen hierbei einen systematischen Ansatz, bei dem wir zunächst eine Sicher- heitsarchitektur entwerfen, welche Systemressourcen auf Basis von Virtualisierung auf Betriebssystem-Ebene isoliert. Diese Architektur ermöglicht es, verschiedene voneinander isolierte Ausführungsumgebungen, sogenannte Container, zu betreiben, um Angreifer, die eine Software-Schwachstelle eines verwundbaren Containers ausnutzen, innerhalb des Con- tainers zu isolieren. Dies bewahrt andere Container mit deren vertraulichen Daten vor den Auswirkungen des Angriffs. Während der Architekturentwurf generell plattformunabhängig ist, schneiden wir die Architektur zunächst auf mobile Endgeräte zu, auf denen wir mehrere, virtualisierte Android-Container betreiben. Dabei läuft ein Container für den Nutzer sichtbar im Vordergrund und die anderen Container im Hintergrund. Des weiteren demon- strieren wir die Anwendbarkeit der Architektur innerhalb produktiv genutzter Ökosysteme durch Bereitstellen eines ganzheitlichen Sicherheitskonzepts. Dies beinhaltet das Verwalten von Identitäten, sowie Geräteprovisionierung und -ausrollung, basierend auf einer Infras- truktur mit öffentlichen Schlüsselpaaren und Sicherheitselementen, wie Chipkarten, für Endnutzer. Im nächsten Schritt schneiden wir die Architektur auf Benutzungsszenarien im Bereich eingebetteter Systeme zu, wie zum Beispiel auf Plattformen im Internet der Dinge, oder auf Cyber-physische Systeme. Wir beschreiben darüber hinaus die Integration dieser Architektur in produktive Umgebungen am Beispiel einer Bereichsgrenzen überschreitenden Plattform zum Datenaustausch zwischen Organisationen. vii viii Während die Sicherheitsarchitekturen zur Isolation von Ausführungsumgebungen gegen Angreifer wirkt, welche Softwareschwachstellen ausnutzen, verhindert diese aber nicht die Angriffsszenarien auf den Hauptspeicher durch physische Angreifer. Ein Beispiel dafür sind Kaltstart- oder DMA-Attacken, welche es ermöglichen, vertrauliche, im Hauptspe- icher abgelegte Daten unter umgehen der Schutzmechanismen der Betriebssysteme
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]
  • 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]
  • 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]
  • Reducing Power Consumption in Mobile Devices by Using a Kernel
    IEEE TRANSACTIONS ON MOBILE COMPUTING, VOL. Z, NO. B, AUGUST 2017 1 Reducing Event Latency and Power Consumption in Mobile Devices by Using a Kernel-Level Display Server Stephen Marz, Member, IEEE and Brad Vander Zanden and Wei Gao, Member, IEEE E-mail: [email protected], [email protected], [email protected] Abstract—Mobile devices differ from desktop computers in that they have a limited power source, a battery, and they tend to spend more CPU time on the graphical user interface (GUI). These two facts force us to consider different software approaches in the mobile device kernel that can conserve battery life and reduce latency, which is the duration of time between the inception of an event and the reaction to the event. One area to consider is a software package called the display server. The display server is middleware that handles all GUI activities between an application and the operating system, such as event handling and drawing to the screen. In both desktop and mobile devices, the display server is located in the application layer. However, the kernel layer contains most of the information needed for handling events and drawing graphics, which forces the application-level display server to make a series of system calls in order to coordinate events and to draw graphics. These calls interrupt the CPU which can increase both latency and power consumption, and also require the kernel to maintain event queues that duplicate event queues in the display server. A further drawback of placing the display server in the application layer is that the display server contains most of the information required to efficiently schedule the application and this information is not communicated to existing kernels, meaning that GUI-oriented applications are scheduled less efficiently than they might be, which further increases power consumption.
    [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]
  • Ivoyeur: Inotify
    COLUMNS iVoyeur inotify DAVE JOSEPHSEN Dave Josephsen is the he last time I changed jobs, the magnitude of the change didn’t really author of Building a sink in until the morning of my first day, when I took a different com- Monitoring Infrastructure bination of freeways to work. The difference was accentuated by the with Nagios (Prentice Hall T PTR, 2007) and is Senior fact that the new commute began the same as the old one, but on this morn- Systems Engineer at DBG, Inc., where he ing, at a particular interchange, I would zig where before I zagged. maintains a gaggle of geographically dispersed It was an unexpectedly emotional and profound metaphor for the change. My old place was server farms. He won LISA ‘04’s Best Paper off to the side, and down below, while my future was straight ahead, and literally under award for his co-authored work on spam construction. mitigation, and he donates his spare time to the SourceMage GNU Linux Project. The fact that it was under construction was poetic but not surprising. Most of the roads I [email protected] travel in the Dallas/Fort Worth area are under construction and have been for as long as anyone can remember. And I don’t mean a lane closed here or there. Our roads drift and wan- der like leaves in the water—here today and tomorrow over there. The exits and entrances, neither a part of this road or that, seem unable to anticipate the movements of their brethren, and are constantly forced to react.
    [Show full text]
  • Hypervisors Vs. Lightweight Virtualization: a Performance Comparison
    2015 IEEE International Conference on Cloud Engineering Hypervisors vs. Lightweight Virtualization: a Performance Comparison Roberto Morabito, Jimmy Kjällman, and Miika Komu Ericsson Research, NomadicLab Jorvas, Finland [email protected], [email protected], [email protected] Abstract — Virtualization of operating systems provides a container and alternative solutions. The idea is to quantify the common way to run different services in the cloud. Recently, the level of overhead introduced by these platforms and the lightweight virtualization technologies claim to offer superior existing gap compared to a non-virtualized environment. performance. In this paper, we present a detailed performance The remainder of this paper is structured as follows: in comparison of traditional hypervisor based virtualization and Section II, literature review and a brief description of all the new lightweight solutions. In our measurements, we use several technologies and platforms evaluated is provided. The benchmarks tools in order to understand the strengths, methodology used to realize our performance comparison is weaknesses, and anomalies introduced by these different platforms in terms of processing, storage, memory and network. introduced in Section III. The benchmark results are presented Our results show that containers achieve generally better in Section IV. Finally, some concluding remarks and future performance when compared with traditional virtual machines work are provided in Section V. and other recent solutions. Albeit containers offer clearly more dense deployment of virtual machines, the performance II. BACKGROUND AND RELATED WORK difference with other technologies is in many cases relatively small. In this section, we provide an overview of the different technologies included in the performance comparison.
    [Show full text]
  • Onload User Guide
    Onload User Guide Copyright © 2017 SOLARFLARE Communications, Inc. All rights reserved. The software and hardware as applicable (the “Product”) described in this document, and this document, are protected by copyright laws, patents and other intellectual property laws and international treaties. The Product described in this document is provided pursuant to a license agreement, evaluation agreement and/or non‐disclosure agreement. The Product may be used only in accordance with the terms of such agreement. The software as applicable may be copied only in accordance with the terms of such agreement. Onload is licensed under the GNU General Public License (Version 2, June 1991). See the LICENSE file in the distribution for details. The Onload Extensions Stub Library is Copyright licensed under the BSD 2‐Clause License. Onload contains algorithms and uses hardware interface techniques which are subject to Solarflare Communications Inc patent applications. Parties interested in licensing Solarflare's IP are encouraged to contact Solarflare's Intellectual Property Licensing Group at: Director of Intellectual Property Licensing Intellectual Property Licensing Group Solarflare Communications Inc, 7505 Irvine Center Drive Suite 100 Irvine, California 92618 You will not disclose to a third party the results of any performance tests carried out using Onload or EnterpriseOnload without the prior written consent of Solarflare. The furnishing of this document to you does not give you any rights or licenses, express or implied, by estoppel or otherwise, with respect to any such Product, or any copyrights, patents or other intellectual property rights covering such Product, and this document does not contain or represent any commitment of any kind on the part of SOLARFLARE Communications, Inc.
    [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]
  • Systemd As a Container Manager
    systemd as a Container Manager Seth Jennings [email protected] Texas Linux Fest 2015 8/21/2015 Agenda ● Very quick overview of systemd ● What is a Linux Container ● systemd as a Container Manager ● Live Demo! Because I like to punish myself! Disclaimer What is systemd? ● systemd is a suite of system management daemons, libraries, and utilities designed as a central management and configuration platform for the Linux operating system. How Big Is This “Suite” ● systemd - init process, pid 1 ● journald ● logind ● udevd ● hostnamed ● machined ● importd ● networkd ● resolved ● localed ● timedated ● timesyncd ● and more! Don't Leave! ● No deep dive on all of these ● Focus on using systemd for container management – Spoiler alert: many of the systemd commands you already use work on containers managed by systemd too! What is a Linux Container ● What it is not – Magic ● conjured only from the mystical language of Go – Virtualization (hardware emulation) – A completely new concept never before conceived of by man since time began – An image format – An image distribution mechanism – Only usable by modular (microservice) applications at scale What is a Linux Container ● A resource-constrained, namespaced environment, initialized by a container manager and enforced by the kernel, where processes can run – kernel cgroups limits hardware resources ● cpus, memory, i/o ● special cgroup filesystem /sys/fs/cgroup – kernel namespacing limits resource visibility ● mount, PID, user, network, UTS, IPC ● syscalls clone(), setns(), unshare() What is a Linux Container ● The set of processes in the container is rooted in a process that has pid 1 inside the pid namespace of the container ● The filesystem inside the container can be as complex as a docker image or as simple as a subdirectory on the host (think chroot).
    [Show full text]
  • Programmer's Guide
    Programmer’s Guide Release 18.11.11 Jan 20, 2021 CONTENTS 1 Introduction 1 1.1 Documentation Roadmap...............................1 1.2 Related Publications..................................2 2 Overview 3 2.1 Development Environment..............................3 2.2 Environment Abstraction Layer............................4 2.3 Core Components...................................4 2.3.1 Ring Manager (librte_ring)..........................4 2.3.2 Memory Pool Manager (librte_mempool)..................4 2.3.3 Network Packet Buffer Management (librte_mbuf).............6 2.3.4 Timer Manager (librte_timer)........................6 2.4 Ethernet* Poll Mode Driver Architecture.......................6 2.5 Packet Forwarding Algorithm Support........................6 2.6 librte_net........................................6 3 Environment Abstraction Layer7 3.1 EAL in a Linux-userland Execution Environment..................7 3.1.1 Initialization and Core Launching......................8 3.1.2 Shutdown and Cleanup...........................8 3.1.3 Multi-process Support............................8 3.1.4 Memory Mapping Discovery and Memory Reservation..........8 3.1.5 Support for Externally Allocated Memory.................. 11 3.1.6 Per-lcore and Shared Variables....................... 12 3.1.7 Logs...................................... 12 3.1.8 CPU Feature Identification.......................... 12 3.1.9 User Space Interrupt Event......................... 13 3.1.10 Blacklisting.................................. 14 3.1.11 Misc Functions...............................
    [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]