DOCSLIB.ORG

The Flux OS Toolkit

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
The Flux OS Toolkit The Flux OS Toolkit: Reusable Components for OS Implementation Bryan Ford Kevin Van Maren Jay Lepreau Stephen Clawson Bart Robinson Jeff Turner Department of Computer Science, University of Utah Salt Lake City, UT 84112 [email protected] http://www.cs.utah.edu/projects/flux/ Abstract 1 Introduction To an unappreciated degree, research both in operating As operating system functionality continues to expand systems and their programming languages has been severely and diversify, it is increasingly impractical for a small group hampered by the lack of cleanly reusable code providing to implement even a basic useful OS coreÐe.g., the func- mundane low-level OS infrastructure such as bootstrapcode tionality traditionally found in the Unix kernelÐentirely and device drivers. The Flux OS Toolkit solves this problem from scratch. Furthermore, in most research domains, only by providing a set of clean, well-documented components. a few speci®c areas provide fodder for interesting research These components can be used as basic buildingblocks both topics. For example, from reading an OS conference pro- for operating systems and for booting language run-time ceedings, one might be given the impression that build- systems directly on the hardware. The toolkit's implementa- ing an OS ªonlyº involves writing a virtual memory sys- tion itself embodies reuse techniques by incorporating com- tem, an IPC system, a ®le system, a scheduler, some fast ponents such as device drivers, ®le systems, and network- local-area network code, and a pro®ler to produce nice bar ing code, unchanged, from other sources. We believe the kit charts. However, as any experienced OS builder knows, also makes feasible the production of highly assured embed- many of the problems involved in building an OS have al- ded and operating systems: by enabling reuse of low-level ready been solved countless times, and just aren't interest- code, the high cost of detailed veri®cation of that code can ing to researchers. For example, any realistic OS, in or- be amortized over many systems for critical environments. der to be useful even for research, typically includes boot The OS toolkit is already heavily used in several different loader code, kernel startup code, various device drivers, ker- OS and programming language projects, and has already nel printf and malloc code, a kernel debugger, etc. A catalyzed research and development that would otherwise research project starting a new OS completely from scratch never have been attempted. would invariably spend at least the ®rst six months simply writing such infrastructure ªgrungeº before even starting on the interesting aspects of the OS. 1.1 Related work Most OS researchers have realized this problem of high This researchwas supportedin part by the DefenseAdvancedResearch Projects Agency, monitored by the Department of the Army under contract startup cost, and have resorted to cannibalizing BSD, Mach, number DABT63±94±C±0058, and Rome Laboratory, Air Force Material or other freely available OSes rather than reinventing the Command, USAF, underagreementnumber F30602±96±2±0269. The U.S. wheel. Mach used BSD, Linux [13], and vendors' device Government is authorized to reproduce and distribute reprints for Govern- drivers; SPIN [3] uses device drivers from FreeBSD; and mental purposes notwithstanding any copyright annotation hereon. ¡ U.S. Department of Defense VINO [17] takes its device drivers, bootstrap code, and low- Copyright 1997IEEE. Personal use of this material is permitted. How- level support for virtual memory from NetBSD. ever, permission to reprint/republish this material for advertising or promo- While this approach saves time, the developer must man- tional purposesor for creating new collective works for resale or redistribu- tion to servers or lists, or to reuse any copyrighted component of this work ually examine and dissect the old OS; it would save even in other works must be obtained from the IEEE. more time if the developer could simply obtain a set of 1 clearly-documented components. It would also enable re- in Fluke's atomic operations [18]), which took only a month. search by those whose primary expertise is in areas other We have found this ability to prototype radical designs in a than operating systems, e.g., programming language re- ªrealº kernel to be crucial to choosing designs that are worth searchers who wish to explore the effects of higher-level lan- fully developing. guages runningdirectly on the hardware. This is the purpose of the Flux OS Toolkit. Recent research projects such as Exokernel [6], SPIN [3], 2 Toolkit design and VINO [17], focus on creating extensible systems which allow applications to modify the behavior of the core OS to suit their particular needs. However, these systems still de- ®ne a particular, ®xed set of ªcoreº functionality and a set of The Flux OS Toolkit is a framework and set of modular- policies by which the core can be used and extended. The ized library code, together with extensive documentation [9] OS Toolkit, in contrast, makes no attempt to be a useful OS for the construction of operating system kernels, servers, in itself and does not de®ne any particular set of ªcoreº func- and other core OS functionality. The goal is for develop- tionality, but merely provides a suite of components from ers to take the OS Kit and immediately have a starting point which real OSes can be built. for investigating ªrealº OS issues such as scheduling, VM, Other approaches involved creating an operating system IPC, ®le systems, or security. Researchers in programming built from a complex object-oriented framework, such as languages for systems software bene®t as well, as the toolkit in the Choices[5] or Taligent [15] work. Although such makes it easy to run language systems on the bare hardware. efforts have been in¯uential in other OS projects, such as The intention of this toolkit is not to ªwrite the OS for Spring, they do not appear to have been widely used. In con- youº; we certainly want to leave the OS writing to the OS trast, the OS Kit exhibits a less ambitious, but more prag- writer. The dividing line between the ªOSº and the ªOS matic, and we believe more effective, approach to software Toolkit,º as we see it, is basically the line between what OS design and re-use. Gabriel distinguished two approaches writers want to write and what they would otherwise have to software design and implementation, sardonically label- to write but don't really want to. Naturally this will vary ing them ªThe Right Thingº and ªWorse is Betterº [12]. among different OS groups and developers. If you really The former is characterized by interface perfection at the want to write your own x86 protected-mode startup code, or cost of implementation complexity (e.g., Lisp with CLOS), have found a clever way to do it ªbetter,º you are perfectly whereas the latter sacri®ces interface elegance and com- free to do so and simply not use the corresponding code in pleteness for simplicity of implementation (e.g., Unix and our toolkit. However, the OS Kit is modular enough so that C). Gabriel makes a strong case that ªWorse is Betterº is the you can still easily use other parts of it to ®ll in other func- more sucessful approach, and we believe that the OS Kit ex- tional areas you don't want to have to deal with yourself (or empli®es this lesson. areas that you just don't have time to do ªyet.º) As such, the toolkit is designed to be usable either as a 1.2 Historical genesis of the OS Toolkit whole or in arbitrary subsets, as requirements dictate. It is useful not only for kernels but also for other OS-related pro- We followed the cannibalization approach in our own OS grams, such as boot loaders or servers running on top of a research for some time. However, starting in 1995, that ap- microkernel. proach gradually evolved, resultingin what became the Flux While the OS Kit currently runs on x86 PCs, it is de- OS Toolkit, or ªOS Kitº. Because we were ®nding our ver- signed to be portable to other architectures, and most of the sion of Mach [11] too constraining a vehicle in which to OS Kit's exported interfaces are architecture-neutral. Most prototype new ideas, we developed a series of experimen- of the heavily architecture-speci®c aspects of the OS Kit are tal kernels to try out ideas before designing our Fluke ker- isolated in a single component, the low-level kernel support nel [10]. In doing so, we gradually modularized and for- library, whose purpose is to provide easy access to the raw malized the libraries of support code we developed, proto- privileged-mode hardware facilities without adding over- typing the OS Kit along the way. These experimental ker- head or obscuring the underlying abstractions. For exam- nels embodied radical changes to fundamental aspects of OS ple, on the x86, the kernel support library includes functions structure which would have been impossible to explore in to directly create and manipulate x86 page tables and seg- an existing operating system. One of these kernels explored ment registers. Other OS Kit components can, and often implementations of high performance kernel-mediated ca- do, provide higher-level architecture-neutral facilities built pabilities and IPC paths, and took about 2 weeks to develop on these low-level mechanisms; however, the architecture- from scratch; the other explored interruptibilityof kernel op- speci®c interfaces always remain accessible in order to pro- erations at arbitrary points (®nding a more ®nal expression vide maximum ¯exibility. 2 3 Sample components boots from standard boot loaders is as easy as writing an or- dinary ªHello Worldº application in C.
Load more

