Complete formal verification is the only known way to guarantee that a system is free of programming errorsWe present our experience in performing the formal, machine-checked verification of the seL4 microkernel from an abstract specification down to its C implementation We assume correctness of compiler, assembly code, and hardware, and we used a unique design approach that fuses formal and operating systems techniques To our knowledge, this is the first formal proof of functional correctness of a complete, general-purpose operating-system kernel Functional correctness means here that the implementation always strictly follows our high-level abstract specification of kernel behaviour This encompasses traditional design and implementation safety properties such as the kernel will never crash, and it will never perform an unsafe operation It also proves much more: we can predict precisely how the kernel will behave in every possible situationseL4, a third-generation microkernel of L4 provenance, comprises 8,700 lines of C code and 600 lines of assembler Its performance is comparable to other high-performance L4 kernels

/pdf/sel4-formal-verification-of-an-os-kernel-20d8n4rs7p.pdf

seL4: formal verification of an OS kernel

Intel’s Software Guard Extensions (SGX) is a set of extensions to the Intel architecture that aims to provide integrity and confidentiality guarantees to securitysensitive computation performed on a computer where all the privileged software (kernel, hypervisor, etc) is potentially malicious. This paper analyzes Intel SGX, based on the 3 papers [14, 78, 137] that introduced it, on the Intel Software Developer’s Manual [100] (which supersedes the SGX manuals [94, 98]), on an ISCA 2015 tutorial [102], and on two patents [108, 136]. We use the papers, reference manuals, and tutorial as primary data sources, and only draw on the patents to fill in missing information. This paper’s contributions are a summary of the Intel-specific architectural and micro-architectural details needed to understand SGX, a detailed and structured presentation of the publicly available information on SGX, a series of intelligent guesses about some important but undocumented aspects of SGX, and an analysis of SGX’s security properties.

Intel SGX Explained.

Today, embedded, mobile, and cyberphysical systems are ubiquitous and used in many applications, from industrial control systems, modern vehicles, to critical infrastructure. Current trends and initiatives, such as "Industrie 4.0" and Internet of Things (IoT), promise innovative business models and novel user experiences through strong connectivity and effective use of next generation of embedded devices. These systems generate, process, and exchange vast amounts of security-critical and privacy-sensitive data, which makes them attractive targets of attacks. Cyberattacks on IoT systems are very critical since they may cause physical damage and even threaten human lives. The complexity of these systems and the potential impact of cyberattacks bring upon new threats. This paper gives an introduction to Industrial IoT systems, the related security and privacy challenges, and an outlook on possible solutions towards a holistic security framework for Industrial IoT systems.

/pdf/security-and-privacy-challenges-in-industrial-internet-of-193xb7473p.pdf

Security and privacy challenges in industrial internet of things

The presence of large numbers of security vulnerabilities in popular feature-rich commodity operating systems has inspired a long line of work on excluding these operating systems from the trusted computing base of applications, while retaining many of their benefits. Legacy applications continue to run on the untrusted operating system, while a small hyper visor or trusted hardware prevents the operating system from accessing the applications' memory. In this paper, we introduce controlled-channel attacks, a new type of side-channel attack that allows an untrusted operating system to extract large amounts of sensitive information from protected applications on systems like Overshadow, Ink Tag or Haven. We implement the attacks on Haven and Ink Tag and demonstrate their power by extracting complete text documents and outlines of JPEG images from widely deployed application libraries. Given these attacks, it is unclear if Over shadow's vision of protecting unmodified legacy applications from legacy operating systems running on off-the-shelf hardware is still tenable.

/pdf/controlled-channel-attacks-deterministic-side-channels-for-26lzcntreu.pdf

Controlled-Channel Attacks: Deterministic Side Channels for Untrusted Operating Systems

Today’s cloud computing infrastructure requires substantial trust. Cloud users rely on both the provider’s staff and its globally distributed software/hardware platform not to expose any of their private data.We introduce the notion of shielded execution, which protects the confidentiality and integrity of a program and its data from the platform on which it runs (i.e., the cloud operator’s OS, VM, and firmware). Our prototype, Haven, is the first system to achieve shielded execution of unmodified legacy applications, including SQL Server and Apache, on a commodity OS (Windows) and commodity hardware. Haven leverages the hardware protection of Intel SGX to defend against privileged code and physical attacks such as memory probes, and also addresses the dual challenges of executing unmodified legacy binaries and protecting them from a malicious host. This work motivated recent changes in the SGX specification.

Shielding Applications from an Untrusted Cloud with Haven

