Software and Hardware Supports for Multi-OS Environment
Total Page：16
File Type：pdf, Size：1020Kb
Software and Hardware Supports for Multi-OS Environment マルチ OS 環境を支援するソフトウェア およびハードウェア機能の提案 February 2012 Waseda University Graduate School of Fundamental Science and Engineering Major in Computer Science and Engineering Research on Distributed Systems Yuki KINEBUCHI 2 c Copyright by Yuki Kinebuchi 2012 All rights reserved 2 Acknowledgements This is a great opportunity to express my respect to my thesis advisor, Prof. Tatsuo Nakajima. My research and this dissertation would not exist without his support and patience. I would also like to thank all the members at Distributed Computing Laboratory in Waseda University for encouraging me. 3 4 Abstract Personal mobile devices are rapidly enhancing their functionalities. Not limited to phone and text messages, they offer web browsing via the Internet, free to install applications on the users’ requests, play musics and videos, etc. Now they are capable of running multiple OS instances with support of virtualization. Like the use in desktop/enterprise systems, virtualization for embedded mobile devices allows consolidating multiple OS instances and enhancing the security of hosted OS environment. In addition, there are applications specific to embedded systems such as hosting real-time OS (RTOS) and application OS (GPOS) concurrently without spoiling the real-time responsiveness of the RTOS. There is no doubt that virtualization brings many benefits to the embedded mobile devices, however virtualization is not a panacea. Additional layer of virtualization incurs additional complexity to the software stack of devices. Some extra engineering efforts of developing such device might make the system prone to bugs and security risks. In this dissertation we take the position that some applications of embedded virtualization can be supported with more light-weight methods. The methods leverages architecture specific features that are common or expected to be common among embedded mobile devices. We first focus on real-time and application OS consolidation, for which we propose a thin abstraction layer that achieves better interrupt responsiveness than virtualization. Next we focus on hosting a kernel integrity monitor for rootkit detection. The monitor is hosted within an isolated memory region that is protected by means of processor architecture. 5 6 Contents 1 Introduction 1 1.1 Motivation . 1 1.2 Contributions................................... 2 1.3 Organization of the Dissertation . 2 2 Discussions on Embedded System Virtualization 5 2.1 The Use of Embedded System Virtualization . 5 2.2 Performance and Real-time Responsiveness . 6 2.3 EngineeringCost ................................. 7 2.4 Security ...................................... 8 3 Microkernel-based Multi-OS Architecture 11 3.1 Background . 11 3.2 Implementation.................................. 13 3.2.1 L4-embedded . 14 3.2.2 Wombat . 15 3.2.3 L4/TOPPERS . 16 3.3 TaskGrainScheduling.............................. 17 3.3.1 Full- and Para-virtualization . 17 3.3.2 Scheduling Algorithm . 18 3.3.3 Global Priority . 18 3.3.4 Global Scheduler . 19 3.3.5 Task Grained Scheduling in L4-embedded . 19 3.3.6 Task Grained Scheduling in Wombat . 20 3.3.7 Task Grained Scheduling in L4/TOPPERS . 20 3.4 Evaluation . 21 3.4.1 Context Switch Overhead . 22 3.4.2 InterruptDelayOverhead . 22 3.4.3 Task Grain Scheduling . 24 3.4.4 InterruptDelayJitters. 26 3.5 RelatedWork................................... 27 7 3.5.1 Improving OS Real-time Performance . 27 3.5.2 Hybrid Architecture . 28 3.5.3 Hypervisor-based Systems . 28 3.6 Summary ..................................... 29 4 Software-based Processor Core Multiplexing 31 4.1 Background . 31 4.2 Design and Implementation . 33 4.2.1 SPUMONE . 33 4.2.2 ModifyingOSKernels .......................... 35 4.3 InterruptDelayReduction. 37 4.3.1 Interrupt Priority Level Assignment . 37 4.3.2 Virtual Processor Core Migration . 38 4.4 Evaluation . 39 4.4.1 Basic Overhead . 39 4.4.2 Engineering Cost . 40 4.4.3 The Effect of Linux Load to TOPPERS Real-time Responsiveness . 41 4.4.4 The Effect of TOPPERS Periodic Task Load to Linux Throughput . 47 4.5 RelatedWork................................... 47 4.6 Summary ..................................... 50 5 Core-local Memory Assisted Protection 51 5.1 Background . 51 5.2 The LLM Architecture . 52 5.3 TheSecurePaging ................................ 54 5.3.1 Threat Detections . 61 5.4 Implementation.................................. 62 5.5 Evaluations . 63 5.5.1 Case study . 64 5.5.2 Performance . 66 5.5.3 Engineering Cost . 67 5.6 RelatedWork................................... 68 5.7 Summary ..................................... 69 6 Conclusion 71 8 List of Figures 1.1 Organization of the Dissertation . 3 3.1 Task grain scheduling . 13 3.2 Wombat . 15 3.3 L4/TOPPERS . 16 3.4 Mapping the local priorities to the global priority . 18 3.5 Globalscheduler ................................. 19 3.6 Serialinterruptdelays .............................. 22 3.7 Directandindirectinterruptdelays. 23 3.8 Dummy tasks without and with task grain scheduling . 25 3.9 Testing task grain scheduling . 26 3.10 The intervals of TOPPERS’s 2ms periodic task. 27 4.1 SPUMONE based system on a single-core processor . 33 4.2 SPUMONE based system on a multi-core processor . 33 4.3 InterruptDeliveryMechanism. 38 4.4 Theinterruptprioritylevelsassignment . 38 4.5 Virtual core migration . 39 4.6 The dispatch delay of 1ms periodic task on native TOPPERS) . 42 4.7 Dispatch delay (CPU stress on Linux without IPL modification) . 43 4.8 Dispatch delay (CPU stress on Linux with IPL modification) . 43 4.9 Dispatch delay (CF read/write stress on Linux without IPL modification) 44 4.10 Dispatch delay (CF read/write stress on Linux with IPL modification) . 44 4.11 Dispatch delay (NFS r/w stress on Linux without virt. core migration) . 45 4.12 Dispatch delay (NFS r/w stress on Linux with virt. core migration) . 45 4.13 Dispatch delay on SMP (frequent IPC on Linux without virt. core migration) 46 4.14 Dispatch delay on SMP (frequent IPC on Linux with virt. core migration) . 46 4.15 The effect of load on TOPPERS to Linux’s DMIPS score (y-axis in DMIPS, largerisbetter).................................. 48 4.16 The effect of load on TOPPERS to Linux’s hackbench (y-axis in seconds, smallerisbetter) ................................. 48 9 5.1 Loading the pager, the monitor and the target OS. 55 5.2 The pager calculates the hash value of each page. The target OS is not activated at this point. 56 5.3 Execute the entry of the monitor and trap into the pager. 57 5.4 The pager swaps in a page while calculating its hash value, and checks if thepageisaltered................................. 58 5.5 The pagers maps the checked page into the address space. 59 5.6 The pager tries to evict a page contained in the local memory to the main memory....................................... 60 5.7 The pager detects a data page that is tampered by a malicious application runningonthetargetOS. ............................ 61 5.8 The memory layout of the pseudo LLM architecture. 64 5.9 The result of Unixbench on Linux with 3 cores running beside the monitor and the secure pager. Normalized to the score of native Linux with 3 cores. 66 5.10 The result of Unixbench on Linux with 3 cores running beside the monitor and the secure pager. Normalized to the score of native Linux with 4 cores. 67 10 List of Tables 3.1 Evaluation settings . 21 3.2 Average interrupt delay: in microseconds (cycles) . 23 3.3 Worst interrupt delay: in microseconds (cycles) . 23 3.4 Average indirect timer interrupt delay: in microseconds . 24 3.5 Dummytasks................................... 25 4.1 A list of the modifications to the Linux kernel . 37 4.2 The delay of handling the timer interrupts in TOPPERS. 40 4.3 Linuxkernelbuildtime ............................. 40 4.4 The total number of modified LoC in *.c, *.S, *.h, Makefiles . 41 5.1 Lines of code modified in xv6 (rev4) to create the monitor OS. 67 5.2 Lines of code modified in Linux to run on the LLM architecture. 68 11 12 Chapter 1 Introduction Personal mobile devices are rapidly enhancing their functionalities. Not limited to phone and text messages, they offer web browsing via the Internet, free to install applications on the users’ requests, play musics and videos, etc. At this point writing this thesis the latest device is equipped with multiple processor cores run with over 1.4GHz frequency and a gigabyte of memory [6]. This outstrips the performance of desktop computers those were available in 1990s. As their hardware advances, now they are capable of running multiple OS instances with support of virtualization [9, 17, 32]. Like the use in desktop/enterprise systems, virtualization for embedded mobile devices allows consolidating multiple OS instances and enhancing the security of hosted OS environment. In addition, there are applications specific to embedded systems such as hosting real-time OS (RTOS) and application OS (GPOS) concurrently without spoiling the real-time responsiveness of the RTOS. These benefits of virtualization motivated the ARM architecture to add a hardware virtualization support to their upcoming instruction set architecture (ISA) [62]. 1.1 Motivation There is no doubt that virtualization brings many benefits to the embedded mobile de- vices, however virtualization is not a panacea. Additional layer of virtualization incurs additional complexity to the software stack of devices. The hypervisor should be designed carefully to achieve reasonable performance. The straightforward port of an existing hy- pervisor from the desktop/enterprise field to embedded field does not perform well [34]. Extra engineering efforts of developing such device might make the system prone to bugs and security risks. In Chapter 2, we discuss the advantages and disadvantage of using hypervisors for embedded systems to accomodate multiple OS kernels in detail. In this dissertation we take the position that some applications of embedded vir- tualization can be supported with more light-weight methods. The hybrid architecture [24, 66, 44, 59] and the logical partitioning of OS kernels [54] suggest the feasibility of 1 running multiple-OS system without support of hypervisors.