Thin Hypervisor-Based Security Architectures for Embedded Platforms

Total Page:16

File Type:pdf, Size:1020Kb

Thin Hypervisor-Based Security Architectures for Embedded Platforms View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Software institutes' Online Digital Archive Thin Hypervisor-Based Security Architectures for Embedded Platforms Heradon Douglas The Royal Institute of Technology, Stockholm, Sweden Advisor: Christian Gehrmann Swedish Institute of Computer Science, Stockholm, Sweden February 26, 2010 To my wife, Guiniwere, who is everything to me. Till min hustru, Guiniwere, som är allt för mig. I would also like to thank my advisor, Christian Gehrmann, for his support, guidance and collaboration; Louise Yngström, Alan Davidson, Stewart Kowalski and my other teachers and colleagues at DSV for their generosity and tutelage; and my friends and family for their love. ABSTRACT Virtualization has grown increasingly popular, thanks to its benefits of isolation, management, and utilization, supported by hardware advances. It is also re- ceiving attention for its potential to support security, through hypervisor-based services and advanced protections supplied to guests. Today, virtualization is even making inroads in the embedded space, and embedded systems, with their security needs, have already started to benefit from virtualization’s security po- tential. In this thesis, we investigate the possibilities for thin hypervisor-based security on embedded platforms. In addition to significant background study, we present implementation of a low-footprint, thin hypervisor capable of provd- ing security protections to a single FreeRTOS guest kernel on ARM. Backed by performance test results, our hypervisor provides security to a formerly unse- cured kernel with minimal performance overhead, and represents a first step in a greater research effort into the security advantages and possibilities of embed- ded thin hypervisors. Our results show that thin hypervisors are both possible and beneficial even on limited embedded systems, and sets the stage for more advanced investigations, implementations, and security applications in the fu- ture. CONTENTS List of Tables . viii List of Figures . ix Abbreviations . x 1. Introduction ................................. 1 1.1 Security and Virtualization on Embedded Systems . 1 1.2 Thesis Organization . 2 1.3 Problem Definition . 2 1.3.1 Impetus . 2 1.3.2 Originality . 2 1.3.3 Feasibility . 3 1.4 Purpose and Goals . 3 1.5 Method . 3 2. Virtualization Technologies ........................ 5 2.1 What is virtualization? . 5 2.2 Virtualization Basics . 6 2.2.1 Interfaces . 6 2.2.2 Types of virtualization . 8 2.2.3 Non-standard systems . 12 2.3 Hypervisors . 12 2.3.1 Traditional hypervisors . 12 2.3.2 Hosted hypervisors . 13 2.3.3 Microkernels . 14 2.3.4 Thin hypervisors . 14 2.4 Advantages of System Virtualization . 15 2.4.1 Isolation . 15 2.4.2 Minimized trusted computing base . 16 2.4.3 Architectural flexibility . 16 2.4.4 Simplified development . 16 2.4.5 Management . 17 2.4.6 Security . 17 2.5 Hardware Support for Virtualization . 18 2.5.1 Basic virtualization requirements . 19 2.5.2 Challenges in x86 architecture . 19 2.5.3 Intel VT . 20 2.5.4 AMD-V . 24 2.5.5 ARM TrustZone . 25 2.6 Typical Virtualization Scenarios . 27 2.6.1 Hosting center . 27 2.6.2 Desktop . 28 Contents vi 2.6.3 Service provider . 28 2.6.4 Mobile/embedded . 28 2.7 Hypervisor-based security architectures . 29 2.7.1 Advantages . 29 2.7.2 Virtualization security challenges . 29 2.7.3 Architectural limitations . 31 2.7.4 Architectural patterns . 33 2.7.5 Isolation-based services . 34 2.7.6 Monitoring-based services . 39 2.7.7 Alternatives . 41 2.8 Summary . 41 3. Multicore and Embedded Systems .................... 42 3.1 Embedded systems . 42 3.1.1 Traditional characteristics . 42 3.1.2 Emerging trends . 42 3.2 Virtualization and embedded systems . 43 3.2.1 Existing platforms . 43 3.2.2 Companies . 43 3.2.3 Applications . 44 3.3 Multicore systems . 46 3.3.1 Why multicore? . 46 3.3.2 Hardware considerations . 47 3.3.3 Software considerations . 49 3.3.4 Interesting multicore architectures . 51 3.4 Multicore and virtualization . 52 3.4.1 Multicore virtualization architectures . 53 3.5 Embedded multicore systems . 54 3.5.1 Virtualization and embedded multicore . 54 3.6 Summary . 55 4. Thin Hypervisors on ARM Architecture ................. 56 4.1 ARMv5 Architecture . 57 4.1.1 Operating modes . 57 4.1.2 Exceptions and exception handlers . 57 4.1.3 Registers . 58 4.1.4 MMU . 59 4.1.5 Key differences with ARM TrustZone processors . 62 4.2 The FreeRTOS Kernel . 63 4.3 Thin Hypervisor Approach . 64 4.3.1 General concerns . 64 4.3.2 A thin hypervisor on TrustZone . 67 4.3.3 A thin hypervisor for FreeRTOS . 68 4.4 Analysis and Transitioning of Current Systems . 69 4.4.1 Kernel code interity . 69 4.4.2 Application protection . 71 4.4.3 Identifying covert binaries . 74 4.5 Summary . 76 Contents vii 5. Implementation of a Thin Hypervisor .................. 77 5.1 Use of OVP . 77 5.2 Overall structure . 78 5.2.1 The core kernel . 79 5.2.2 Platform-dependent code . 79 5.2.3 The hypervisor . 79 5.3 Key system aspects . 80 5.3.1 Hypercall interface . 80 5.3.2 Memory protection . 81 5.3.3 Interrupts and yielding . 83 5.4 Security Analysis . 83 5.5 Design Recommendations . 85 5.5.1 Trapping vs. Hypercalls . 85 5.5.2 Memory protection . 85 5.5.3 Security Services . 86 5.5.4 Multicore . 86 5.5.5 Hardware heterogeneity . 86 5.5.6 Multiple guests . 87 5.6 Summary . 87 6. Performance Tests ............................. 88 6.1 Description of Tests . 88 6.2 Results . 89 7. Conclusions and Future Work ....................... 90 7.1 Future Work . 90 7.2 Conclusions . 90 LIST OF TABLES 4.1 ARMv5 operating modes . 57 4.2 ARMv5 exceptions . 58 4.3 ARMv5 “special” general purpose registers. 58 4.4 ARMv5 system control coprocessor registers . 60 4.5 ARMv5 MMU access control . 61 4.6 Memory domains . 66 5.1 Hypercall interface . 80 6.1 Test Results, in OVP-simulated instruction counts . 89 LIST OF FIGURES 2.1 Virtualization in a nutshell . 5 2.2 Interposition . 6 2.3 Virtual memory for processes . 9 2.4 System virtualization . 10 2.5 Domain isolation in a mobile device . 34 5.1 Overall implementation structure . 78 5.2 MMU domains . 81 5.3 Interrupt sequence . 83 ABBREVIATIONS ABI Application Binary Interface API Application Programming Interface ASID Address Space Identifier CPSR current program status register CPU central processing unit DMA direct memory access DMAC DMA controller DMR dual-modular redundancy DRM Digital Rights Management EPT Extended Page Table FCSE PID Fast Context-Switch Extension Process ID I/O Input/Output IOMMU I/O Memory Management Unit IPC interprocess communication ISA Instruction Set Architecture MAC Mandatory Access Control MMM Mixed-Mode Multicore reliability MMU Memory Management Unit MPU Memory Protection Unit MVA modified virtual address.
Recommended publications
  • UG1046 Ultrafast Embedded Design Methodology Guide
    UltraFast Embedded Design Methodology Guide UG1046 (v2.3) April 20, 2018 Revision History The following table shows the revision history for this document. Date Version Revision 04/20/2018 2.3 • Added a note in the Overview section of Chapter 5. • Replaced BFM terminology with VIP across the user guide. 07/27/2017 2.2 • Vivado IDE updates and minor editorial changes. 04/22/2015 2.1 • Added Embedded Design Methodology Checklist. • Added Accessing Documentation and Training. 03/26/2015 2.0 • Added SDSoC Environment. • Added Related Design Hubs. 10/20/2014 1.1 • Removed outdated information. •In System Level Considerations, added information to the following sections: ° Performance ° Clocking and Reset 10/08/2014 1.0 Initial Release of document. UltraFast Embedded Design Methodology Guide Send Feedback 2 UG1046 (v2.3) April 20, 2018 www.xilinx.com Table of Contents Chapter 1: Introduction Embedded Design Methodology Checklist. 9 Accessing Documentation and Training . 10 Chapter 2: System Level Considerations Performance. 13 Power Consumption . 18 Clocking and Reset. 36 Interrupts . 41 Embedded Device Security . 45 Profiling and Partitioning . 51 Chapter 3: Hardware Design Considerations Configuration and Boot Devices . 63 Memory Interfaces . 69 Peripherals . 76 Designing IP Blocks . 94 Hardware Performance Considerations . 102 Dataflow . 108 PL Clocking Methodology . 112 ACP and Cache Coherency. 116 PL High-Performance Port Access. 120 System Management Hardware Assistance. 124 Managing Hardware Reconfiguration . 127 GPs and Direct PL Access from APU . 133 Chapter 4: Software Design Considerations Processor Configuration . 137 OS and RTOS Choices . 142 Libraries and Middleware . 152 Boot Loaders . 156 Software Development Tools . 162 UltraFast Embedded Design Methodology GuideSend Feedback 3 UG1046 (v2.3) April 20, 2018 www.xilinx.com Chapter 5: Hardware Design Flow Overview .
    [Show full text]
  • Vmware Fusion 12 Vmware Fusion Pro 12 Using Vmware Fusion
    Using VMware Fusion 8 SEP 2020 VMware Fusion 12 VMware Fusion Pro 12 Using VMware Fusion You can find the most up-to-date technical documentation on the VMware website at: https://docs.vmware.com/ VMware, Inc. 3401 Hillview Ave. Palo Alto, CA 94304 www.vmware.com © Copyright 2020 VMware, Inc. All rights reserved. Copyright and trademark information. VMware, Inc. 2 Contents Using VMware Fusion 9 1 Getting Started with Fusion 10 About VMware Fusion 10 About VMware Fusion Pro 11 System Requirements for Fusion 11 Install Fusion 12 Start Fusion 13 How-To Videos 13 Take Advantage of Fusion Online Resources 13 2 Understanding Fusion 15 Virtual Machines and What Fusion Can Do 15 What Is a Virtual Machine? 15 Fusion Capabilities 16 Supported Guest Operating Systems 16 Virtual Hardware Specifications 16 Navigating and Taking Action by Using the Fusion Interface 21 VMware Fusion Toolbar 21 Use the Fusion Toolbar to Access the Virtual-Machine Path 21 Default File Location of a Virtual Machine 22 Change the File Location of a Virtual Machine 22 Perform Actions on Your Virtual Machines from the Virtual Machine Library Window 23 Using the Home Pane to Create a Virtual Machine or Obtain One from Another Source 24 Using the Fusion Applications Menus 25 Using Different Views in the Fusion Interface 29 Resize the Virtual Machine Display to Fit 35 Using Multiple Displays 35 3 Configuring Fusion 37 Setting Fusion Preferences 37 Set General Preferences 37 Select a Keyboard and Mouse Profile 38 Set Key Mappings on the Keyboard and Mouse Preferences Pane 39 Set Mouse Shortcuts on the Keyboard and Mouse Preference Pane 40 Enable or Disable Mac Host Shortcuts on the Keyboard and Mouse Preference Pane 40 Enable Fusion Shortcuts on the Keyboard and Mouse Preference Pane 41 Set Fusion Display Resolution Preferences 41 VMware, Inc.
    [Show full text]
  • Improving the Reliability of Commodity Operating Systems
    Improving the Reliability of Commodity Operating Systems MICHAEL M. SWIFT, BRIAN N. BERSHAD, and HENRY M. LEVY University of Washington Despite decades of research in extensible operating system technology, extensions such as device drivers remain a significant cause of system failures. In Windows XP, for example, drivers account for 85% of recently reported failures. This paper describes Nooks, a reliability subsystem that seeks to greatly enhance OS reliability by isolating the OS from driver failures. The Nooks approach is practical: rather than guaranteeing complete fault tolerance through a new (and incompatible) OS or driver architecture, our goal is to prevent the vast majority of driver-caused crashes with little or no change to existing driver and system code. Nooks isolates drivers within lightweight protection domains inside the kernel address space, where hardware and software prevent them from corrupting the kernel. Nooks also tracks a driver’s use of kernel resources to facilitate automatic clean-up during recovery. To prove the viability of our approach, we implemented Nooks in the Linux operating system and used it to fault-isolate several device drivers. Our results show that Nooks offers a substantial increase in the reliability of operating systems, catching and quickly recovering from many faults that would otherwise crash the system. Under a wide range and number of fault conditions, we show that Nooks recovers automatically from 99% of the faults that otherwise cause Linux to crash. While Nooks was designed for drivers, our techniques generalize to other kernel extensions. We demonstrate this by isolating a kernel-mode file system and an in-kernel Internet service.
    [Show full text]
  • The OKL4 Microvisor: Convergence Point of Microkernels and Hypervisors
    The OKL4 Microvisor: Convergence Point of Microkernels and Hypervisors Gernot Heiser, Ben Leslie Open Kernel Labs and NICTA and UNSW Sydney, Australia ok-labs.com ©2010 Open Kernel Labs and NICTA. All rights reserved. Microkernels vs Hypervisors > Hypervisors = “microkernels done right?” [Hand et al, HotOS ‘05] • Talks about “liability inversion”, “IPC irrelevance” … > What’s the difference anyway? ok-labs.com ©2010 Open Kernel Labs and NICTA. All rights reserved. 2 What are Hypervisors? > Hypervisor = “virtual machine monitor” • Designed to multiplex multiple virtual machines on single physical machine VM1 VM2 Apps Apps AppsApps AppsApps OS OS Hypervisor > Invented in ‘60s to time-share with single-user OSes > Re-discovered in ‘00s to work around broken OS resource management ok-labs.com ©2010 Open Kernel Labs and NICTA. All rights reserved. 3 What are Microkernels? > Designed to minimise kernel code • Remove policy, services, retain mechanisms • Run OS services in user-mode • Software-engineering and dependability reasons • L4: ≈ 10 kLOC, Xen ≈ 100 kLOC, Linux: ≈ 10,000 kLOC ServersServers ServersServers Apps Servers Device AppsApps Drivers Microkernel > IPC performance critical (highly optimised) • Achieved by API simplicity, cache-friendly implementation > Invented 1970 [Brinch Hansen], popularised late ‘80s (Mach, Chorus) ok-labs.com ©2010 Open Kernel Labs and NICTA. All rights reserved. 4 What’s the Difference? > Both contain all code executing at highest privilege level • Although hypervisor may contain user-mode code as well > Both need to abstract hardware resources • Hypervisor: abstraction closely models hardware • Microkernel: abstraction designed to support wide range of systems > What must be abstracted? • Memory • CPU • I/O • Communication ok-labs.com ©2010 Open Kernel Labs and NICTA.
    [Show full text]
  • Performance Analysis of Selected Hypervisors (Virtual Machine Monitors - Vmms) Waldemar Graniszewski, Adam Arciszewski
    INTL JOURNAL OF ELECTRONICS AND TELECOMMUNICATIONS, 2016, VOL. 62, NO. 3, PP. 231–236 Manuscript received August 12, 2016; revised September, 2016. DOI: 10.1515/eletel-2016-0031 Performance analysis of selected hypervisors (Virtual Machine Monitors - VMMs) Waldemar Graniszewski, Adam Arciszewski Abstract—Virtualization of operating systems and network results for CPU, NIC, kernel compilation time and storage infrastructure plays an important role in current IT projects. benchmarks’ tests are presented in Section IV. Finally, in With the number of services running on different hardware Section V, we draw some conclusions. resources it is easy to provide availability, security and efficiency using virtualizers. All virtualization vendors claim that their hypervisor (virtual machine monitor - VMM) is better than their II. BACKGROUND AND RELATED WORK competitors. In this paper we evaluate performance of different In this section we present some general background for solutions: proprietary software products (Hyper-V, ESXi, OVM, VirtualBox), and open source (Xen). We are using standard virtualisation technology (in Subsection II-A) and a short benchmark tools to compare efficiency of main hardware com- review of related work (in Subsection II-B). ponents, i.e. CPU (nbench), NIC (netperf), storage (Filebench), memory (ramspeed). Results of each tests are presented. A. Background Keywords—virtualisation, virtualmachines, benchmark, per- As mentioned earlier, in Section I, cloud computing and formance, hypervisor, virtual machine monitor, vmm services provided by data centers require robust software for their operation. With data center server consolidation, the I. INTRODUCTION portability of each solution plays an important role. In the N recent years the most popular IT projects have been last decade both proprietary software like VMware ESXi, Mi- I based on cloud computing.
    [Show full text]
  • Carrier Grade Virtualization
    Carrier Grade Virtualization Leveraging virtualization in Carrier Grade Systems Abstract Network Equipment Providers (NEPs) have been building networking infrastructure equipment able to deliver “carrier grade” services, typically mission-critical services such as voice telephony. In decades past, NEPs have achieved high degrees of availability through purpose-built hardware and software implementations. Today they increasingly build on COTS (Commercial Off The Shelf) hardware and Open Source Software (OSS), freeing their engineering resources to focus on core telephony competencies. The move to COTS and OSS requires that these hardware and software components be available from an ecosystem of suppliers, and that they interoperate seamlessly. Bodies such as The Linux Foundation (LF), the Service Availability Forum (SA Forum) and PICMG have defined standards and specifications such as carrier grade OSes (CGLinux), Service Availability Forum APIs and AdvancedTCA hardware to target carrier grade applications. Recent advances have made virtualization appealing for carrier class equipment by permitting significant cost reduction through consolidation of workloads and of physical hardware. Virtualization also transparently lets NEPs and other OEMs (Original Equipment Manufacturers) leverage multi-core processors to run legacy software designed for uniprocessor hardware. However, virtualization needs to meet specific requirements to enable network equipment deploying this technology to meet industry expectations for carrier grade systems. This
    [Show full text]
  • Information Guide for Managing Vmware Esxi : Vmware, Inc
    INFORMATION GUIDE Managing VMware ESXi VMWARE INFORMATION GUIDE Table of Contents Introduction ............................................................................................................ 3 Deployment ........................................................................................................... 3 Large-Scale Standardized Deployment ............................................................. 4 Interactive and Scripted Management ................................................................. 5 VI Client .............................................................................................................. 5 Remote Command Line Interfaces .................................................................... 6 File Management ............................................................................................... 7 Remote Command Line Interface and ESX 3 ..................................................... 8 Third-Party Management Applications ................................................................. 8 Common Information Model ............................................................................. 8 VI API .................................................................................................................. 8 SNMP .................................................................................................................. 9 System Image Design ............................................................................................. 10 Patching and Upgrading
    [Show full text]
  • A Lightweight Virtualization Layer with Hardware-Assistance for Embedded Systems
    PONTIFICAL CATHOLIC UNIVERSITY OF RIO GRANDE DO SUL FACULTY OF INFORMATICS COMPUTER SCIENCE GRADUATE PROGRAM A LIGHTWEIGHT VIRTUALIZATION LAYER WITH HARDWARE-ASSISTANCE FOR EMBEDDED SYSTEMS CARLOS ROBERTO MORATELLI Dissertation submitted to the Pontifical Catholic University of Rio Grande do Sul in partial fullfillment of the requirements for the degree of Ph. D. in Computer Science. Advisor: Prof. Fabiano Hessel Porto Alegre 2016 To my family and friends. “I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu) for 386(486) AT clones.” (Linus Torvalds) ACKNOWLEDGMENTS I would like to express my sincere gratitude to those who helped me throughout all my Ph.D. years and made this dissertation possible. First of all, I would like to thank my advisor, Prof. Fabiano Passuelo Hessel, who has given me the opportunity to undertake a Ph.D. and provided me invaluable guidance and support in my Ph.D. and in my academic life in general. Thank you to all the Ph.D. committee members – Prof. Carlos Eduardo Pereira (dissertation proposal), Prof. Rodolfo Jardim de Azevedo, Prof. Rômulo Silva de Oliveira and Prof. Tiago Ferreto - for the time invested and for the valuable feedback provided.Thank you Dr. Luca Carloni and the other SLD team members at the Columbia University in the City of New York for receiving me and giving me the opportunity to work with them during my ‘sandwich’ research internship. Eu gostaria de agraceder minha esposa, Ana Claudia, por ter estado ao meu lado durante todo o meu período de doutorado. O seu apoio e compreensão foram e continuam sendo muito importantes para mim.
    [Show full text]
  • Linux Virtualization Update
    Linux Virtualization Update Chris Wright <[email protected]> Japan Linux Symposium, November 2007 Intro Virtualization mini-summit Paravirtualization Full virtualization Hardware changes Libvirt Xen Virtualization Mini-summit June 25-27, 2007 ± Just before OLS in Ottawa. 18 attendees ● Xen, Vmware, KVM, lguest, UML, LinuxOnLinux ● x86, ia64, PPC and S390 Focused primarily on Linux as guest and areas of cooperation ● paravirt_ops and virtio Common interfaces ● Not the best group to design or discuss management interfaces ● Defer to libvirt, CIM, etc... ● CPUID 0x4000_00xx for hypervisor feature detection ● Can we get to common ABI for paravirt hybrid guest? Virtualization Mini-summit paravirt_ops ● Make use of existing abstractions wherever possible (clocksource, clockevents or irqchip) ● Could use a common lib/x86_emulate.c ● Open question: performance benefit of shadow vs. direct paging? Distro Issues ● Lack of feature parity between bare metal and Xen is difficult for distros ● Single binary kernel image ● Merge upstream Performance ● NUMA awareness lacking in Xen ± difficult for Altix ● Static NUMA representation doesn©t map well to dynamic virt environment ● Cooperative memory management ± guest memory hints Virtualization Mini-summit Hardware ● x86 and ia64 hardware virtualization roadmap ● ppc virtualization is gaining in embedded market, realtime requirments ● S390 ªhas an instruction for thatº Virtio ● Separate driver from transport ● Makes driver small, looks like a Linux driver and reusable ● Hypervisor specific
    [Show full text]
  • Ubuntu Server Guide Basic Installation Preparing to Install
    Ubuntu Server Guide Welcome to the Ubuntu Server Guide! This site includes information on using Ubuntu Server for the latest LTS release, Ubuntu 20.04 LTS (Focal Fossa). For an offline version as well as versions for previous releases see below. Improving the Documentation If you find any errors or have suggestions for improvements to pages, please use the link at thebottomof each topic titled: “Help improve this document in the forum.” This link will take you to the Server Discourse forum for the specific page you are viewing. There you can share your comments or let us know aboutbugs with any page. PDFs and Previous Releases Below are links to the previous Ubuntu Server release server guides as well as an offline copy of the current version of this site: Ubuntu 20.04 LTS (Focal Fossa): PDF Ubuntu 18.04 LTS (Bionic Beaver): Web and PDF Ubuntu 16.04 LTS (Xenial Xerus): Web and PDF Support There are a couple of different ways that the Ubuntu Server edition is supported: commercial support and community support. The main commercial support (and development funding) is available from Canonical, Ltd. They supply reasonably- priced support contracts on a per desktop or per-server basis. For more information see the Ubuntu Advantage page. Community support is also provided by dedicated individuals and companies that wish to make Ubuntu the best distribution possible. Support is provided through multiple mailing lists, IRC channels, forums, blogs, wikis, etc. The large amount of information available can be overwhelming, but a good search engine query can usually provide an answer to your questions.
    [Show full text]
  • Netflix Security Requirements for Android Platforms Version 1.0 December 6, 2010
    Netflix Security Requirements for Android Platforms Version 1.0 December 6, 2010 Netflix Confidential Overall Security Philosophy • Netflix and Partners are working together to create a market for connected platforms and services • For long-term success, this requires a healthy and secure ecosystem – Based on best practices – Transparency between content, service, and platform partners – Proactive cooperation, rapid response • Our mutual success depends on it – Breaches hurt everyone Netflix Confidential Typical Studio Requirements • Platforms must meet agreed-upon robustness specifications (Netflix Robustness Rules, DRM providers’ robustness rules) • Platform partners must submit sample products and security documentation to Netflix for certification. – Netflix must review documentation and assess compliance with robustness specifications • If a platform is breached, Netflix or partner may be required to revoke individual or class of platforms. • In case of extended breach or platform non-compliance, studio has option to suspend availability of content to the Netflix service. – Such action would adversely affect all platforms and all Netflix subscribers. Netflix Confidential Android vs. Studio Requirements • Most Android platforms have been “rooted” – yields full control of system – history suggests this problem will not go away • Once rooting occurs, Linux security model is insufficient to protect content -related assets • Without modification, these platforms do not allow Netflix to meet contractual obligations to studios • We are aggressively working with partners to address this vulnerability Netflix Confidential High-Level Platform Security Concerns • Content Protection – DRM keys – Content keys – AV content • Application Security – Application keys – Access to Netflix APIs & functionality – Non-modifiability – Non-migrateability Netflix Confidential Content Protection: DRM Keys • Group key – typically provisioned in manufacturing – one key for entire class of devices (e.g.
    [Show full text]
  • Full Virtualization on Low-End Hardware: a Case Study
    Full Virtualization on Low-End Hardware: a Case Study Adriano Carvalho∗, Vitor Silva∗, Francisco Afonsoy, Paulo Cardoso∗, Jorge Cabral∗, Mongkol Ekpanyapongz, Sergio Montenegrox and Adriano Tavares∗ ∗Embedded Systems Research Group Universidade do Minho, 4800–058 Guimaraes˜ — Portugal yInstituto Politecnico´ de Coimbra (ESTGOH), 3400–124 Oliveira do Hospital — Portugal zAsian Institute of Technology, Pathumthani 12120 — Thailand xUniversitat¨ Wurzburg,¨ 97074 Wurzburg¨ — Germany Abstract—Most hypervisors today rely either on (1) full virtua- a hypervisor-specific, often proprietary, interface. Full virtua- lization on high-end hardware (i.e., hardware with virtualization lization on low-end hardware, on the other end, has none of extensions), (2) paravirtualization, or (3) both. These, however, those disadvantages. do not fulfill embedded systems’ requirements, or require legacy software to be modified. Full virtualization on low-end hardware Full virtualization on low-end hardware (i.e., hardware with- (i.e., hardware without virtualization extensions), on the other out dedicated support for virtualization) must be accomplished end, has none of those disadvantages. However, it is often using mechanisms which were not originally designed for it. claimed that it is not feasible due to an unacceptably high Therefore, full virtualization on low-end hardware is not al- virtualization overhead. We were, nevertheless, unable to find ways possible because the hardware may not fulfill the neces- real-world quantitative results supporting those claims. In this paper, performance and footprint measurements from a sary requirements (i.e., “the set of sensitive instructions for that case study on low-end hardware full virtualization for embedded computer is a subset of the set of privileged instructions” [1]).
    [Show full text]