We propose SecVisor, a tiny hypervisor that ensures code integrity for commodity OS kernels. In particular, SecVisor ensures that only user-approved code can execute in kernel mode over the entire system lifetime. This protects the kernel against code injection attacks, such as kernel rootkits. SecVisor can achieve this propertyeven against an attacker who controls everything but the CPU, the memory controller, and system memory chips. Further, SecVisor can even defend against attackers with knowledge of zero-day kernel exploits.Our goal is to make SecVisor amenable to formal verificationand manual audit, thereby making it possible to rule out known classes of vulnerabilities. To this end, SecVisor offers small code size and small external interface. We rely on memory virtualization to build SecVisor and implement two versions, one using software memory virtualization and the other using CPU-supported memory virtualization. The code sizes of the runtime portions of these versions are 1739 and 1112 lines, respectively. The size of the external interface for both versions of SecVisor is 2 hypercalls. It is easy to port OS kernels to SecVisor. We port the Linux kernel version 2.6.20 by adding 12 lines and deleting 81 lines, out of a total of approximately 4.3 million lines of code in the kernel.

/pdf/secvisor-a-tiny-hypervisor-to-provide-lifetime-kernel-code-5giiagtgwg.pdf

SecVisor: a tiny hypervisor to provide lifetime kernel code integrity for commodity OSes

An important security challenge is to protect the execution of security-sensitive code on legacy systems from malware that may infect the OS, applications, or system devices. Prior work experienced a tradeoff between the level of security achieved and efficiency. In this work, we leverage the features of modern processors from AMD and Intel to overcome the tradeoff to simultaneously achieve a high level of security and high performance. We present TrustVisor, a special-purpose hypervisor that provides code integrity as well as data integrity and secrecy for selected portions of an application. TrustVisor achieves a high level of security, first because it can protect sensitive code at a very fine granularity, and second because it has a very small code base (only around 6K lines of code) that makes verification feasible. TrustVisor can also attest the existence of isolated execution to an external entity. We have implemented TrustVisor to protect security-sensitive code blocks while imposing less than 7% overhead on the legacy OS and its applications in the common case.

http://www.cse.psu.edu/~trj1/cse597-s11/docs/trustvisor_oakland10.pdf

TrustVisor: Efficient TCB Reduction and Attestation

Systems and methods are provided for preventing unauthorized modification of an operating system. The system includes an operating system comprised of kernel code for controlling access to operation of a processing unit. The system further includes an enforcement agent executing at a higher privilege than the kernel code such that any changes to the kernel code are approved by the enforcement agent prior to execution.

Systems and methods for preventing unauthorized modification of an operating system

An apparatus and method for establishing a trusted path (152) between a user interface (150) and a trusted executable (312), wherein the trusted path (152) includes a hypervisor (316) and a driver shim (314) The method includes measuring (710) an identity of the hypervisor; comparing (712) the measurement of the identity of the hypervisor with a policy for the hypervisor; measuring (714) an identity of the driver shim; comparing (716) the measurement of the identity of the driver shim with a policy for the driver shim; measuring (718) an identity of the user interface; comparing (720) the measurement of the identity of the user interface with a policy for the user interface; and providing (722) a human-perceptible indication of whether the identity of the hypervisor, the identity of the driver shim, and the identity of the user interface correspond with the policy for the hypervisor, the policy for the driver shim, and the policy for the user interface, respectively

Methods and Apparatuses for User-Verifiable Trusted Path in the Presence of Malware

We investigate a new point in the design space of red/green systems [19,30], which provide the user with a highly-protected, yet also highly-constrained trusted ("green") environment for performing security-sensitive transactions, as well as a high-performance, general-purpose environment for all other (non-security-sensitive or "red") applications. Through the design and implementation of the Lockdown architecture, we evaluate whether partitioning, rather than virtualizing, resources and devices can lead to better security or performance for red/green systems. We also design a simple external interface to allow the user to securely learn which environment is active and easily switch between them. We find that partitioning offers a new tradeoff between security, performance, and usability. On the one hand, partitioning can improve the security of the "green" environment and the performance of the "red" environment (as compared with a virtualized solution). On the other hand, with current systems, partitioning makes switching between environments quite slow (13-31 seconds), which may prove intolerable to users.

/pdf/lockdown-towards-a-safe-and-practical-architecture-for-6nt8fppykm.pdf

Ning Qu

Papers

SecVisor: a tiny hypervisor to provide lifetime kernel code integrity for commodity OSes

TrustVisor: Efficient TCB Reduction and Attestation

Systems and methods for preventing unauthorized modification of an operating system

Methods and Apparatuses for User-Verifiable Trusted Path in the Presence of Malware

Lockdown: towards a safe and practical architecture for security applications on commodity platforms