CHERI: a research platform deconflating hardware virtualisation and protection

Contemporary CPU architectures conflate virtualization and protection, imposing virtualization-related performance, programmability, and debuggability penalties on software requiring finegrained protection. First observed in micro-kernel research, these problems are increasingly apparent in recent attempts to mitigate software vulnerabilities through application compartmentalisation. Capability Hardware Enhanced RISC Instructions (CHERI) extend RISC ISAs to support greater software compartmentalisation. CHERI’s hybrid capability model provides fine-grained compartmentalisation within address spaces while maintaining software backward compatibility, which will allow the incremental deployment of fine-grained compartmentalisation in both our most trusted and least trustworthy C-language software stacks. We have implemented a 64-bit MIPS research soft core, BERI, as well as a capability coprocessor, and begun adapting commodity software packages (FreeBSD and Chromium) to execute on the platform

CHERI: A hybrid capability-system architecture for scalable software compartmentalization

CHERI extends a conventional RISC Instruction- Set Architecture, compiler, and operating system to support fine-grained, capability-based memory protection to mitigate memory-related vulnerabilities in C-language TCBs. We describe how CHERI capabilities can also underpin a hardware-software object-capability model for application compartmentalization that can mitigate broader classes of attack. Prototyped as an extension to the open-source 64-bit BERI RISC FPGA softcore processor, FreeBSD operating system, and LLVM compiler, we demonstrate multiple orders-of-magnitude improvement in scalability, simplified programmability, and resulting tangible security benefits as compared to compartmentalization based on pure Memory-Management Unit (MMU) designs. We evaluate incrementally deployable CHERI-based compartmentalization using several real-world UNIX libraries and applications.We thank our colleagues Ross Anderson, Ruslan Bukin, Gregory Chadwick, Steve Hand, Alexandre Joannou, Chris Kitching, Wojciech Koszek, Bob Laddaga, Patrick Lincoln, Ilias Marinos, A Theodore Markettos, Ed Maste, Andrew W. Moore, Alan Mujumdar, Prashanth Mundkur, Colin Rothwell, Philip Paeps, Jeunese Payne, Hassen Saidi, Howie Shrobe, and Bjoern Zeeb, our anonymous reviewers, and shepherd Frank Piessens, for their feedback and assistance. This work is part of the CTSRD and MRC2 projects sponsored by the Defense Advanced Research Projects Agency (DARPA) and the Air Force Research Laboratory (AFRL), under contracts FA8750-10-C- 0237 and FA8750-11-C-0249. The views, opinions, and/or findings contained in this paper are those of the authors and should not be interpreted as representing the official views or policies, either expressed or implied, of the Department of Defense or the U.S. Government. We acknowledge the EPSRC REMS Programme Grant [EP/K008528/1], Isaac Newton Trust, UK Higher Education Innovation Fund (HEIF), Thales E-Security, and Google, Inc.This is the author accepted manuscript. The final version is available at http://dx.doi.org/10.1109/SP.2015.

Enhancing systems integration by incorporating business continuity drivers

Purpose – The purpose of this paper is to present a framework for developing an integrated operating environment (IOE) within an enterprise information system by incorporating business continuity drivers. These drivers enable a business to continue with its operations even if some sort of failure or disaster occurs. Design/methodology/approach – Development and implementation of the framework are based on holistic and top-down approach. An IOE on server’s side of contemporary business computing is investigated in depth. Findings – Key disconnection points are identified, where systems integration technologies can be used to integrate platforms, protocols, data and application formats, etc. Downtime points are also identified and explained. A thorough list of main business continuity drivers (continuous computing (CC) technologies) for enhancing business continuity is identified and presented. The framework can be utilized in developing an integrated server operating environment for enhancing business continuity. Originality/value – This paper presents a comprehensive framework including exhaustive handling of enabling drivers as well as disconnection points toward CC and business continuity

PLC Virtualization and Software Defined Architectures in Industrial Control Systems

Today’s automation systems are going through a transition called Industry 4.0, referring to the Fourth Industrial Revolution. New concepts, such as cyber-physical systems, mi-croservices and Smart Factory are introduced. This brings up the question of how some of these new technologies can be utilized in Industrial Control Systems. Machines and production lines are nowadays controlled by hardware PLCs and this is considered as a state-of-the-art solution. However, the market demands are continuously increasing and pushing the industry e.g. to lower the operational costs and to develop more agile solutions. Industry 4.0 provides promising approaches to take a step forward and consider PLC virtualization. The purpose of this thesis was to evaluate PLC virtualization possibilities using different Software Defined Architectures. Requirements and benefits of different solutions were evaluated. The major objective of the case study was to compare container- and hypervisor-based virtualization solutions using Docker and KVM. The case study provides a modular and scalable IIoT solution in which a virtual PLC takes over the control instead of a hardware PLC. Node-RED was used as a runtime environment and an I/O-module was needed to set up a control loop test. Response time of the control loop was measured by capturing Modbus traffic with tcpdump. Multiple iterations were performed to show minimum, maximum, average, median and 90th pctl. latencies. The results indicate that the container-based solution has a smaller overhead than the hypervisor-based solution and it has a very little overhead in general. Peak latencies are a concern and even the average latencies show that this solution would not be suitable for any hard real-time or safety-related applications. Further investigation on the topic would be needed to estimate the actual potential of PLC virtualization on hard real-time applications. First of all, a more powerful hardware PC would be needed to perform such tests. Secondly, a faster industrial protocol than Modbus TCP/IP would be required. Perhaps another kind of approach would be needed to overcome the issues that were experienced in this case study. It would be interesting to test a direct communication between virtual PLC and I/O and use Node-RED nodes for example to trigger inputs. Anyhow, it seems that container-based solution is holding much promise as a virtualization approach