Recommended publications
  • Moving FLASK to BSD Systems
    MovingMoving FLASKFLASK toto BSDBSD SSystemsystems SELinux Symposium 2006 Chris Vance Information Systems Security Operation, SPARTA, Inc. Vance_20060301_01 Overview • Security Frameworks • A Brief History • SELinux Inspired… – Security Enhanced BSD – Security Enhanced Darwin Vance_20060301_02 Security Frameworks • Traditional UNIX security isn’t enough – OS hardening – Mandatory protection – Flexible, manageable, scalable protection • Support required in the operating system for new security services – Costs of locally maintaining security extensions are high – Framework offers extensibility so that policies may be enhanced without changing the base operating system • There does not appear to be one perfect security model or policy – Sites may have different security/performance trade-offs – Sites may have special local requirements – Vendors unlikely to adopt a single policy • Bottom Line: Frameworks for Linux, FreeBSD, Darwin Vance_20060301_03 How We Got Here… Vance_20060301_04 Focus and Reuse • Don’t “reinvent” security – Learn from the past – The research is often decades old – A good design is durable, doesn’t require constant change – FLASK hasn’t changed much recently, what’s that mean? • Leverage existing technology, focus on “new” issues – Focus on improving operating system security – Spend the time to get Frameworks correct – Work with vendor for acceptance – Develop rule sets that work – Develop effective tools to manage policy • Do innovate – Don’t stop thinking! – Don’t squash new ideas – Re-factor old ideas Vance_20060301_05
    [Show full text]
  • Operating System Structure
    Operating System Structure Joey Echeverria [email protected] modified by: Matthew Brewer [email protected] Nov 15, 2006 Carnegie Mellon University: 15-410 Fall 2006 Overview • Motivations • Kernel Structures – Monolithic Kernels ∗ Kernel Extensions – Open Systems – Microkernels – Exokernels – More Microkernels • Final Thoughts Carnegie Mellon University: 15-410 Fall 2006 1 Motivations • Operating systems have a hard job. • Operating systems are: – Hardware Multiplexers – Abstraction layers – Protection boundaries – Complicated Carnegie Mellon University: 15-410 Fall 2006 2 Motivations • Hardware Multiplexer – Each process sees a “computer” as if it were alone – Requires allocation and multiplexing of: ∗ Memory ∗ Disk ∗ CPU ∗ IO in general (network, graphics, keyboard etc.) • If OS is multiplexing it must also allocate – Priorities, Classes? - HARD problems!!! Carnegie Mellon University: 15-410 Fall 2006 3 Motivations • Abstraction Layer – Presents “simple”, “uniform” interface to hardware – Applications see a well defined interface (system calls) ∗ Block Device (hard drive, flash card, network mount, USB drive) ∗ CD drive (SCSI, IDE) ∗ tty (teletype, serial terminal, virtual terminal) ∗ filesystem (ext2-4, reiserfs, UFS, FFS, NFS, AFS, JFFS2, CRAMFS) ∗ network stack (TCP/IP abstraction) Carnegie Mellon University: 15-410 Fall 2006 4 Motivations • Protection Boundaries – Protect processes from each other – Protect crucial services (like the kernel) from process – Note: Everyone trusts the kernel • Complicated – See Project 3 :) – Full
    [Show full text]
  • Chapter 2 Operating System Structures
    Operating Systems Associate Prof. Yongkun Li 中科大-计算机学院 副教授 http://staff.ustc.edu.cn/~ykli Chapter 2 Operating System Structures 1 Objectives • Operating System Services – User Operating System Interface – System Calls • Operating System Structure • Operating System Design and Implementation • MISC: Debugging, Generation & System Boot 2 Operating System Services Services Overview, User Interface 3 Operating System Services • Operating systems provide – an environment for execution of programs and – services to programs and users • Services may differ from one OS to another • What are the common classes? – Convenience of the user – Efficiency of the system 4 Overview of Operating System Services 5 OS Services for Helping Users • User interface - Almost all operating systems have a user interface (UI). – Three forms • Command-Line (CLI) – Shell command • Batch – Shell script • Graphics User Interface (GUI) – Windows system 6 OS Services for Helping Users • Program execution – Load a program into memory – Run the program – End execution • either normally or • abnormally (indicating error) 7 OS Services for Helping Users • I/O operations - A running program may require I/O, which may involve a file or an I/O device – Common I/Os: read, write, etc. – Special functions: recording CD/DVD • Notes: Users usually cannot control I/O devices directly, so OS provides a mean to do I/O – Mainly for efficiency and protection 8 OS Services for Helping Users • File-system manipulation - The file system is of particular interest – OS provides a variety of file systems • Major services – read and write files and directories – create and delete files and directories – search for a given file – list file Information – permission management: allow/deny access 9 OS Services for Helping Users • Communications: information exchange between processes – Processes on the same computer – Processes between computers over a network • Implementations – Shared memory • Two or more processes read/write to a shared section of mem.
    [Show full text]
  • Darwin: Mac OS X's Core OS
    ADC April 2001 3/8/01 1:57 PM Page 1 Apple Developer Connection Direct Darwin: Mac OS X’s Core OS eneath Mac OS X’s user-friendly and attractive user interface, Most of the reference documents can be Aqua, and the application frameworks (Classic, Carbon and found in the /Developer/Documentation/ BCocoa) is Darwin: Mac OS X’s core OS. Unseen by users, Kernel directory on any Mac OS X system Darwin provides a strong yet flexible foundation with features like with the Mac OS X Developer Tools package preemptive multitasking, protected memory and real-time support installed. that make Mac OS X a truly modern operating system. The focus of this article is to provide a brief overview of Components of Darwin Darwin and its components as well as give an introduction to Just like in the old Reese’s Peanut Butter developing kernel extensions—modules that extend Darwin’s Cups commercials (“You’ve got chocolate in functionality. For more in-depth information, you should read my peanut butter… No, you’ve got peanut butter on my choco- Inside Mac OS X: Kernel Environment which is available, along late!”), Darwin blends a mixture of mature industry standard com- with other documents referred to in this article, on the Apple ponents such as Mach and BSD with Apple-engineered components Developer Connection (ADC) web site in the Mac OS X to provide Mac OS X with a stable, reliable and extensible founda- Documentation section: tion. Darwin consists of five main components: Mach, I/O Kit, File http://developer.apple.com/techpubs/macosx/macosx.html System, Networking and BSD.
    [Show full text]
  • Mach-O Internals
    Mach-O Internals William Woodru February 10, 2016 1 / 31 General Agenda 1. Who are you? 2. What is Mach-O? 3. An Extremely Brief History of Mach and Mach-O 4. Structure of a Mach-O File 5. Quirks Encountered 6. Concluding Notes 2 / 31 Who are you? My name is William Woodru. I'm a Computer Science major and Philosophy minor at the University of Maryland, College Park. Outside of school, I'm a member of the Homebrew project and a regular contributor to several open source groups. My work for Homebrew is largely concerned with the underlying system interface and reconciling OS X's intricacies/irregularities with the package manager. 3 / 31 What is Mach-O? Mach-O is the Mach Object binary format. Mach-O is used primarily by Apple in OS X and iOS. Apps on both platforms are really just directory trees containing Mach-O binaries and resources (fonts, icons, congurations). Metadata is stored in a number of places, but mainly within bundled plists (XML) and the binaries themselves. Like its cousins on Linux (ELF) and Windows (PE), Mach-O supports multiple object types: I Executable I Core dump I Shared library/object I Prelinked object le I etc. 4 / 31 . and multiple architectures: I m68k/m88k (yes, it's still supported!*) I x86 I AMD64 I POWER I ARMv6/7/8 Unlike ELF or PE, Mach-O has been extended to allow multi-architecture fat binaries. This has resulted in some interesting properties not shared by the other two. More on that later.
    [Show full text]
  • Evolving Mach 3.0 to a Migrating Thread Model
    Evolving Mach to a Migrating Thread Mo del Bryan Ford Jay Lepreau University of Utah Abstract Wehave mo died Mach to treat crossdomain remote pro cedure call RPC as a single entity instead of a sequence of message passing op erations With RPC thus elevated we improved the transfer of control during RPC bychanging the thread mo del Like most op erating systems Mach views threads as statically asso ciated with a single task with two threads involved in an RPC An alternate mo del is that of migrating threads in which during RPC a single thread abstraction moves b etween tasks with the logical owofcontrol and server co de is passively executed Wehave compatibly replaced Machs static threads with migrating threads in an attempt to isolate this asp ect of op erating system design and implementation The key elementof our design is a decoupling of the thread abstraction into the execution context and the schedulable thread of control consisting of a chain of contexts A key element of our implementation is that threads are now based in the kernel and temp orarily make excursions into tasks via up calls The new system provides more precisely dened semantics for thread manipulation and additional control op erations allows scheduling and accounting attributes to follow threads simplies kernel co de and improves RPC p erformance Wehave retained the old thread and IPC interfaces for backwards compatibility with no changes required to existing client programs and only a minimal change to servers as demonstrated by a functional Unix single server
    [Show full text]
  • Mach: a System Software Kernel Abstract
    Mach: A System Software Kernel Richard Rashid, Daniel Julin, Douglas Orr, Richard Sanzi, Robert Baron, Alessandro Forin, David Golub, Michael Jones Department of Computer Science Carnegie Mellon University Pittsburgh, Pennsylvania 15213 Abstract for a 16-bit uniprocessor. Under the weight of changing needs and technology, Unix has been modified to provide a The Mach operating system can be used as a system staggering number of different mechanisms for managing ob- software kernel which can support a variety of operating jects and resources. In addition to pipes, Unix versions now system environments. Key elements of the Mach design support facilities such as System V streams, 4.2BSD sockets, which allow it to efficiently support system software include pty's, various forms of semaphores, shared memory and a integrated virtual memory management and interprocess com- munication, multiple threads of control within one address mind-boggling array of ioctl operations on special files and space, support for transparent system trap callout and an ob- devices. The result has been scores of additional system calls ject programming facility integrated with the Mach IPC and options with less than uniform access to different mechanisms. Mach is currently available both from CMU resources within a single Unix system and within a network of and commercially on a wide range of uniprocessor and mul- tiprocessor hardware. Unix machines. The Mach operating system kernel developed at Carnegie 1. Introduction Mellon University [1] was designed to operate on both uniprocessors and multiprocessors and to provide a small set The operating system software problems faced by manufac- of basic facilities which would permit a wide variety of turers are often magnified by a need for compatibility be- operating system environments to be efficiently implemented.
    [Show full text]
  • 01.Answers Even.Osx
    1 Answers to Even-numbered Exercises 1. 2. What is the Free Software Foundation/GNU? BSD? Mach? Which parts of the Mac OS X operating system did each provide? The Free Software Foundation (www.fsf.org) is the principal organizational sponsor of the GNU Project. GNU developed many of the tools, including the C compiler, that are part of Mac OS X. BSD stands for Berkeley Software Distribution; it describes the code released by the University of California at Berkeley. Mach is an operating system kernel developed at CMU. Mac OS X uses some GNU tools, such as the GNU C compiler, and the bash shell, a lot of BSD tools and utilities, and the Mach kernel. 3. 4. How can you use utility programs and a shell to create your own applications? You can write a shell script, also called a shell program, or a batch file under DOS. A shell script is one or more command lines contained in a file. Make the file executable and give the name of the file as a command: The shell then executes the commands in the file as though you had typed each command individually. (You may need to give the command as ./command.) 5. 6. What is the difference between a multiprocessor and a multiprocessing system? Multiprocessor (having more than one processor) refers to a system with two or more processors or CPUs. Multiprocessing (supporting multiple processes) refers to a system that can process one or more tasks at a time. 1 2 Answers to Even-numbered Exercises 7. 8.
    [Show full text]
  • An Operating System
    Page 1 of 7 What is an Operating System 2.1 Examples: An operating system (OS) is software that manages computer hardware and software resources and provides common services for computer programs. The operating system is an essential component of the system software in a computer system. Application programs usually require an operating system to function. Unix and Unix-like operating systems Unix was originally written in assembly language.[6] Ken Thompson wrote B, mainly based on BCPL, based on his experience in the MULTICS project. B was replaced by C, and Unix, rewritten in C, developed into a large, complex family of inter-related operating systems which have been influential in every modern operating system (see History). The Unix-like family is a diverse group of operating systems, with several major sub-categories including System V, BSD, and Linux. The name "UNIX" is a trademark of The Open Group which licenses it for use with any operating system that has been shown to conform to their definitions. "UNIX-like" is commonly used to refer to the large set of operating systems which resemble the original UNIX. Unix-like systems run on a wide variety of computer architectures. They are used heavily for servers in business, as well as workstations in academic and engineering environments. Free UNIX variants, such as Linux and BSD, are popular in these areas. Four operating systems are certified by The Open Group (holder of the Unix trademark) as Unix. HP's HP-UX and IBM's AIX are both descendants of the original System V Unix and are designed to run only on their respective vendor's hardware.
    [Show full text]
  • Operating Systems, 1997., the Sixth Work
    Experience with the Development of a Microkernel-Based, Multiserver Operating System Freeman L. Rawson I11 IBM Austin Abstract and feel” of any operating system in the set while maintaining a single system image that shared as much code as possible among the During the first half the 1990s IBM developed a set . of of personalities operating system products called Worhplace OS that was bused . that offered full compatibility with all of the operating on the Mach 3.0 microkernel and Taligent’s object-oriented systems in the set and with DOSlWindows 3.1 TalOS. These products were intended to be scalable, portable + which offered the choice of a fully object-oriented and capable of concurrently running multiple operating system operating system including both object-oriented interfaces personalities while sharing as much code as possible. The and an object-oriented implementation operating system personalities were constructed out of a set of - which provided real time operation. user-level personality and personality-neutral servers and Since the technologies were modular, the project was libraries. While we made a number of important changes to structured as a set of related products so that customers could Mach 3.0, we maintained its fundamentals and the multi-server buy precisely the parts that they needed. The project as a design throughout our project. In evaluating the resulting system, whole was known as Workplace OS (WPOS) but was often a number ofproblems are apparent. There is no good way to referred to as the “microkemel-based” system because of the factor multiple existing systems into a set of functional servers central role played by the microkernel and because the without making them excessively large and complex.
    [Show full text]
  • Microkernels: Mach and L4
    Microkernels: Mach and L4 Presented by Jason Wu With content borrowed from Dan Williams (2009) and Hakim Weatherspoon (2008) Outline • Introduction to Kernels • 1st Generation Microkernels – Mach • 2nd Generation Microkernels – L4 • Conclusions Introduction to Kernels • Different Types of Kernel Designs – Monolithic kernel – Microkernel – Hybrid Kernel – Exokernel – Virtual Machines? Monolithic Kernels • All OS services operate in kernel space • Good performance • Disadvantages – Dependencies between system component – Complex & huge (millions(!) of lines of code) – Larger size makes it hard to maintain • E.g. Multics, Unix, BSD, Linux Microkernels • Minimalist approach – IPC, virtual memory, thread scheduling • Put the rest into user space – Device drivers, networking, file system, user interface • More stable with less services in kernel space • Disadvantages – Lots of system calls and context switches • E.g. Mach, L4, AmigaOS, Minix, K42 Monolithic Kernels VS Microkernels Hybrid Kernels • Combine the best of both worlds – Speed and simple design of a monolithic kernel – Modularity and stability of a microkernel • Still similar to a monolithic kernel – Disadvantages still apply here • E.g. Windows NT, NetWare, BeOS Exokernels • Follows end-to-end principle – Extremely minimal – Fewest hardware abstractions as possible – Just allocates physical resources to apps • Disadvantages – More work for application developers • E.g. Nemesis, ExOS • Next Thursday! The Microkernel Debate • How big should it be? • Big debate during the 1980’s Summary:
    [Show full text]
  • A Secure Computing Platform for Building Automation Using Microkernel-Based Operating Systems Xiaolong Wang University of South Florida, [email protected]
    University of South Florida Scholar Commons Graduate Theses and Dissertations Graduate School November 2018 A Secure Computing Platform for Building Automation Using Microkernel-based Operating Systems Xiaolong Wang University of South Florida, [email protected] Follow this and additional works at: https://scholarcommons.usf.edu/etd Part of the Computer Sciences Commons Scholar Commons Citation Wang, Xiaolong, "A Secure Computing Platform for Building Automation Using Microkernel-based Operating Systems" (2018). Graduate Theses and Dissertations. https://scholarcommons.usf.edu/etd/7589 This Dissertation is brought to you for free and open access by the Graduate School at Scholar Commons. It has been accepted for inclusion in Graduate Theses and Dissertations by an authorized administrator of Scholar Commons. For more information, please contact [email protected]. A Secure Computing Platform for Building Automation Using Microkernel-based Operating Systems by Xiaolong Wang A dissertation submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy in Computer Science and Engineering Department of Computer Science and Engineering College of Engineering University of South Florida Major Professor: Xinming Ou, Ph.D. Jarred Ligatti, Ph.D. Srinivas Katkoori, Ph.D. Nasir Ghani, Ph.D. Siva Raj Rajagopalan, Ph.D. Date of Approval: October 26, 2018 Keywords: System Security, Embedded System, Internet of Things, Cyber-Physical Systems Copyright © 2018, Xiaolong Wang DEDICATION In loving memory of my father, to my beloved, Blanka, and my family. Thank you for your love and support. ACKNOWLEDGMENTS First and foremost, I would like to thank my advisor, Dr. Xinming Ou for his guidance, encouragement, and unreserved support throughout my PhD journey.
    [Show full text]