DOCSLIB.ORG

Microkernel OS Evolution

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Microkernel OS Evolution COMP9242 Advanced OS S2/2018 W01: Introduction to seL4 @GernotHeiser Copyright Notice These slides are distributed under the Creative Commons Attribution 3.0 License • You are free: – to share—to copy, distribute and transmit the work – to remix—to adapt the work • under the following conditions: – Attribution: You must attribute the work (but not in any way that suggests that the author endorses you or your use of the work) as follows: “Courtesy of Gernot Heiser, UNSW Sydney” The complete license text can be found at http://creativecommons.org/licenses/by/3.0/legalcode 2 COMP9242 S2/2018 W01 © 2017 Gernot Heiser. Distributed under CC Attribution License Reducing Trusted Computing Base: Microkernels • Idea of microkernel: IPC performance – Flexible, minimal platform is critical! – Mechanisms, not policies – Actual OS functionality provided by user-mode servers – Servers invoked by kernel-provided message-passing mechanism (IPC) – Goes back to Nucleus [Brinch Hansen’70] Application Syscall VFS User Unix File Mode Server Device Server IPC, file system Application Driver Kernel Scheduler, virtual memory Mode Device drivers, dispatcher IPC, virtual memory IPC Hardware Hardware 3 COMP9242 S2/2018 W01 © 2017 Gernot Heiser. Distributed under CC Attribution License Monolithic vs Microkernel OS Evolution Monolithic OS Microkernel OS • New features add code kernel • Features add usermode code • New policies add code kernel • Policies replace usermode code • Kernel complexity grows • Kernel complexity is stable • Adaptable • Dependable Application • Highly optimised Syscall VFS User Unix File Mode Server Device Server IPC, file system Application Driver Kernel Scheduler, virtual memory Mode Device drivers, dispatcher IPC, virtual memory IPC Hardware Hardware 4 COMP9242 S2/2018 W01 © 2017 Gernot Heiser. Distributed under CC Attribution License 1993 “Microkernel”: IPC Performance [µs] 400 Mach i486 @ 50 MHz 300 Culprit: Cache 200 footprint 115 µs [Liedtke’95] L4 100 5 µs raw copy 0 0 2000 4000 6000 Message Length [B] 5 COMP9242 S2/2018 W01 © 2017 Gernot Heiser. Distributed under CC Attribution License Microkernel Principle: Minimality A concept is tolerated inside the microkernel only if moving it outside the kernel, i.e. permitting competing implementations, would prevent the implementation of the system’s required functionality. [SOSP’95] Limited by arch- • Advantages of resulting small kernel: specific micro- – Easy to implement, port? optimisations – Easier to optimise – Hopefully enables a minimal trusted computing base – Easier debug, maybe even prove correct? Small attack • Challenges: surface, fewer – API design: generality despite small code base failure modes – Kernel design and implementation for high performance 6 COMP9242 S2/2018 W01 © 2017 Gernot Heiser. Distributed under CC Attribution License Microkernel Evolution First generation Second generation Third generation • Eg Mach [’87] • L4 [’95] • seL4 [’09] (QNX, Chorus) (PikeOS, Integrity) Memory Objects Low-level FS, Memory- Swapping mangmt Devices library Kernel memory Kernel memory Scheduling Scheduling Scheduling IPC, MMU abstr. IPC, MMU abstr. IPC, MMU abstr. • 180 syscalls • ~7 syscalls • ~3 syscalls • 100 kSLOC • ~10 kSLOC • 9 kSLOC • 100 µs IPC • ~ 1 µs IPC • 0.1 µs IPC • capabilities • design for isolation 7 COMP9242 S2/2018 W01 © 2017 Gernot Heiser. Distributed under CC Attribution License L4: A Family of High-Performance Microkernels First L4 iOS security kernel with co-processor capabilities API Inheritance L4-embed. seL4 Code Inheritance OKL4 Microvisor L4/MIPS OKL4 µKernel L4/Alpha Codezero Qualcomm modem chips L3 → L4 “X” Hazelnut Pistachio Fiasco Fiasco.OC UNSW/NICTA GMD/IBM/Karlsruhe NOVA Dresden OK Labs P4 → PikeOS Commercial Clone 93 94 95 96 97 98 99 00 01 02 03 04 05 06 07 08 09 10 11 12 13 8 COMP9242 S2/2018 W01 © 2017 Gernot Heiser. Distributed under CC Attribution License Issues of 2G Microkernels • L4 solved performance issue [Härtig et al, SOSP’97] • Left a number of security issues unsolved • Problem: ad-hoc approach to protection and resource management – Global thread name space ⇒ covert channels [Shapiro’03] – Threads as IPC targets ⇒ insufficient encapsulation – Single kernel memory pool ⇒ DoS attacks – Insufficient delegation of authority ⇒ limited flexibility, performance issues – Unprincipled management of time • Addressed by seL4 – Designed to support safety- and security-critical systems – Principled time management (MCS branch) 9 COMP9242 S2/2018 W01 © 2017 Gernot Heiser. Distributed under CC Attribution License The seL4 Microkernel 10 COMP9242 S2/2018 W01 © 2017 Gernot Heiser. Distributed under CC Attribution License Principles • Single protection mechanism: capabilities – Now also for time [Lyons et al, EuroSys’18] • All resource-management policy at user level – Painful to use – Need to provide standard memory-management library o Results in L4-like programming model • Suitable for formal verification (proof of implementation correctness) – Attempted since ‘70s – Finally achieved by L4.verified project at NICTA [Klein et al, SOSP’09] 11 COMP9242 S2/2018 W01 © 2017 Gernot Heiser. Distributed under CC Attribution License Concepts • Capabilities (Caps) – mediate access • Kernel objects: – Threads (thread-control blocks: TCBs) – Address spaces (page table objects: PDs, PTs) – Endpoints (IPC) – Notifications – Capability spaces (CNodes) – Frames – Interrupt objects (architecture specific) – Untyped memory • System calls – Send, Wait (and variants) – Yield 12 COMP9242 S2/2018 W01 © 2017 Gernot Heiser. Distributed under CC Attribution License What are (Object) Capabilities? Cap = Access Token: Eg. thread, Prima-facie evidence file, … of privilege Object Obj reference Access rights Cap typically in kernel to protect from forgery Eg. read, write, send, execute… Ø user references cap through handle • OO API: err = method( cap, args ); Linux • Used in some earlier microkernels: “capabilities” – KeyKOS [‘85], Mach [‘87], EROS [‘99] are different 13 COMP9242 S2/2018 W01 © 2017 Gernot Heiser. Distributed under CC Attribution License seL4 Capabilities • Stored in cap space (CSpace) – Kernel object made up of CNodes – each an array of cap “slots” • Inaccessible to userland – But referred to by pointers into CSpace (slot addresses) – These CSpace addresses are called CPTRs • Caps convey specific privilege (access rights) – Read, Write, Execute, Grant (cap transfer) • Main operations on caps: – Invoke: perform operation on object referred to by cap o Possible operations depend on object type – Copy/Mint/Grant: create copy of cap with same/lesser privilege – Move/Mutate: transfer to different address with same/lesser privilege – Delete: invalidate slot (cleans up object if this is the only cap to it) – Revoke: delete any derived (eg. copied or minted) caps 14 COMP9242 S2/2018 W01 © 2017 Gernot Heiser. Distributed under CC Attribution License Inter-Process Communication (IPC) • Fundamental microkernel operation – Kernel provides no services, only mechanisms – OS services provided by (protected) user-level server processes – invoked by IPC Client Server seL4 IPC • seL4 IPC uses a handshake through endpoints: – Transfer points without storage capacity send receive – Message must be transferred instantly o Single-copy user ➞ user by kernel 15 COMP9242 S2/2018 W01 © 2017 Gernot Heiser. Distributed under CC Attribution License IPC: Endpoints Thread1 Thread2 Running Blocked Blocked Running ….. Recv (ep1_cap, …) Send (ep1_cap, …) ….... Recv (ep2_cap, …) ….... ….... Send (ep2_cap, …) • Threads must rendez-vous for message transfer – One side blocks until the other is ready – Implicit synchronisation • Message copied from sender’s to receiver’s message registers – Message is combination of caps and data words o Presently max 121 words (484B, incl message “tag”) o Should never use anywhere near that much! 16 COMP9242 S2/2018 W01 © 2017 Gernot Heiser. Distributed under CC Attribution License Endpoints are Message Queues Server Client1 Client2 Kernel TCB1 TCB2 EP First invocation • EP has no sense of direction queues caller • May queue senders or receivers Further callers of same direction – never both at the same time! queue behind • Communication needs 2 EPs! 17 COMP9242 S2/2018 W01 © 2017 Gernot Heiser. Distributed under CC Attribution License Client-Server Communication • Asymmetric relationship: – Server widely accessible, clients not Server Client1 Client2 – How can server reply back to client (distinguish between them)? • Client can pass (session) reply cap in first request – server needs to maintain session state – forces stateful server design • seL4 solution: Kernel provides single-use reply cap – only for Call operation (Send+Recv) – allows server to reply to client – cannot be copied/minted/re-used but can be moved – one-shot (automatically destroyed after first use) 18 COMP9242 S2/2018 W01 © 2017 Gernot Heiser. Distributed under CC Attribution License Call RPC Semantics Client Client Server Call(ep,…) Kernel Server Recv(ep,&rep) mint rep deliver to server process process Send(rep,…) deliver to client destroy rep process 19 COMP9242 S2/2018 W01 © 2017 Gernot Heiser. Distributed under CC Attribution License Stateful Servers: Identifying Clients Stateful server serving multiple clients • Must respond to correct client Server – Ensured by reply cap Client1 Client1 • Must associate request Msg state with correct state Client2 Client2 state • Could use separate EP per client – endpoints are lightweight (16 B) – but requires mechanism to wait on a set of
Load more

