The Evolution of Secure Operating Systems

Trent Jaeger

Systems and Internet Infrastructure Security (SIIS) Lab Computer Science and Engineering Department Pennsylvania State University

Systems and Internet Infrastructure Security Laboratory (SIIS) Page 1 Operating Systems

• Make computer systems easier to use • Improve productivity and collaboration

Systems and Internet Infrastructure Security Laboratory (SIIS) Page Operating Systems

• Users make mistakes that may affect others • Users may have malicious intentions

Systems and Internet Infrastructure Security Laboratory (SIIS) Page Need for Security

• The need for operating systems to enforce security requirements was recognized from the advent of multi-user operating systems

Systems and Internet Infrastructure Security Laboratory (SIIS) Page EvolutionMultiprocessor of Secure Systems OS

•• MajorIn this talk,Effort: I will Multics review the evolution of the design of secure ‣operatingMultiprocessing systems withsystem respect -- developed to these many questions OS concepts • Phase• Including 1: The (Early)security Multics Experience ‣ Begun in 1965 ‣ Archaen ‒ “the formation of continents and life started to form” • Research continued into the mid-70s • Phase 2: The Security Kernel Experience ‣ Used until 2000 ‣‣ ProterozoicInitial partners: ‒ “from MIT, the Bell appearance Labs, GE of (replaced oxygen in by Earth's Honeywell) atmosphere to just before the proliferation of complex life” ‣ Other innovations: hierarchical ﬁlesystems, dynamic linking • Phase 3: Recent and Future Directions ‣ Phanerozoic ‒ “starts with the rapid emergence of a number of • Multicslife forms” remains a basis for a secure operating systems • designNot only vertical but horizontal transfers

SystemsCSE543 and- Introduction Internet Infrastructure to Computer Security and Network Laboratory Security (SIIS) Page X Need for Security

• The need for operating systems to enforce security requirements was recognized from the advent of multi-user operating systems ‣ F. J. Corbató and V. A. Vyssotsky. Introduction and overview of the Multics System. In Proceedings of the 1965 AFIPS Fall Joint Computer Conference, 1965. ‣ “Of considerable concern is the issue of privacy. Experience has shown that privacy and security are sensitive issues in a multiuser system where terminals are anonymously remote.”

Systems and Internet Infrastructure Security Laboratory (SIIS) Page Questions

• So, were we done? No, still several difﬁcult questions to address, including • (1) What does security mean? ‣ Policy: What degree of control and access should be allowed to enable a system to process user data securely? • (2) How do we enforce security effectively? ‣ Mechanism: What should be the requirements of a security mechanism to enforce security policies correctly? • (3) How do we validate correctness in enforcement? ‣ Validation: What methods are necessary to validate the correctness requirements for enforcing a security policy?

Systems and Internet Infrastructure Security Laboratory (SIIS) Page Multics Project (to 1977)

• Importantly, the Multics project explored all three big questions

‣ And made important contributions to each

Systems and Internet Infrastructure Security Laboratory (SIIS) Page Multics Project (to 1977)

• Importantly, the Multics project explored all three big questions

‣ And made important contributions to each • What does security (policy) mean?

‣ Security has to protect secrecy and integrity even when adversaries control processes (e.g., Mandatory Access Control)

Systems and Internet Infrastructure Security Laboratory (SIIS) Page Multics Project (to 1977)

• Importantly, the Multics project explored all three big questions

‣ And made important contributions to each • What does security (policy) mean?

‣ Security has to protect secrecy and integrity even when adversaries control processes (e.g., Mandatory Access Control) • What does enforcement mean? ‣ Enforcement mechanisms must satisfy the reference monitor concept

Systems and Internet Infrastructure Security Laboratory (SIIS) Page Multics Project (to 1977)

• Importantly, the Multics project explored all three big questions

‣ And made important contributions to each • What does security (policy) mean?

‣ Small code base; design for security; formal veriﬁcation

Systems and Internet Infrastructure Security Laboratory (SIIS) Page Mandatory Access Control

• Multics introduced mandatory access control (MAC) to enforce security

‣ Mandatory ‒ System-deﬁned administration of policies

‣ Access control ‒ Information ﬂow or MLS (e.g., Bell-La Padula, Biba) • User programs are not authorized to

‣ Read/Write to data to unauthorized ﬁles or processes

‣ Or change the access control policy • Prevents Trojan horse or compromised programs from violating expected data security

Systems and Internet Infrastructure Security Laboratory (SIIS) Page Multics Access Control

• Each resource is associated with an

‣ Access Control List

‣ Multilevel Security Level (secrecy)

• Bell-La Padula

‣ Access Brackets (integrity)

• More later • Last two are forms of mandatory access control

Systems and Internet Infrastructure Security Laboratory (SIIS) Page Enforcement in Multics

• How to apply policy to ensure correct enforcement?

Process 1 Process 2 Process n

Program Program Program

Data Data ... Data

Operating System Security

Scheduling

Resource Mechanisms Memory Disk Network Display ...

Memory Disk Network Display Device Device Device Device ...

Systems and Internet Infrastructure Security Laboratory (SIIS) Page Enforcement in Multics

• Found that enforcement itself must be systematic and secured ‣ Which OS operations should be protected? ‣ How do authorization checks get processed correctly?

‣ How do we know they were processed correctly? • Clearly, an informal approach to the enforcement of policies is insufﬁcient

Systems and Internet Infrastructure Security Laboratory (SIIS) Page Reference Monitor

• The Anderson report (USAF 1972) proposed the reference monitor concept to provide ‣ Explicit control must be established over each programs access to any system resource which is shared with any other user or system program. • Reference Monitor Concept requirements: ‣ The reference validation mechanism must be tamperproof

‣ The reference validation mechanism must always be invoked (complete mediation over security-sensitive operations) ‣ The reference validation mechanism must be small enough to be subject to analysis and tests, the completeness of which can be assured (validation)

Systems and Internet Infrastructure Security Laboratory (SIIS) Page EnforcementProtection Rings in Multics

•• SuccessivelyFound that enforcement less-privileged itself must“domains be systematic” and secured • Modern‣ Which OSCPUs operations support should 4 ringsbe protected? ‣ Use 2 mainly: Kernel and user ‣ How do authorization checks get processed correctly? • Intel x86 rings ‣ How do we know they were processed correctly? ‣ Ring 0 has kernel • Clearly, an informal approach to the enforcement of policies is‣ insufﬁcientRing 3 has application code

• Example: Multics (64 rings in theory, 8 in practice)

SystemsCSE543 and- Introduction Internet Infrastructure to Computer Security and Network Laboratory Security (SIIS) Page X ProtectionEnforcement Ring in MulticsRules

• • ProgramFound that cannot enforcement call code itself of must be systematic and secured higher privilege directly ‣ Which OS operations should be protected? ‣ Gate is a special memory Ring 3 ‣ addressHow do whereauthorization lower-privilege checks get processed correctly? ‣ codeHow docan we call know higher they were processed correctly? No • Enables OS to control where gate • Clearly,applications an informal call it approach(system calls) to the enforcementGate of policies is insufﬁcient Ring 0

SystemsCSE543 and- Introduction Internet Infrastructure to Computer Securityand Network Laboratory Security (SIIS) Page X EnforcementWhat Are Protection in Multics Rings? • • Coarse-grained,Found that enforcement Hardware itself mustProtection be systematic Mechanism and secured • Boundary between Levels of Authority ‣ Which OS operations should be protected? ‣ Most privileged -- ring 0 ‣ How do authorization checks get processed correctly? ‣ Monotonically less privileged above ‣ How do we know they were processed correctly? • Fundamental Purpose • ‣Clearly,Protect an systeminformal integrity approach to the enforcement of policies is insufﬁcient• Protect kernel from services • Protect services from apps • So on...

SystemsCSE543 and - Introduction Internet Infrastructure to Computer Security and Network Laboratory Security (SIIS) PagePage X Access Brackets

• Multics policy that governs access control based on the ring in which code is run ‣ Subject ‒ process’s ring number ‣ Object ‒ resource’s ring number

‣ Operations ‒ usual read, write and execute • By default, processes cannot ‣ Modify resources in lower (more privileged) rings

• What access control model is that? ‣ A bit too strong

• Weakened to a contiguous sequence of rings that could modify (or execute) each object

Systems and Internet Infrastructure Security Laboratory (SIIS) Page Reference Monitor in Multics

• Tamperprooﬁng

‣ Protection rings

‣ Kernel in ring 0

‣ Gates protecting kernel entry and exit • Complete mediation

‣ Resources modeled as “segments”

‣ Control all segment operations (ACLs, MLS, ring brackets) • Validation

‣ Come back to this

Systems and Internet Infrastructure Security Laboratory (SIIS) Page Karger-Schell Analysis

• Demonstrated the importance of following the reference monitor concept

‣ Flaws in Tamperprooﬁng

• Untrusted “master mode” code run in Ring 0 for performance

• No untrusted code in ring 0

‣ Flaws in Complete Mediation

• Failure to mediate some indirect memory accesses

• Implementation bug in complete mediation • However, these were both ﬂaws in implementation, not design, that would have been alleviated by following the reference monitor concept correctly

Systems and Internet Infrastructure Security Laboratory (SIIS) Page Validation in Multics

• Challenges were seen for validating Multics (circa 1977)

‣ Size of the code base ‒ 54 SLOC

• Although the Multics Final Report suggests that the kernel size can be reduced by approximately half

‣ How to do formal validation on a kernel?

• To this point techniques had not been developed • Ultimately, the Multics design formed the basis for the B2 assurance level of the Orange Book (now Common Criteria)

‣ + Security policy model clearly deﬁned and formally documented (B2)

‣ - Satisﬁes reference monitor requirements (B3)

Systems and Internet Infrastructure Security Laboratory (SIIS) Page Security Kernel Experience

• A number of projects emerged to address the challenge of validating secure operating systems ‣ Which came to be called security kernels • To address three main challenges ‣ Reduce size and complexity of operating systems and utility software ‣ Deﬁne security enforced by the OS internal controls ‣ Validate the correctness of the implemented security controls • From Ames and Gasser, IEEE Computer, July 1983

Systems and Internet Infrastructure Security Laboratory (SIIS) Page July 1983, IEEE Computer

Systems and Internet Infrastructure Security Laboratory (SIIS) Page Security Kernel Approach

• Security Kernel Design: Ames, Gasser, and Schell • Basic Principles ‣ A formally deﬁned security model

• Complete, mandatory, and validated for security requirements ‣ Faithful implementation • Transfer model to design incrementally and formally • While addressing practical considerations ‣ Extracting security relevant functionality from OS at large ‣ Formal speciﬁcation and validation methods

Systems and Internet Infrastructure Security Laboratory (SIIS) Page pand the functionality by gradually introducing more im- along with their application to Department of Defense plementation detail. This process is done without affect- security policy.8 Walker et al. describe an example of a ing the validity of the security properties already formal specification and verification.9 established. (For examples of systems that use formal specification techniques, see the article by Landwehr in this issue.) Implementation considerations Three classes of formal verification techniques have been applied to different stages of kernel development To successfully realize a kernel-based system, we must (Figure 2), and several techniques are available within take into account architectural and engineering consider- each class. The first class is used to prove that the ations that may not be encountered in the development kernel's intended behavior, as described in the formal of other systems. Although the kernel approach can be high-level interface specification, is secure with respect to applied to all types of systems, these considerations are the policy model. One common technique, securityJflow best illustrated in the context of a general-purpose analysis, is a relatively simple way to identify and analyze operating system with online, interactive users (Figure 3). information flows in a specification.7 Note that only the The kernel, as already noted, provides a relatively small security of the interface specification must be demon- and simple subset of the operating system functions. The strated, not the more difficult problem of its functional kernel primitives are the interface of this subset to the "correctness," since functional properties, most of rest of the operating system (generally referred to as the which are not security related, are not addressed by the supervisor). In turn, the supervisor primitives provide model. the general-purpose operating system functions used by In the second class of formal verification techniques, the applications. Security Kernelwe verify the correspondence Approachor correctness of mappings between any intermediate specifications in the hierarchy Kernel/supervisor trade-offs. An operating system is and the interface specifications. Finally, a third class of usually broken down into functional areas, such as pro- verification techniques, the most traditional way to cess management, file system management for segments, prove correctness, shows that the kernel implementation and I/O control. Within each area, some functions are corresponds to its specification. clearly security relevant and must be in the kernel, while Cheheyl et al. have documented a survey of current some are not. The rules of the policy model help to clear- • From model to implementationverification systems covering most of these techniques, ly identify which functions are security relevant.

Figure 2. Development and verification hierarchy. Figure 3. Structure of a kernel-based operation system.

July 1983 17 Systems and Internet Infrastructure Security Laboratory (SIIS) Page Formal Veriﬁcation

• What techniques are necessary to formally assure a kernel implementation satisfies a security model? ‣ “verification has turned out to be more difficult than we expected” • Goal: correctness ‣ Techniques not ready to prove correctness • Approaches (at this time) ‣ Compare kernel security to information flows allowed ‣ Specification and implementation correspondence

Systems and Internet Infrastructure Security Laboratory (SIIS) Page VMM Security Kernel

• Choices in bringing security kernel OS to market ‣ (1) High-assurance version of existing OS

• But, would trail the standard product development lifecycle

‣ (2) Custom, high-assurance OS

• Lack application and ecosystem support • Alternative: high-assurance virtual machine monitor (VMM) ‣ Motivation for the “VMM Security Kernel for VAX” in 1980 IEEE Symposium on Security and Privacy

• VMM security kernel layers under commercial OSes • To support multiple OSes and versions

Systems and Internet Infrastructure Security Laboratory (SIIS) Page VAX/SVS Project

• Important design choices was behind the action. Two privileges were reserved for VMs, so these VMs needed to be privileged. Te VAX/ Users SVS designers were primarily concerned with ensur- ing that mandatory security could be enforced. Because performing these two privileged operations outside the Virtual machine operating system ‣ Layered system design kernel didn’t violate that goal, the designers preferred limiting these abilities rather than creating a larger and Security perimeter more complex kernel. In addition to mandatory access control and user Secure Virtual • Aimed to simplify design, test, and assuranceprivileges, VAX/SVS implemented discretionary access server VAX control (access control lists) on objects. Te discretion- SSVR VVAX ary access control’s efectiveness was the only major Kernel interface area of disagreement between the development team and TCSEC evaluators. Te design was optimized KI ‣ Enforce information flow for secrecyaround and multiuser integrity VMs#if each user required his or Visual printers her own VM, the physical memory requirement for VPrint a commercially viable VAX/SVS system would have Virtual terminals grown beyond what was available, and the team would have had to modify the design to demand page VMs’ VTerm • Bell-La Padula and Biba memories. In the chosen design, a VM would operate Volumes at a specifc mandatory access class (level and category VOL set) with read-write access to objects at that access class Files-11 files and read access to objects at lower confdentiality access • Coarse-grained: For VMs access to storageclasses (that volumesis, lower security level and lesser category F11F set). All users who needed to access objects at that VM’s Audit trail access class would share the machine. AUD With multiuser VMs, VAX/SVS couldn’t determine Higher-level scheduler with high assurance which individual user took a spe- ‣ Paravirtualization with simple memorycifc action management for the purpose of enforcing discretionary HLS VM-virtual access control or collecting an audit trail. Te VAX/SVS space manager team argued that, given the reality of Trojan horses, the VMV security gain wasn’t worth the impact on the system. VM-physical Te evaluators argued that the TCSEC required “A1 space manager • Implemented in Pascal, PL/1, and assemblydiscretionary access controls.” In the end, the team VMP documented a way to confgure a VAX/SVS system for I/O services single-user VMs, with the expectation that user orga- IOS nizations would confgure their VAX/SVS systems for Lower-level scheduler more efcient and adequately secure multiuser VMs. ‣ About 48K SLOC altogether LLS We note that the tradition of documenting an evaluated Hardware confguration with specifc security atributes, knowing interrupt handlers full well it will be largely impractical, continues today. HIH Modified microcode Layered Design for virtualization Te VAX/SVS layered design approach proved to be key to a number of areas. Te Orange Book called for sig- VAX hardware nifcant use of layering, abstraction, and data hiding. A levels-of-abstraction approach in security kernel design Figure 1. VAX/SVS layers (from “A VMM Security Kernel for was recommended as a means to reduce complexity the VAX Architecture”1). Each layer implemented a well- Systems and Internet Infrastructure Security Laboratory (SIIS) and an aid in precise and understandable specifcations. defined abstraction in the system. HigherPage layers could call Reduced complexity was a core principle of VAX/SVS; on the services of lower layers whereas lower layers were the team lived by the “keep it simple, stupid” moto. Te forbidden from calling on higher layers. team followed other classic layered design principles, including a separation of concerns between the layers, low coupling between layers and high cohesion within them, and limited exposure to layer internals.

www.computer.org/security 29 VAX/SVS Project

• Project Successes was behind the action. Two privileges were reserved for VMs, so these VMs needed to be privileged. Te VAX/ Users SVS designers were primarily concerned with ensur- ing that mandatory security could be enforced. Because ‒ performing these two privileged operations outside the Virtual machine operating system ‣ System was piloted in 1989 “reasonablykernel didn’t violate successful” that goal, the designers preferred limiting these abilities rather than creating a larger and Security perimeter more complex kernel. In addition to mandatory access control and user Secure Virtual ‣ “A VMM Security Kernel for the VAXprivileges, Architecture” VAX/SVS implemented discretionary access server VAX control (access control lists) on objects. Te discretion- SSVR VVAX ary access control’s efectiveness was the only major Kernel interface was lead paper and Best Paper Awardarea ofwinner disagreement between theat development the team and TCSEC evaluators. Te design was optimized KI around multiuser VMs#if each user required his or Visual printers her own VM, the physical memory requirement for VPrint 1990 IEEE Symposium on Security anda commercially Privacy viable VAX/SVS system would have Virtual terminals grown beyond what was available, and the team would have had to modify the design to demand page VMs’ VTerm memories. In the chosen design, a VM would operate Volumes at a specifc mandatory access class (level and category VOL ‣ Comprehensive effort for A1 assuranceset) with read-write applying access to objects at that access class Files-11 files and read access to objects at lower confdentiality access classes (that is, lower security level and lesser category F11F formal methods for system design, test,set). All users maintenance, who needed to access objects at that VM’s Audit trail access class would share the machine. AUD With multiuser VMs, VAX/SVS couldn’t determine Higher-level scheduler and cover channels with high assurance which individual user took a spe- HLS cifc action for the purpose of enforcing discretionary VM-virtual access control or collecting an audit trail. Te VAX/SVS space manager team argued that, given the reality of Trojan horses, the VMV security gain wasn’t worth the impact on the system. VM-physical • Nonetheless, the project was cancelledTe evaluators arguedin that 1990 the TCSEC required “A1 space manager discretionary access controls.” In the end, the team VMP documented a way to confgure a VAX/SVS system for I/O services single-user VMs, with the expectation that user orga- IOS nizations would confgure their VAX/SVS systems for Lower-level scheduler ‣ Lack of customers ‒ export controls moredid efcient not and adequately help secure multiuser VMs. We note that the tradition of documenting an evaluated LLS Hardware confguration with specifc security atributes, knowing interrupt handlers full well it will be largely impractical, continues today. HIH Modified microcode ‣ Lack of features ‒ e.g., no networkingLayered support Design for virtualization Te VAX/SVS layered design approach proved to be key to a number of areas. Te Orange Book called for sig- VAX hardware nifcant use of layering, abstraction, and data hiding. A levels-of-abstraction approach in security kernel design Figure 1. VAX/SVS layers (from “A VMM Security Kernel for was recommended as a means to reduce complexity the VAX Architecture”1). Each layer implemented a well- Systems and Internet Infrastructure Security Laboratory (SIIS) and an aid in precise and understandable specifcations. defined abstraction in the system. HigherPage layers could call Reduced complexity was a core principle of VAX/SVS; on the services of lower layers whereas lower layers were the team lived by the “keep it simple, stupid” moto. Te forbidden from calling on higher layers. team followed other classic layered design principles, including a separation of concerns between the layers, low coupling between layers and high cohesion within them, and limited exposure to layer internals.

www.computer.org/security 29 VAX/SVS Project

• Other issues that may have had an impact ‣ Drivers are in the VMM security kernel

• DMA enables malicious device to overwrite physical memory

• Implications? ‣ Multi-user and privileged VMs

• Achieving A1 assurance in practice requires tracking individual users, but no visibility into VMs

• Implications?

‣ Assembly code

• About 11K SLOC of the VMM security kernel was implemented in assembly

Systems and Internet Infrastructure Security Laboratory (SIIS) Page Recent and Future Work

• Signiﬁcant advances since then ‣ Hardware support for security

• E.g., IOMMU ‣ Software architectures 1for microkernel security • E.g., Decentralized 8,700 information li nes ﬂow controlof C ‣ Program analysis for security0 bugs *

• E.g., Validation and retroﬁtting of security in programs qed ‣ Formal methods for security

• E.g., seL4 • These advances address several prior limitations *conditions apply Systems and Internet Infrastructure Security Laboratory (SIIS) Page RecentSmall Kernels and Future Work

•Small Signiﬁcant trustworthy advances foundation since then Untrusted Trusted ‣ • Hardwarehypervisor, supportmicrokernel, for security nano-kernel, virtual machine, • E.g., IOMMU Legacy separation kernel, exokernel ... Sensitive LegacyApps App. Legacy App. App ‣ Software architectures for security • High assurance components in • presenceE.g., Decentralized of other components information ﬂow control

Linux Trusted ‣ Program analysis for security Server Service • E.g.,seL4 Validation API: and retroﬁtting of security in programs - IPC ‣ Formal- methodsThreads for security seL4 • E.g., -seL4VM - IRQ Hardware • These advances- Capabilities address several prior limitations

• Signiﬁcant advances since then ‣ Hardware support for security Expectation • E.g., IOMMU

‣ Software architecturesSpecification for security

• E.g., Decentralized information ﬂow control Proof ‣ Program analysis for security

• E.g., Validation and retroﬁtting of security in programs Code ‣ Formal methods for security Assumptions • E.g., seL4 • These advances address several prior limitations

constdefs switch_to_thread :: thread_ptr unit s_monad switch_to_thread t do ⇤ state get; ⇥ assert (get_tcb t state = None); arch_switch_to_thread t;⌅ modify (s. s ( cur_thread := t )) | | Proof Architecture od Recent and Futureconstdefs Work switch_to_idle_thread :: unit s_monad switch_to_idle_thread do thread gets idle_thread; ⇥ • SignificantAccess advances Control Spec since then arch_switch_to_idle_thread;Confinement modify (s. s ( cur_thread := thread )) od | | ‣ Hardware support for security definition schedule :: unit s_monad where • E.g., IOMMU schedule do threads allActiveTCBs; ‣ SoftwareSpecification architectures for securitythread ⇥select threads; switch_to_thread⇥ thread od • E.g., Decentralized information flowOR control switch_to_idle_thread

‣ Program analysis for security end

• Haskell E.g., ValidationDesign and retroﬁtting of security in programs Prototype ‣ Formal methods for security 22 Threads and TCBs

theory Tcb_A • E.g., seL4 imports CSpace_A ArchVSpace_A Schedule_A Ipc_decls_A begin

• These advancesC Code address severalconstdefs prior limitations set_thread_state :: obj_ref thread_state unit s_monad ⇤ ⇤ © NICTA 2009 set_thread_state ref ts do 12 tcb assert_opt_get $ get_tcb ref; Systems and Internet Infrastructure Security Laboratory (SIIS) ⇥ Page set_object ref (TCB (tcb ( tcb_state := ts ))) od | |

defs suspend_def: suspend lazy thread do ipc_cancel thread; set_thread_state thread Inactive od

constdefs restart :: obj_ref unit s_monad restart thread do ⇤ state get_thread_state thread; when (⇥ runnable state) $ do ipc_cancel¬ thread;

NICTA Conﬁdential 66 RecentImplications and Future Work

•Execution Signiﬁcant always advances defined: since then Specification • no null pointer de-reference ‣ Hardware support for security • no buffer overflows C Code • • noE.g., code IOMMU injection ‣ • Softwareno memory architectures leaks/out of kernel for memorysecurity • no div by zero, no undefined shift • E.g., Decentralized information ﬂow control • no undefined execution ‣ • Programno infinite analysisloops/recursion for security

• E.g., Validation and retroﬁtting of security in programs Not implied: ‣ • Formal“secure” methods (define secure) for security • • zeroE.g., bugs seL4 from expectation to physical world • covert channel analysis • These advances address several prior limitations

• Signiﬁcant advances since then ‣ Hardware supportWhiteboard for security

• E.g., IOMMU

‣ Software architectures for security Haskell Formal Formal Prototype • E.g., Decentralized informationDesign ﬂow control Specification

‣ Program analysis for security

• E.g., Validation and retroﬁtting of security in programs

‣ FormalC Code methods for security • E.g., seL4 • These advances address several prior limitations

Bugs• Significant found advances since then Effort ‣ Hardware support for security Haskell design 2 py • E.g., IOMMU during testing: 16 First C impl. 2 weeks Debugging/Testing 2 months ‣ Software architectures for security Kernel verification 12 py • E.g., Decentralized information flow Formalcontrol frameworks 10 py during verification: Total 25 py ‣ Program analysis for security • in C: 160 Cost • •in E.g.,design: Validation ~150 and retrofitting of securityCommon in Criteriaprograms EAL6: $87M L4.verified: $6M ‣• Formalin spec: methods ~150 for security 460 bugs • E.g., seL4 • These advances address several prior limitations

• The importance of enforcing security in operating systems has been long recognized • Multics examined the dimensions of what to enforce (policy) how to enforce (mechanism), and need for validation • Security kernel projects explore how to validate real systems based on security designs converted to implementations • Recent and future work shows promise of overcoming some of the major challenges that have held back prior work • With the availability of a formally veriﬁed core kernel, there is an opportunity to develop secure operating environment

Systems and Internet Infrastructure Security Laboratory (SIIS) Page