Recommended publications
  • The Flask Security Architecture: System Support for Diverse Security Policies
    The Flask Security Architecture: System Support for Diverse Security Policies Ray Spencer Secure Computing Corporation Stephen Smalley, Peter Loscocco National Security Agency Mike Hibler, David Andersen, Jay Lepreau University of Utah http://www.cs.utah.edu/flux/flask/ Abstract and even many types of policies [1, 43, 48]. To be gen- erally acceptable, any computer security solution must Operating systems must be flexible in their support be flexible enough to support this wide range of security for security policies, providing sufficient mechanisms for policies. Even in the distributed environments of today, supporting the wide variety of real-world security poli- this policy flexibility must be supported by the security cies. Such flexibility requires controlling the propaga- mechanisms of the operating system [32]. tion of access rights, enforcing fine-grained access rights and supporting the revocation of previously granted ac- Supporting policy flexibility in the operating system is cess rights. Previous systems are lacking in at least one a hard problem that goes beyond just supporting multi- of these areas. In this paper we present an operating ple policies. The system must be capable of supporting system security architecture that solves these problems. fine-grained access controls on low-level objects used to Control over propagation is provided by ensuring that perform higher-level functions controlled by the secu- the security policy is consulted for every security deci- rity policy. Additionally, the system must ensure that sion. This control is achieved without significant perfor- the propagation of access rights is in accordance with mance degradation through the use of a security decision the security policy.
    [Show full text]
  • Microkernels Meet Recursive Virtual Machines
    Microkernels Meet Recursive Virtual Machines Bryan Ford Mike Hibler Jay Lepreau Patrick Tullmann Godmar Back Stephen Clawson Department of Computer Science, University of Utah Salt Lake City, UT 84112 [email protected] http://www.cs.utah.edu/projects/flux/ Abstract ªverticallyº by implementing OS functionalityin stackable virtual machine monitors, each of which exports a virtual Thispaper describes a novel approach to providingmod- machine interface compatible with the machine interface ular and extensible operating system functionality and en- on which it runs. Traditionally,virtual machines have been capsulated environments based on a synthesis of micro- implemented on and export existing hardware architectures kernel and virtual machine concepts. We have developed so they can support ªnaiveº operating systems (see Fig- a software-based virtualizable architecture called Fluke ure 1). For example, the most well-known virtual machine that allows recursive virtual machines (virtual machines system, VM/370 [28, 29], provides virtual memory and se- running on other virtual machines) to be implemented ef- curity between multiple concurrent virtual machines, all ®ciently by a microkernel running on generic hardware. exporting the IBM S/370 hardware architecture. Further- A complete virtual machine interface is provided at each more, special virtualizable hardware architectures [22, 35] level; ef®ciency derives from needing to implement only have been proposed, whose design goal is to allow virtual new functionality at each level. This infrastructure allows machines to be stacked much more ef®ciently. common OS functionality, such as process management, demand paging, fault tolerance, and debugging support, to This paper presents a new approach to OS extensibil- be provided by cleanly modularized, independent, stack- ity which combines both microkernel and virtual machine able virtual machine monitors, implemented as user pro- concepts in one system.
    [Show full text]
  • All Computer Applications Need to Store and Retrieve Information
    MyFS: An Enhanced File System for MINIX A Dissertation Submitted in partial fulfillment of the requirement for the award of the degree of MASTER OF ENGINEERING ( COMPUTER TECHNOLOGY & APPLICATIONS ) By ASHISH BHAWSAR College Roll No. 05/CTA/03 Delhi University Roll No. 3005 Under the guidance of Prof. Asok De Department Of Computer Engineering Delhi College Of Engineering, New Delhi-110042 (University of Delhi) July-2005 1 CERTIFICATE This is to certify that the dissertation entitled “MyFS: An Enhanced File System for MINIX” submitted by Ashish Bhawsar in the partial fulfillment of the requirement for the award of degree of Master of Engineering in Computer Technology and Application, Delhi College of Engineering is an account of his work carried out under my guidance and supervision. Professor D. Roy Choudhury Professor Asok De Head of Department Head of Department Department of Computer Engineering Department of Information Technology Delhi College of Engineering Delhi College of Engineering Delhi Delhi 2 ACKNOWLEDGEMENT It is a great pleasure to have the opportunity to extent my heartiest felt gratitude to everybody who helped me throughout the course of this project. I would like to express my heartiest felt regards to Dr. Asok De, Head of the Department, Department of Information Technology for the constant motivation and support during the duration of this project. It is my privilege and owner to have worked under the supervision. His invaluable guidance and helpful discussions in every stage of this thesis really helped me in materializing this project. It is indeed difficult to put his contribution in few words. I would also like to take this opportunity to present my most sincere regards to Dr.
    [Show full text]
  • Composing Abstractions Using the Null-Kernel
    Composing Abstractions using the null-Kernel James Litton Deepak Garg University of Maryland Max Planck Institute for Software Systems Max Planck Institute for Software Systems [email protected] [email protected] Peter Druschel Bobby Bhattacharjee Max Planck Institute for Software Systems University of Maryland [email protected] [email protected] CCS CONCEPTS hardware, such as GPUs, crypto/AI accelerators, smart NICs/- • Software and its engineering → Operating systems; storage devices, NVRAM etc., and to efficiently support new Layered systems; • Security and privacy → Access control. application requirements for functionality such as transac- tional memory, fast snapshots, fine-grained isolation, etc., KEYWORDS that demand new OS abstractions that can exploit existing hardware in novel and more efficient ways. Operating Systems, Capability Systems At its core, the null-Kernel derives its novelty from being ACM Reference Format: able to support and compose across components, called Ab- James Litton, Deepak Garg, Peter Druschel, and Bobby Bhattachar- stract Machines (AMs) that provide programming interfaces jee. 2019. Composing Abstractions using the null-Kernel. In Work- at different levels of abstraction. The null-Kernel uses an ex- shop on Hot Topics in Operating Systems (HotOS ’19), May 13–15, 2019, Bertinoro, Italy. ACM, New York, NY, USA, 6 pages. https: tensible capability mechanism to control resource allocation //doi.org/10.1145/3317550.3321450 and use at runtime. The ability of the null-Kernel to support interfaces at different levels of abstraction accrues several 1 INTRODUCTION benefits: New hardware can be rapidly deployed using rela- tively low-level interfaces; high-level interfaces can easily Abstractions imply choice, one that OS designers must con- be built using low-level ones; and applications can benefit front when designing a programming interface to expose.
    [Show full text]
  • The Flask Security Architecture: System Support for Diverse Security Policies
    The Flask Security Architecture: System Support for Diverse Security Policies Ray Spencer Secure Computing Corporation Stephen Smalley, Peter Loscocco National Security Agency Mike Hibler, David Andersen, Jay Lepreau University of Utah http://www.cs.utah.edu/flux/flask/ Abstract and even many types of policies [1, 43, 48]. To be gen­ erally acceptable, any computer security solution must Operating systems must be flexible in their support be flexible enough to support this wide range of security for security policies, providing sufficient mechanisms for policies. Even in the distributed environments of today, supporting the wide variety of real-world security poli­ this policy flexibility must be supported by the security cies. Such flexibility requires controlling the propaga­ mechanisms of the operating system [32]. tion of access rights, enforcing fine-grained access rights and supporting the revocation of previously granted ac­ Supporting policy flexibility in the operating system is cess rights. Previous systems are lacking in at least one a hard problem that goes beyond just supporting multi­ of these areas. In this paper we present an operating ple policies. The system must be capable of supporting system security architecture that solves these problems. fine-grained access controls on low-level objects used to Control over propagation is provided by ensuring that perform higher-level functions controlled by the secu­ the security policy is consulted for every security deci­ rity policy. Additionally, the system must ensure that sion. This control is achieved without significant perfor­ the propagation of access rights is in accordance with mance degradation through the use of a security decision the security policy.
    [Show full text]
  • Harvard Cs252r Fa'13
    Type Enforcement & Pluggable MAC Harvard CS252r Fa’13 Tuesday, October 22, 13 1 Practical Domain and Type Enforcement for UNIX • Badger, et al. 1995 • Trusted Information Systems Tuesday, October 22, 13 2 Domain and Type Enforcement • Every Subject is associated with a Domain • Every Object is associated with a Type Tuesday, October 22, 13 3 Boebart and Kain ’85 [7], page 23 introduces this a given user could have multiple subjects operating in diferent domains dynamically, it seems a subject and an object are associated with just one, statically: could be anything Domain and Type Enforcement • Domain Definition Table • Domain’s Access Rights to each Type • read, write, etc. • Domain Interaction Table • Domain’s Access Rights to other Domains • signal, create, destroy, etc. Tuesday, October 22, 13 4 Domain and Type Enforcement • Strict Superset of Lattice-Expressible Security Policies Tuesday, October 22, 13 5 Domain and Type Enforcement Manager budget designs Accountant Engineer salary Tuesday, October 22, 13 6 DTEL Domain and Type Enforcement Language • Encompasses Existing Security Policies • Hierarchical Types • Simple, Declarative Language Tuesday, October 22, 13 7 DTEL Operating System Entities File Hierarchy Process Hierarchy Figure 1: Mismatch Between Policy Concepts and System Structures trol configurations. A DTE specification includes ration: the type statement, the domain statement, the security attribute associations such as typelfile tnitial-domain statement, and the assign statement.’ associations as well as other access control in- The purpose of this section is not to fully document Tuesday,formation. October 22, 13 The language provides a high-level DTEL, but to demonstrate through a small example 8 view of information traditionally enurnerated in that a meaningful DTEL policy can be expressed com- type enforcement tables and includes facilities pletely in a form simple and concise enough to be ad- for superimposing security attribute bindings and ministered at reasonable cost.
    [Show full text]
  • Capability Myths Demolished
    Capability Myths Demolished Mark S. Miller Ka-Ping Yee Jonathan Shapiro Combex, Inc. University of California, Berkeley Johns Hopkins University [email protected] [email protected] [email protected] ABSTRACT The second and third myths state false limitations on We address three common misconceptions about what capability systems can do, and have been capability-based systems: the Equivalence Myth (access propagated by a series of research publications over the control list systems and capability systems are formally past 20 years (including [2, 3, 7, 24]). They have been equivalent), the Confinement Myth (capability systems cited as reasons to avoid adopting capability models cannot enforce confinement), and the Irrevocability and have even motivated some researchers to augment Myth (capability-based access cannot be revoked). The capability systems with extra access checks [7, 13] in Equivalence Myth obscures the benefits of capabilities attempts to fix problems that do not exist. The myths as compared to access control lists, while the Confine- about what capability systems cannot do continue to ment Myth and the Irrevocability Myth lead people to spread, despite formal results [22] and practical see problems with capabilities that do not actually exist. systems [1, 9, 18, 21] demonstrating that they can do these supposedly impossible things. The prevalence of these myths is due to differing inter- pretations of the capability security model. To clear up We believe these severe misunderstandings are rooted the confusion, we examine three different models that in the fact that the term capability has come to be have been used to describe capabilities, and define a set portrayed in terms of several very different security of seven security properties that capture the distinctions models.
    [Show full text]
  • What Have We Learnt in 20 Years of L4 Microkernels?
    Lecture 6 From L3 to seL4: What Have We Learnt in 20 Years of L4 Microkernels? Kevin Elphinstone and Gernot Heiser Operating Systems Practical 12 November, 2014 OSP Lecture 6, L4 Microkernels 1/42 Contents Introduction and design principles Brief history of microkernels L4: Basic abstractions L4: Design and implementation choices Keywords Questions OSP Lecture 6, L4 Microkernels 2/42 Outline Introduction and design principles Brief history of microkernels L4: Basic abstractions L4: Design and implementation choices Keywords Questions OSP Lecture 6, L4 Microkernels 3/42 Context and terminology I Operating system I Kernel I Monolithic kernel I Microkernel OSP Lecture 6, L4 Microkernels 4/42 Operating system I abbrv. OS I Software (collection) to interface hardware with user I Components: I Kernel: Linux, FreeBSD, Windows NT, XNU, L4, ::: I Services/daemons: sysvinit, CUPS print server, udev, ::: I Utilities: ls, Windows Commander, top I Other applications OSP Lecture 6, L4 Microkernels 5/42 Kernel I Components directly interfacing with hardware I Examples? I \Core" of OS I No general definition of \core" OSP Lecture 6, L4 Microkernels 6/42 Monolithic vs. Micro-kernel Application Syscall User VFS "ode Uni File Server Device Server IPC, file system Application Driver Scheduler, virtual memory !ernel "ode Device drivers, dispatcher IPC, virtual memory IPC Hardware Hardware Source: http://www.cse.unsw.edu.au/ OSP Lecture 6, L4 Microkernels 7/42 Monolithic vs. Micro-kernel Monolithic kernel Microkernel I IPC, scheduling, I IPC, scheduling, memory management memory management I File systems I API closer to the I Drivers hardware I Higher-level API OSP Lecture 6, L4 Microkernels 8/42 Microkernel principles: minimality I If it's not critical, leave it out of the kernel I Pros: I Small code base I Easy to debug I Trusted Computing Base, feasible for formal verification I Cons: I Harder to find the \right" API design I Harder to optimize for high-performance OSP Lecture 6, L4 Microkernels 9/42 Microkernel principles: user-level services I Drivers, file systems, etc.
    [Show full text]
  • Formal Verification of a Component Platform Matthew Fernandez
    Formal Verification of a Component Platform Matthew Fernandez A thesis in fulfilment of the requirements for the degree of Doctor of Philosophy School of Computer Science and Engineering Faculty of Engineering March, 2016 Abstract The function of software used to be calculation; mechanising what was previously done by hand. Now it runs our communication networks, mass transportation and medical support. Yet we still build large software systems as if they were small, easily compre- hensible tools. The right to manage our safety and security should not be handed over lightly. When a program has the ability to compromise our security or injure us, we should demand evidence of its correctness. Formal software verification has demonstrated how to re- liably and repeatedly build safe and secure high-assurance systems, to a standard not achievable using other techniques. Yet it remains underused due to perceptions that it is expensive and time intensive to apply. In this thesis we demonstrate how to scale formal software verification beyond its current limits using component-based software engineering. By leveraging the strong isolation boundaries made possible by the CAmkES component platform operating on the seL4 microkernel, we decompose system verification along lines that correspond to the sys- tem architecture. The parallels between proof obligations and system architecture aid the designer’s intuition and allow easing verification challenges through architectural refactoring. To uphold the engineering abstraction that a component platform provides, we demonstrate a fully automated process for verifying functional correctness of platform- generated code and the correct initialisation of a CAmkES system. The system designer no longer needs to trust that the platform’s mechanisms do what they claim, as is the case with other existing component platforms.
    [Show full text]
  • Dynamic Data Models: an Application of MOP-Based Persistence in Common Lisp 1 Introduction
    Dynamic data models: an application of MOP-based persistence in Common Lisp Pierre Thierry Simon E.B. Thierry Ph.D. candidate Independent developer LSIIT, UMR CNRS-ULP 7005 Thierry Technologies Pôle API, BP 10413 Illkirch Cedex France [email protected] [email protected] Abstract The data model of an application, the nature and format of data stored across executions, is typically a very rigid part of its early specication, even when prototyping, and changing it after code that relies on it was written can prove quite expensive and error-prone. Code and data in a running Lisp image can be dynamically modied. A MOP-based persistence library can bring this dynamicity to the data model. This enables to extend the easy prototyping way of development to the storage of data and helps avoiding interruptions of service. This article presents the conditions to do this portably and transparently. 1 Introduction Many applications provide a continuous service but cannot guarantee that they will run continuously. These applications must serialize and write part of their state to be able to restore it when they are executed again. Some of these applications are designed to run continuously but one cannot avoid to shut them down occasionally, e.g. because of hardware failure, maintenance or software updates, like network servers. Others are only needed part of the time and are designed to be executed only then, like accounting software. Occasionally an application is designed to be executed in a short time and only handle user input and hardcoded data but, as the use conditions evolve, it becomes necessary to stop its execution and be able to resume it later.
    [Show full text]
  • Statistics for Brynosaurus.Com (2004)
    Statistics for brynosaurus.com (2004) Statistics for: brynosaurus.com Last Update: 26 Sep 2006 − 03:56 Reported period: Year 2004 When: Monthly history Days of month Days of week Hours Who: Countries Full list Hosts Full list Last visit Unresolved IP Address Robots/Spiders visitors Full list Last visit Navigation: Visits duration File type Viewed Full list Entry Exit Operating Systems Versions Unknown Browsers Versions Unknown Referers: Origin Refering search engines Refering sites Search Search Keyphrases Search Keywords Others: Miscellaneous HTTP Status codes Pages not found Summary Reported period Year 2004 First visit 01 Jan 2004 − 00:04 Last visit 31 Dec 2004 − 23:57 Unique visitors Number of visits Pages Hits Bandwidth <= 40525 47088 85260 726872 20.63 GB Viewed traffic * Exact value not available in (1.16 visits/visitor) (1.81 pages/visit) (15.43 hits/visit) (459.33 KB/visit) 'Year' view Not viewed traffic * 56661 78092 1.91 GB * Not viewed traffic includes traffic generated by robots, worms, or replies with special HTTP status codes. Monthly history Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec 2004 2004 2004 2004 2004 2004 2004 2004 2004 2004 2004 2004 Month Unique visitors Number of visits Pages Hits Bandwidth Jan 2004 3254 3542 5336 34926 1.06 GB Feb 2004 3721 4080 7997 68946 1.83 GB Mar 2004 5103 5842 9661 116080 2.89 GB Apr 2004 3761 4306 7697 69176 1.86 GB May 2004 3796 4415 7466 71072 1.96 GB Jun 2004 2664 3143 6283 49758 1.40 GB Jul 2004 2470 2908 5066 40287 1.18 GB Aug 2004 2279 2836 5394 40026 1.14 GB Sep 2004 2955
    [Show full text]
  • Lxds: Towards Isolation of Kernel Subsystems
    LXDs: Towards Isolation of Kernel Subsystems Vikram Narayanan Abhiram Balasubramanian∗ Charlie Jacobsen∗ University of California, Irvine University of Utah University of Utah Sarah Spall† Scott Bauer‡ Michael Quigley§ Aftab Hussain University of Utah University of Utah University of Utah University of California, Irvine Abdullah Younis¶ Junjie Shen University of California, Irvine University of California, Irvine Moinak Bhattacharyya Anton Burtsev University of California, Irvine University of California, Irvine Abstract and inherent complexity (typical kernel code adheres to mul- Modern operating systems are monolithic. Today, however, tiple allocation, synchronization, access control, and object lack of isolation is one of the main factors undermining se- lifetime conventions) bugs and vulnerabilities are routinely curity of the kernel. Inherent complexity of the kernel code introduced into the kernel code. In 2018, the Common Vul- and rapid development pace combined with the use of unsafe, nerabilities and Exposures database lists 176 Linux kernel low-level programming language results in a steady stream vulnerabilities that allow for privilege escalation, denial-of- of errors. Even after decades of efforts to make commodity service, and other exploits [20]. This number is the lowest kernels more secure, i.e., development of numerous static and across several years [19]. dynamic approaches aimed to prevent exploitation of most Even though a number of static and dynamic mechanisms common errors, several hundreds of serious kernel vulnerabil- have been invented to protect execution of the low-level kernel ities are reported every year. Unfortunately, in a monolithic code, e.g., modern kernels deploy stack guards [18], address kernel a single exploitable vulnerability potentially provides space layout randomization (ASLR) [45], and data execution an attacker with access to the entire kernel.
    [Show full text]