US20160070658A1 - Multi-level, hardware-enforced domain separation using a separation kernel on a multicore processor with a shared cache - Google Patents

Multi-level, hardware-enforced domain separation using a separation kernel on a multicore processor with a shared cache Download PDF

Info

Publication number
US20160070658A1
US20160070658A1 US14/480,456 US201414480456A US2016070658A1 US 20160070658 A1 US20160070658 A1 US 20160070658A1 US 201414480456 A US201414480456 A US 201414480456A US 2016070658 A1 US2016070658 A1 US 2016070658A1
Authority
US
United States
Prior art keywords
shared
processing cores
domains
management units
memory
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
US14/480,456
Other versions
US9436619B2 (en
Inventor
Brandon Woolley
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Raytheon Co
Original Assignee
Raytheon Co
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Raytheon Co filed Critical Raytheon Co
Assigned to RAYTHEON COMPANY reassignment RAYTHEON COMPANY ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: WOOLLEY, BRANDON
Priority to US14/480,456 priority Critical patent/US9436619B2/en
Priority to EP19190794.8A priority patent/EP3598309B1/en
Priority to EP15739453.7A priority patent/EP3191966B1/en
Priority to PCT/US2015/039394 priority patent/WO2016039841A1/en
Priority to AU2015315801A priority patent/AU2015315801B2/en
Publication of US20160070658A1 publication Critical patent/US20160070658A1/en
Publication of US9436619B2 publication Critical patent/US9436619B2/en
Application granted granted Critical
Priority to IL250714A priority patent/IL250714B/en
Active legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14Protection against unauthorised use of memory or access to memory
    • G06F12/1458Protection against unauthorised use of memory or access to memory by checking the subject access rights
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02Addressing or allocation; Relocation
    • G06F12/08Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0806Multiuser, multiprocessor or multiprocessing cache systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02Addressing or allocation; Relocation
    • G06F12/08Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0806Multiuser, multiprocessor or multiprocessing cache systems
    • G06F12/084Multiuser, multiprocessor or multiprocessing cache systems with a shared cache
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02Addressing or allocation; Relocation
    • G06F12/08Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/0802Addressing of a memory level in which the access to the desired data or data block requires associative addressing means, e.g. caches
    • G06F12/0806Multiuser, multiprocessor or multiprocessing cache systems
    • G06F12/0842Multiuser, multiprocessor or multiprocessing cache systems for multiprocessing or multitasking
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02Addressing or allocation; Relocation
    • G06F12/08Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/10Address translation
    • G06F12/1009Address translation using page tables, e.g. page table structures
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02Addressing or allocation; Relocation
    • G06F12/08Addressing or allocation; Relocation in hierarchically structured memory systems, e.g. virtual memory systems
    • G06F12/10Address translation
    • G06F12/1081Address translation for peripheral access to main memory, e.g. direct memory access [DMA]
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601Interfaces specially adapted for storage systems
    • G06F3/0602Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/062Securing storage systems
    • G06F3/0622Securing storage systems in relation to access
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601Interfaces specially adapted for storage systems
    • G06F3/0628Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0662Virtualisation aspects
    • G06F3/0665Virtualisation aspects at area level, e.g. provisioning of virtual or logical volumes
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601Interfaces specially adapted for storage systems
    • G06F3/0668Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/0671In-line storage system
    • G06F3/0673Single storage device
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/4401Bootstrapping
    • G06F9/4405Initialisation of multiprocessor systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/468Specific access rights for resources, e.g. using capability register
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/54Interprogram communication
    • G06F9/547Remote procedure calls [RPC]; Web services
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • G06F2009/45587Isolation or security of virtual machine instances
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/45558Hypervisor-specific management and integration aspects
    • G06F2009/45595Network integration; Enabling network access in virtual machine instances
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/10Providing a specific technical effect
    • G06F2212/1052Security improvement
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/28Using a specific disk cache architecture
    • G06F2212/281Single cache
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/62Details of cache specific to multiprocessor cache arrangements

Definitions

  • the present disclosure is directed in general to multicore processor systems, and, more particularly, to multicore processor systems with at least one shared cache.
  • Multicore processors include multiple processing cores on the same integrated circuit die, usually with private, high-level caches also on the same die and often with a shared, lower-level cache either on the same die or in the same package. These configurations have made possible previously theoretical but impractical security attacks, such as timed thread switching and page table entry modification.
  • a separation kernel isolating memory domains within a shared system memory is executed on the cores of a multicore processor having hardware security enforcement for static virtual address mappings, to implement an efficient embedded multi-level security system.
  • Shared caches are either disabled or constrained by the same static virtual address mappings using the hardware security enforcement available, to isolate domains accessible to select cores and reduce security risks from data co-mingling.
  • FIG. 1 is a high level block diagram of a system implementing multi-level, hardware-enforced domain separation using a separation kernel on a multicore processor with a shared cache in accordance with embodiments of the present disclosure
  • FIG. 2 is a high level block diagram of a multicore processor with a shared cache that may be employed to implement multi-level, hardware-enforced domain separation using a separation kernel in accordance with embodiments of the present disclosure
  • FIG. 3 diagrammatically illustrates one core isolation and partitioning configuration of a multicore processor with a shared cache that may be realized with a separation kernel to implement a multi-level, hardware-enforced domain separation in accordance with embodiments of the present disclosure
  • FIG. 4 diagrammatically illustrates another core isolation and partitioning configuration of a multicore processor with a shared cache that may be realized with a separation kernel to implement a multi-level, hardware-enforced domain separation in accordance with embodiments of the present disclosure
  • FIGS. 5 and 6 are high level flowcharts for processes of configuring core isolation and partitioning in a multicore processor with a shared cache executing a separation kernel to implement a multi-level, hardware-enforced domain separation in accordance with embodiments of the present disclosure.
  • MLS multi-level secure
  • AMP symmetric multi-processing
  • SoC Freescale QorIQ system-on-a-chip
  • QorIQ Trust Architecture the built-in QorIQ Trust Architecture
  • FIG. 1 is a high level block diagram of a system implementing multi-level, hardware-enforced domain separation using a separation kernel on a multicore processor with a shared cache in accordance with embodiments of the present disclosure.
  • the system 100 includes a multicore processor 101 , which in the exemplary embodiment is one of the QorIQ family of multicore processors available from Freescale Semiconductor, Inc., such as the model P4080 processor.
  • the multicore processor 101 is communicably coupled by a system bus 102 to a system memory 103 , and, in the exemplary embodiment, also to a transceiver 104 and to a plurality of peripheral devices 105 , 106 and 107 .
  • the system may be implemented, for example, as part of an unmanned aerial vehicle (UAV), an infrared imaging satellite, or a missile system.
  • UAV unmanned aerial vehicle
  • UIR infrared imaging satellite
  • missile system a missile system
  • FIG. 2 is a high level block diagram of a multicore processor with a shared cache that may be employed to implement multi-level, hardware-enforced domain separation using a separation kernel in accordance with embodiments of the present disclosure.
  • the multicore processor 101 is preferably a Freescale QorIQ processor, although any multiprocessor with the security features described herein may be employed instead.
  • Multicore processor 101 includes a plurality of processors. In the exemplary embodiment, eight processors 201 a - 201 h, named “core 0” to “core 7,” are formed in the integrated circuit of multicore processor 101 .
  • Each processor 201 a - 201 h includes a processing core 202 , the circuitry executing instructions of a program.
  • Each processor also includes a level one (L1) data cache (“D-Cache”) 203 and an L1 instruction cache (“I-Cache”) 204 , each 32 kilobytes (KB) in size and each holding working copies of data and program instructions, respectively, for operations executed within the respective processor 202 .
  • Each processor 202 also includes a level two (L2) backside cache 205 (e.g., 128 KB), a combined data and instruction cache.
  • HV MMU memory management unit
  • HV MMU hardware virtualization memory management unit
  • the HV MMU 206 performs, in hardware, virtualization of memory addresses for locations within system memory. That is, ranges of virtual memory addresses defined for use by software operating within the processor 201 a (or 201 b, 201 c, etc.) map to physical memory locations.
  • the mapping and subsequent address translations are controlled by HV MMU 206 , which is employed at least during read or write accesses to system memory and which operates cooperatively for cache control and, to the extent necessary, bus arbitration.
  • the two L1 caches 203 and 204 are communicably coupled to a coherency fabric 207 , which in the example of a QorIQ processor is implemented by the CoreNet coherency fabric.
  • Front side level three (L3) caches 208 and 209 (e.g., 1024 KB) are also communicably coupled to coherency fabric 207 , and are each coupled to a respective memory controller 210 and 211 .
  • L3 caches 208 and 209 are shared by processors 201 a - 201 h, and thus each can contain data for software executing within different ones of those processors. While applications executing in the processors 201 a - 201 h may be designed to operate exclusively within respective memory address ranges, the co-mingling of data within a shared cache presents potential opportunities for security attacks.
  • the coherency fabric 207 manages coherency of the caches 203 , 204 and 205 for each processor 201 a - 201 h and of shared caches 208 and 209 with each other and with system memory (not shown).
  • the coherency fabric 207 also provides scalable on-chip, point-to-point connectivity supporting concurrent traffic to and from multiple resources connected to the fabric 207 , eliminating single-point bottlenecks for non-competing resources and thus avoiding various bus contention and latency issues associated with scaling shared bus/shared memory architectures.
  • the coherency fabric 207 is connected with communications resources (not shown), such as Ethernet frame managers/buffers and input/output (I/O) ports according to various other communications standards with test/debug interfaces (also not shown), and/or with security engines and managers (also not shown).
  • communications resources such as Ethernet frame managers/buffers and input/output (I/O) ports according to various other communications standards with test/debug interfaces (also not shown), and/or with security engines and managers (also not shown).
  • PAMUs peripheral access management units
  • the PAMUs 212 - 216 serve as the input/output (I/O) MMUs for the multicore processor 101 , providing I/O device-to-memory access control, protection and address translation in a manner allowing creation of a securely partitioned system.
  • the multicore processor 101 may be configured so that all DMA-capable I/O devices must go through one of the PAMUs for memory accesses, with the respective PAMU employing a set of software-configured tables to determine what physical address ranges the device is permitted to access.
  • DMA direct memory access
  • FIG. 3 diagrammatically illustrates one core isolation and partitioning configuration of a multicore processor with a shared cache that may be realized with a separation kernel to implement a multi-level, hardware-enforced domain separation in accordance with embodiments of the present disclosure.
  • the configuration 300 employs all processors 201 a - 201 h of the exemplary multi-core processor of FIG. 2 , together with the respective HV MMUs 206 a - 206 h and PAMUs 214 - 215 .
  • each of the processors 201 a - 201 h executes a separation kernel and the L3 caches 208 - 209 are disabled (not utilized).
  • a “separation kernel” is an operating system security kernel used to create an environment that is indistinguishable from physically distributed systems; that is, each domain appears to all other domains as a separate, isolated machine and information flow between domains is limited to known, external communication lines.
  • the characteristics of a separation kernel are defined, for example, by the Separation Kernel Protection Profile (SKPP) promulgated by the Information Assurance Directorate of the U.S. National Security Agency (NSA), and enterprises may seek evaluation and approval of products through the National Information Assurance Partnership (NIAP). Examples of approved, commercially available separation kernels include INTEGRITY-178B from Green Hills Software and VxWorks MILS from Wind River. It should be noted that embedded hypervisors and similar resources found in many multicore processor designs may support implementation of separation kernels, but typically do not, taken alone, meet the requirements for a separation kernel.
  • each processor 201 a - 201 h is a separate domain (domain 0 through domain 7).
  • Each processor 201 a - 201 h executes a separation kernel to enforce static MMU and PAMU mappings in the MMUs 206 a - 206 h and PAMUs.
  • PAMUs 214 - 215 effectively become logically separate PAMUs 214 a - 214 d and 215 a - 215 d for each (for example) 1 Gigabyte Ethernet (“GigE”) communication resource coupled via the coherency fabric 207 .
  • GigE Gigabyte Ethernet
  • the shared main memory 301 of the system 100 is partitioned by the separation kernel into command, control and status registers 302 , a hardware virtualization private memory 303 , and separate private memories 310 through 317 for each of the separate domains. Because the L3 caches have been disabled and are unused, data co-mingling at that cache level no longer poses a security risk, at a performance penalty that is acceptable for the improved security.
  • FIG. 4 diagrammatically illustrates another core isolation and partitioning configuration of a multicore processor with a shared cache that may be realized with a separation kernel to implement a multi-level, hardware-enforced domain separation in accordance with embodiments of the present disclosure.
  • the configuration 400 employs all processors 201 a - 201 h of the exemplary multi-core processor of FIG. 2 , together with the respective HV MMUs 206 a - 206 h and PAMUs 214 - 215 .
  • each of the processors 201 a - 201 h executes a separation kernel and the L3caches 208 - 209 are enabled.
  • the processors 201 a - 201 h are divided into two separate domains (domain 0 and domain 1), with each domain using a separate L3cache.
  • each processor 201 a - 201 h executes a separation kernel to enforce static MMU and PAMU mappings in the MMUs 206 a - 206 h and PAMUs 214 a - 214 d and 215 a - 215 d.
  • the shared main memory 401 of the system 100 is partitioned by the separation kernel, as above, into command, control and status registers 402 , and a hardware virtualization private memory 403 .
  • one L3 cache 208 is used exclusively by one set of processors ( 201 a - 201 d, in the example depicted), while a separate L3 cache 209 is used exclusively for the remaining processors ( 201 e - 201 h, in this example).
  • the processors 201 a - 201 h need not be divided equally between the two domains, and the sizes of domain private memories 410 - 411 need not be equal, as in the example depicted and described. Because the L3 caches are each only used within one domain, the security risk of data co-mingling at the L3 cache level can be controlled by assigning either only one application or only trusted applications to execute within one domain, while all other applications execute in the other domain.
  • FIGS. 5 and 6 are high level flowcharts for processes of configuring core isolation and partitioning in a multicore processor with a shared cache executing a separation kernel to implement a multi-level, hardware-enforced domain separation in accordance with embodiments of the present disclosure.
  • the process 500 illustrated by FIG. 5 begins with performance of the boot process for a separation kernel within a multicore processor (step 501 ).
  • the boot process for a multicore processor begins with booting one of the cores, core 0 in this example, to a point of functionality allowing that core to set certain configuration parameters for the entire multicore processor (i.e., enforced on all cores).
  • any shared caches within the memory hierarchy are disabled (step 503 ). In the example of FIG. 2 , both shared L3 caches 208 - 209 are disabled.
  • caches at other levels may be additional caches at other levels (e.g., below L3) between the processors and shared system memory that are shared, or caches at other levels that are shared between processors (e.g., a shared L2 cache).
  • Shared caches are disabled, but private caches (such as caches 203 - 205 in the example of FIG. 2 ) remain enabled and are utilized together with shared system memory. With shared caches disabled, security attacks based on data co-mingling within such caches are precluded.
  • the enforcement of static MMU and PAMU virtual address mappings by the separation kernel creates isolated domains (one for each core, in this example), minimizing opportunities for security attacks based on data co-mingling.
  • the process 600 illustrated by FIG. 6 also begins with performance of the boot process for a separation kernel within a multicore processor (step 601 ).
  • the enforcement of static MMU and PAMU virtual address mappings by the separation kernel is performed by taking into consideration the architecture of the shared cache(s) and the cores, so that only selected processors access a particular shared cache. For an architecture with two shared caches at a given level, half of the cores may be restricted to using one of the shared caches and the remaining cores to using the other, as in the example described above. Alternatively, as few as one core may be permitted to use one cache by the enforced static MMU and PAMU mappings, with the remaining cores allowed only to use other cache(s).
  • This effective extension of the separation kernel's private memory domains from system memory up into the shared caches creates at least two isolated domains.
  • the domain of a selected security-sensitive application is restricted (step 603 ) to the exclusion of other applications that are either untrusted or for which data co-mingling is deemed a security risk not worth the available performance gains, opportunities for security attacks based on data co-mingling are minimized.
  • FIGS. 5 and 6 are not actually mutually exclusive with respect to use or non-use of available shared caches.
  • use of shared caches may be selectively disabled for certain processing cores while static MMU/PAMU mappings are enforced to both isolate domains within shared system memory and extend such isolation to nominally shared caches.
  • use of a shared cache may be disabled for all but one core, which executes only the security and latency sensitive application (all other applications restricted to other cores).
  • a multicore processor having hardware security enforcement may be employed to implement an efficient embedded MLS system by executing a separation kernel on the processing cores and organizing the processing cores to take advantage of the available hardware enforcement technologies.
  • the selective disabling of shared caches and/or extension of domain isolation imposed by the separation kernel from shared system memory up into any shared (and enabled) caches reduces security risks from data co-mingling.
  • MLS multi-level secure
  • AMP symmetric multi-processor
  • SoC Freescale QorIQ system-on-a-chip
  • SoC Freescale QorIQ system-on-a-chip
  • QorIQ Trust Architecture together with an approved separation kernel, co-mingling of data for different security level processing can be prevented.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Human Computer Interaction (AREA)
  • Computer Security & Cryptography (AREA)
  • Memory System Of A Hierarchy Structure (AREA)

Abstract

A separation kernel isolating memory domains within a shared system memory is executed on the cores of a multicore processor having hardware security enforcement for static virtual address mappings, to implement an efficient embedded multi-level security system. Shared caches are either disabled or constrained by the same static virtual address mappings using the hardware security enforcement available, to isolate domains accessible to select cores and reduce security risks from data co-mingling.

Description

    TECHNICAL FIELD
  • The present disclosure is directed in general to multicore processor systems, and, more particularly, to multicore processor systems with at least one shared cache.
  • BACKGROUND OF THE DISCLOSURE
  • Multicore processors include multiple processing cores on the same integrated circuit die, usually with private, high-level caches also on the same die and often with a shared, lower-level cache either on the same die or in the same package. These configurations have made possible previously theoretical but impractical security attacks, such as timed thread switching and page table entry modification.
  • There is, therefore, a need in the art for improved data security in multicore processor systems.
  • SUMMARY OF THE DISCLOSURE
  • A separation kernel isolating memory domains within a shared system memory is executed on the cores of a multicore processor having hardware security enforcement for static virtual address mappings, to implement an efficient embedded multi-level security system. Shared caches are either disabled or constrained by the same static virtual address mappings using the hardware security enforcement available, to isolate domains accessible to select cores and reduce security risks from data co-mingling.
  • Although specific advantages have been enumerated above, various embodiments may include some, none, or all of the enumerated advantages. Additionally, other technical advantages may become readily apparent to one of ordinary skill in the art after review of the following figures and description.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • For a more complete understanding of the present disclosure and its advantages, reference is now made to the following description taken in conjunction with the accompanying drawings, in which like reference numerals represent like parts:
  • FIG. 1 is a high level block diagram of a system implementing multi-level, hardware-enforced domain separation using a separation kernel on a multicore processor with a shared cache in accordance with embodiments of the present disclosure;
  • FIG. 2 is a high level block diagram of a multicore processor with a shared cache that may be employed to implement multi-level, hardware-enforced domain separation using a separation kernel in accordance with embodiments of the present disclosure;
  • FIG. 3 diagrammatically illustrates one core isolation and partitioning configuration of a multicore processor with a shared cache that may be realized with a separation kernel to implement a multi-level, hardware-enforced domain separation in accordance with embodiments of the present disclosure;
  • FIG. 4 diagrammatically illustrates another core isolation and partitioning configuration of a multicore processor with a shared cache that may be realized with a separation kernel to implement a multi-level, hardware-enforced domain separation in accordance with embodiments of the present disclosure; and
  • FIGS. 5 and 6 are high level flowcharts for processes of configuring core isolation and partitioning in a multicore processor with a shared cache executing a separation kernel to implement a multi-level, hardware-enforced domain separation in accordance with embodiments of the present disclosure.
  • DETAILED DESCRIPTION
  • It should be understood at the outset that, although exemplary embodiments are illustrated in the figures and described below, the principles of the present disclosure may be implemented using any number of techniques, whether currently known or not. The present disclosure should in no way be limited to the exemplary implementations and techniques illustrated in the drawings and described below. Additionally, unless otherwise specifically noted, articles depicted in the drawings are not necessarily drawn to scale.
  • Using an evaluated and approved separation kernel with hardware enforcement as foundation technologies in accordance with the present disclosure, several multi-level secure (MLS) environments running a multicore processor running in asymmetric multi-processing (AMP) mode enable an embedded multicore computer system to support at least two security domains. Based on a Freescale QorIQ system-on-a-chip (SoC) and the built-in QorIQ Trust Architecture, together with an approved separation kernel, co-mingling of data for different security level processing can be prevented. Accordingly, by organizing the processing cores to take advantage of available hardware enforcement technologies, an efficient embedded MLS system may be implemented on a multicore processor system.
  • FIG. 1 is a high level block diagram of a system implementing multi-level, hardware-enforced domain separation using a separation kernel on a multicore processor with a shared cache in accordance with embodiments of the present disclosure. The system 100 includes a multicore processor 101, which in the exemplary embodiment is one of the QorIQ family of multicore processors available from Freescale Semiconductor, Inc., such as the model P4080 processor. The multicore processor 101 is communicably coupled by a system bus 102 to a system memory 103, and, in the exemplary embodiment, also to a transceiver 104 and to a plurality of peripheral devices 105, 106 and 107. The system may be implemented, for example, as part of an unmanned aerial vehicle (UAV), an infrared imaging satellite, or a missile system. Those skilled in the art will recognize that the full structure and operation of the system 100 is not depicted by the drawings or described herein. Instead, for simplicity and clarity, only so much of the system 100 as is either unique to the present disclosure or necessary for an understanding of the present disclosure is depicted and described.
  • FIG. 2 is a high level block diagram of a multicore processor with a shared cache that may be employed to implement multi-level, hardware-enforced domain separation using a separation kernel in accordance with embodiments of the present disclosure. As noted above, the multicore processor 101 is preferably a Freescale QorIQ processor, although any multiprocessor with the security features described herein may be employed instead. Multicore processor 101 includes a plurality of processors. In the exemplary embodiment, eight processors 201 a-201 h, named “core 0” to “core 7,” are formed in the integrated circuit of multicore processor 101. Each processor 201 a-201 h includes a processing core 202, the circuitry executing instructions of a program. Each processor also includes a level one (L1) data cache (“D-Cache”) 203 and an L1 instruction cache (“I-Cache”) 204, each 32 kilobytes (KB) in size and each holding working copies of data and program instructions, respectively, for operations executed within the respective processor 202. Each processor 202 also includes a level two (L2) backside cache 205 (e.g., 128 KB), a combined data and instruction cache.
  • One of the hardware enforcement mechanisms within the multicore processor 101 of the exemplary embodiment is a memory management unit (MMU), which in the exemplary embodiment is implemented by a hardware virtualization memory management unit (HV MMU) 206. The HV MMU 206 performs, in hardware, virtualization of memory addresses for locations within system memory. That is, ranges of virtual memory addresses defined for use by software operating within the processor 201 a (or 201 b, 201 c, etc.) map to physical memory locations. The mapping and subsequent address translations are controlled by HV MMU 206, which is employed at least during read or write accesses to system memory and which operates cooperatively for cache control and, to the extent necessary, bus arbitration.
  • The two L1 caches 203 and 204 are communicably coupled to a coherency fabric 207, which in the example of a QorIQ processor is implemented by the CoreNet coherency fabric. Front side level three (L3) caches 208 and 209 (e.g., 1024 KB) are also communicably coupled to coherency fabric 207, and are each coupled to a respective memory controller 210 and 211. When used, the L3 caches 208 and 209 are shared by processors 201 a-201 h, and thus each can contain data for software executing within different ones of those processors. While applications executing in the processors 201 a-201 h may be designed to operate exclusively within respective memory address ranges, the co-mingling of data within a shared cache presents potential opportunities for security attacks.
  • The coherency fabric 207 manages coherency of the caches 203, 204 and 205 for each processor 201 a-201 h and of shared caches 208 and 209 with each other and with system memory (not shown). The coherency fabric 207 also provides scalable on-chip, point-to-point connectivity supporting concurrent traffic to and from multiple resources connected to the fabric 207, eliminating single-point bottlenecks for non-competing resources and thus avoiding various bus contention and latency issues associated with scaling shared bus/shared memory architectures. The coherency fabric 207 is connected with communications resources (not shown), such as Ethernet frame managers/buffers and input/output (I/O) ports according to various other communications standards with test/debug interfaces (also not shown), and/or with security engines and managers (also not shown). Again, those skilled in the art will recognize that the full structure and operation of the multicore processor 101 is not depicted by the drawings or described herein. Instead, for simplicity and clarity, only so much of the multicore processor 101 as is either unique to the present disclosure or necessary for an understanding of the present disclosure is depicted and described.
  • Another hardware enforcement mechanism within the multicore processor 101 of the exemplary embodiment is the peripheral access management units (PAMUs) 212, 213, 214, 215 and 216 within the coherency fabric 207. The PAMUs 212-216 serve as the input/output (I/O) MMUs for the multicore processor 101, providing I/O device-to-memory access control, protection and address translation in a manner allowing creation of a securely partitioned system. While the PAMUs 212-216 may grant direct memory access (DMA) to peripherals, the multicore processor 101 may be configured so that all DMA-capable I/O devices must go through one of the PAMUs for memory accesses, with the respective PAMU employing a set of software-configured tables to determine what physical address ranges the device is permitted to access.
  • FIG. 3 diagrammatically illustrates one core isolation and partitioning configuration of a multicore processor with a shared cache that may be realized with a separation kernel to implement a multi-level, hardware-enforced domain separation in accordance with embodiments of the present disclosure. The configuration 300 employs all processors 201 a-201 h of the exemplary multi-core processor of FIG. 2, together with the respective HV MMUs 206 a-206 h and PAMUs 214-215. In this configuration 300, each of the processors 201 a-201 h executes a separation kernel and the L3 caches 208-209 are disabled (not utilized). A “separation kernel” is an operating system security kernel used to create an environment that is indistinguishable from physically distributed systems; that is, each domain appears to all other domains as a separate, isolated machine and information flow between domains is limited to known, external communication lines. The characteristics of a separation kernel are defined, for example, by the Separation Kernel Protection Profile (SKPP) promulgated by the Information Assurance Directorate of the U.S. National Security Agency (NSA), and enterprises may seek evaluation and approval of products through the National Information Assurance Partnership (NIAP). Examples of approved, commercially available separation kernels include INTEGRITY-178B from Green Hills Software and VxWorks MILS from Wind River. It should be noted that embedded hypervisors and similar resources found in many multicore processor designs may support implementation of separation kernels, but typically do not, taken alone, meet the requirements for a separation kernel.
  • In the embodiment of FIG. 3, each processor 201 a-201 h is a separate domain (domain 0 through domain 7). Each processor 201 a-201 h executes a separation kernel to enforce static MMU and PAMU mappings in the MMUs 206 a-206 h and PAMUs. As a result, PAMUs 214-215 effectively become logically separate PAMUs 214 a-214 d and 215 a-215 d for each (for example) 1 Gigabyte Ethernet (“GigE”) communication resource coupled via the coherency fabric 207. In addition, the shared main memory 301 of the system 100 is partitioned by the separation kernel into command, control and status registers 302, a hardware virtualization private memory 303, and separate private memories 310 through 317 for each of the separate domains. Because the L3 caches have been disabled and are unused, data co-mingling at that cache level no longer poses a security risk, at a performance penalty that is acceptable for the improved security.
  • FIG. 4 diagrammatically illustrates another core isolation and partitioning configuration of a multicore processor with a shared cache that may be realized with a separation kernel to implement a multi-level, hardware-enforced domain separation in accordance with embodiments of the present disclosure. The configuration 400 employs all processors 201 a-201 h of the exemplary multi-core processor of FIG. 2, together with the respective HV MMUs 206 a-206 h and PAMUs 214-215. In this configuration 400, each of the processors 201 a-201 h executes a separation kernel and the L3caches 208-209 are enabled. In this embodiment, however, the processors 201 a-201 h are divided into two separate domains (domain 0 and domain 1), with each domain using a separate L3cache. As above, each processor 201 a-201 h executes a separation kernel to enforce static MMU and PAMU mappings in the MMUs 206 a-206 h and PAMUs 214 a-214 d and 215 a-215 d. In addition, the shared main memory 401 of the system 100 is partitioned by the separation kernel, as above, into command, control and status registers 402, and a hardware virtualization private memory 403. On the other hand, only two partitions are necessary as separate private memories 410 and 411 for the two separate domains. In the resulting organization, one L3 cache 208 is used exclusively by one set of processors (201 a-201 d, in the example depicted), while a separate L3 cache 209 is used exclusively for the remaining processors (201 e-201 h, in this example). Of course, the processors 201 a-201 h need not be divided equally between the two domains, and the sizes of domain private memories 410-411 need not be equal, as in the example depicted and described. Because the L3 caches are each only used within one domain, the security risk of data co-mingling at the L3 cache level can be controlled by assigning either only one application or only trusted applications to execute within one domain, while all other applications execute in the other domain.
  • FIGS. 5 and 6 are high level flowcharts for processes of configuring core isolation and partitioning in a multicore processor with a shared cache executing a separation kernel to implement a multi-level, hardware-enforced domain separation in accordance with embodiments of the present disclosure. While each process flow and/or event sequence depicted in the figures and described involves a sequence of steps and/or events, occurring either in series or in tandem, unless explicitly stated or otherwise self-evident (e.g., a signal cannot be received before being transmitted), no inference should be drawn regarding specific order of performance of steps or occurrence of events, performance of steps or portions thereof or occurrence of events serially rather than concurrently or in an overlapping manner, or performance the steps or occurrence of the events depicted exclusively without the occurrence of intervening or intermediate steps or events. Moreover, those skilled in the art will recognize that complete processes and event sequences are not illustrated or described. Instead, for simplicity and clarity, only so much of the respective processes and event sequences as is unique to the present disclosure or necessary for an understanding of the present disclosure is depicted and described.
  • The process 500 illustrated by FIG. 5 begins with performance of the boot process for a separation kernel within a multicore processor (step 501). Typically the boot process for a multicore processor begins with booting one of the cores, core 0 in this example, to a point of functionality allowing that core to set certain configuration parameters for the entire multicore processor (i.e., enforced on all cores). Accordingly, once the primary core has been sufficiently booted (step 502), any shared caches within the memory hierarchy are disabled (step 503). In the example of FIG. 2, both shared L3 caches 208-209 are disabled. In other embodiments, however, there may be additional caches at other levels (e.g., below L3) between the processors and shared system memory that are shared, or caches at other levels that are shared between processors (e.g., a shared L2 cache). Shared caches are disabled, but private caches (such as caches 203-205 in the example of FIG. 2) remain enabled and are utilized together with shared system memory. With shared caches disabled, security attacks based on data co-mingling within such caches are precluded. Within the shared system memory, the enforcement of static MMU and PAMU virtual address mappings by the separation kernel (step 504) creates isolated domains (one for each core, in this example), minimizing opportunities for security attacks based on data co-mingling.
  • The process 600 illustrated by FIG. 6 also begins with performance of the boot process for a separation kernel within a multicore processor (step 601). Rather than disabling shared caches, however, the enforcement of static MMU and PAMU virtual address mappings by the separation kernel (step 602) is performed by taking into consideration the architecture of the shared cache(s) and the cores, so that only selected processors access a particular shared cache. For an architecture with two shared caches at a given level, half of the cores may be restricted to using one of the shared caches and the remaining cores to using the other, as in the example described above. Alternatively, as few as one core may be permitted to use one cache by the enforced static MMU and PAMU mappings, with the remaining cores allowed only to use other cache(s). This effective extension of the separation kernel's private memory domains from system memory up into the shared caches creates at least two isolated domains. When the domain of a selected security-sensitive application is restricted (step 603), to the exclusion of other applications that are either untrusted or for which data co-mingling is deemed a security risk not worth the available performance gains, opportunities for security attacks based on data co-mingling are minimized.
  • It will be noted by those skilled in the art that the techniques of FIGS. 5 and 6 are not actually mutually exclusive with respect to use or non-use of available shared caches. For architectures in which use of a shared cache may be enabled or disabled on a core-by-core basis, for example, use of shared caches may be selectively disabled for certain processing cores while static MMU/PAMU mappings are enforced to both isolate domains within shared system memory and extend such isolation to nominally shared caches. For a system executing one security and latency sensitive application and a plurality of applications for which the latency without caching is acceptable, use of a shared cache may be disabled for all but one core, which executes only the security and latency sensitive application (all other applications restricted to other cores).
  • A multicore processor having hardware security enforcement may be employed to implement an efficient embedded MLS system by executing a separation kernel on the processing cores and organizing the processing cores to take advantage of the available hardware enforcement technologies. In particular, the selective disabling of shared caches and/or extension of domain isolation imposed by the separation kernel from shared system memory up into any shared (and enabled) caches reduces security risks from data co-mingling.
  • Using an evaluated and approved separation kernel with hardware enforcement as foundation technologies in accordance with the present disclosure, several multi-level secure (MLS) environments running a multicore processor running in asymmetric multi-processor (AMP) mode enable an embedded multicore computer system to support at least two security domains. Based on a Freescale QorIQ system-on-a-chip (SoC) and the built-in QorIQ Trust Architecture, together with an approved separation kernel, co-mingling of data for different security level processing can be prevented.
  • Modifications, additions, or omissions may be made to the systems, apparatuses, and methods described herein without departing from the scope of the disclosure. For example, the components of the systems and apparatuses may be integrated or separated. Moreover, the operations of the systems and apparatuses disclosed herein may be performed by more, fewer, or other components and the methods described may include more, fewer, or other steps. Additionally, steps may be performed in any suitable order. As used in this document, “each” refers to each member of a set or each member of a subset of a set.
  • To aid the Patent Office and any readers of any patent issued on this application in interpreting the claims appended hereto, applicants wish to note that they do not intend any of the appended claims or claim elements to invoke 35 U.S.C. §112(f) unless the words “means for” or “step for” are explicitly used in the particular claim.

Claims (20)

What is claimed is:
1. An apparatus, comprising:
a multicore processor including a plurality of processing cores, a plurality of memory management units, and a plurality of peripheral access management units, each of the processing cores operating exclusively with only one of the memory management units and each of the processing cores operating with one or more of the peripheral access management units;
at least one cache shared by the plurality of processing cores; and
a separation kernel executing within each of the plurality of processing cores, the separation kernel configured to enforce the static virtual address mappings forming isolated memory domains within a shared system memory,
wherein the apparatus is configured to isolate at least two domains within shared data storage including the shared system memory based on the static virtual address mappings, to operate at least a first of the processing cores with one of the two domains, and to separately operate at least a second of the processing cores with the other of the two domains.
2. The apparatus according to claim 1, wherein the apparatus is configured to isolate the at least two domains by disabling all shared caches within the shared data storage and enforcing the static virtual address mappings for the shared system memory.
3. The apparatus according to claim 2, wherein the apparatus is configured to isolate a plurality of domains within the shared data storage, and wherein each of the processing cores operates with a respective one of the isolated domains.
4. The apparatus according to claim 1, wherein the apparatus is configured to isolate the at least two domains by enforcing the static virtual address mappings such that the first processing core employs a first shared cache within the shared data storage and the second processing core employs a second shared cache within the shared data storage.
5. The apparatus according to claim 4, wherein two or more of the processing cores including the first processing core and excluding the second processing core employ the first shared cache, and wherein two or more of the processing cores including the second processing core and excluding the first processing core employ the second shared cache within the shared data storage.
6. The apparatus according to claim 1, wherein the memory management units are hardware virtualization memory management units implementing hardware virtualization of physical memory addresses.
7. The apparatus according to claim 1, wherein the memory management units and the peripheral access management units are configured to enforce the static virtual address mappings.
8. A method, comprising:
operating each of a plurality of processing cores within a multicore processor exclusively with only one of a plurality of memory management units and with one or more of a plurality of peripheral access management units;
selectively sharing at least one cache by the plurality of processing cores;
executing a separation kernel within each of the plurality of processing cores, the separation kernel configured to enforce the static virtual address mappings forming at least two isolated domains within a shared system memory;
operating at least a first of the processing cores with one of the two domains; and
operating at least a second of the processing cores with the other of the two domains.
9. The method according to claim 8, further comprising:
disabling all shared caches within shared data storage including the shared system memory; and
enforcing the static virtual address mappings for the shared system memory.
10. The method according to claim 9, wherein each of the processing cores operates with a respective one of the domains.
11. The method according to claim 10, further comprising:
employing a first shared cache within the shared data storage for the first processing core; and
employing a second shared cache within the shared data storage for the second processing core.
12. The method according to claim 11, further comprising:
employing the first shared cache for two or more of the processing cores including the first processing core and excluding the second processing core; and
employing the second shared cache for two or more of the processing cores including the second processing core and excluding the first processing core.
13. The method according to claim 8, wherein the memory management units are hardware virtualization memory management units implementing hardware virtualization of physical memory addresses.
14. The method according to claim 8, further comprising:
enforcing the static virtual address mappings using the memory management units and the peripheral access management units.
15. An apparatus, comprising:
a multicore processor including a plurality of processing cores each associated with a memory management unit and one or more peripheral access management units, the memory management units and the peripheral access management units each configured to selectively enforce static virtual address mappings;
at least one cache shared by the plurality of processing cores; and
a separation kernel executing within each of the plurality of processing cores, the separation kernel causing the memory management units and the peripheral access management units to enforce the static virtual address mappings, forming at least two isolated memory domains within a shared system memory,
wherein the apparatus is configured to operate at least a first of the processing cores with a first of the two domains, exclusive of a second of the two domains, and to separately operate at least a second of the processing cores with the second of the two domains, exclusive of the first of the two domains, and
wherein the apparatus is configured to one of
disable all caches shared by the processing cores, and
restrict a first physical, shared cache to operating exclusively with the first domain and a second physical, shared cache to operating exclusively with the second domain.
16. The apparatus according to claim 15, wherein the apparatus is configured to disable all caches within the shared data storage.
17. The apparatus according to claim 16, wherein each of the processing cores operates exclusively with a respective one of the domains.
18. The apparatus according to claim 15, wherein the apparatus is configured to restrict the first physical, shared cache to operate exclusively with the first domain and the second physical, shared cache to operate exclusively with the second domain.
19. The apparatus according to claim 15, wherein two or more of the processing cores, including the first processing core and excluding the second processing core, employ the first shared cache, and wherein two or more of the processing cores, including the second processing core and excluding the first processing core, employ the second shared cache within the shared data storage.
20. The apparatus according to claim 15, wherein the memory management units are hardware virtualization memory management units implementing hardware virtualization of physical memory addresses.
US14/480,456 2014-09-08 2014-09-08 Multi-level, hardware-enforced domain separation using a separation kernel on a multicore processor with a shared cache Active 2034-11-13 US9436619B2 (en)

Priority Applications (6)

Application Number Priority Date Filing Date Title
US14/480,456 US9436619B2 (en) 2014-09-08 2014-09-08 Multi-level, hardware-enforced domain separation using a separation kernel on a multicore processor with a shared cache
AU2015315801A AU2015315801B2 (en) 2014-09-08 2015-07-07 Multi-level, hardware-enforced domain separation using a separation kernel on a multicore processor with a shared cache
EP15739453.7A EP3191966B1 (en) 2014-09-08 2015-07-07 Multi-level, hardware-enforced domain separation using a separation kernel on a multicore processor with a shared cache
PCT/US2015/039394 WO2016039841A1 (en) 2014-09-08 2015-07-07 Multi-level, hardware-enforced domain separation using a separation kernel on a multicore processor with a shared cache
EP19190794.8A EP3598309B1 (en) 2014-09-08 2015-07-07 Multi-level, hardware-enforced domain separation using a separation kernel on a multicore processor with a shared cache
IL250714A IL250714B (en) 2014-09-08 2017-02-22 Multi-level, hardware-enforced domain separation using a separation kernel on a multicore processor with a shared cache

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US14/480,456 US9436619B2 (en) 2014-09-08 2014-09-08 Multi-level, hardware-enforced domain separation using a separation kernel on a multicore processor with a shared cache

Publications (2)

Publication Number Publication Date
US20160070658A1 true US20160070658A1 (en) 2016-03-10
US9436619B2 US9436619B2 (en) 2016-09-06

Family

ID=53682861

Family Applications (1)

Application Number Title Priority Date Filing Date
US14/480,456 Active 2034-11-13 US9436619B2 (en) 2014-09-08 2014-09-08 Multi-level, hardware-enforced domain separation using a separation kernel on a multicore processor with a shared cache

Country Status (5)

Country Link
US (1) US9436619B2 (en)
EP (2) EP3191966B1 (en)
AU (1) AU2015315801B2 (en)
IL (1) IL250714B (en)
WO (1) WO2016039841A1 (en)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108154054A (en) * 2016-12-02 2018-06-12 Arm 有限公司 Filter coherency protocol transaction
US10198373B2 (en) * 2016-11-30 2019-02-05 International Business Machines Corporation Uniform memory access architecture
CN110210214A (en) * 2019-06-03 2019-09-06 成都海光集成电路设计有限公司 Processor core partition method and device
US20200285595A1 (en) * 2019-03-08 2020-09-10 International Business Machines Corporation Secure storage isolation
US20210073042A1 (en) * 2019-09-05 2021-03-11 Nvidia Corporation Techniques for configuring a processor to function as multiple, separate processors
US20210224392A1 (en) * 2020-01-21 2021-07-22 Wind River Systems, Inc. Tri-Level Secure Separation Kernel
US11663036B2 (en) 2019-09-05 2023-05-30 Nvidia Corporation Techniques for configuring a processor to function as multiple, separate processors

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10846117B1 (en) * 2015-12-10 2020-11-24 Fireeye, Inc. Technique for establishing secure communication between host and guest processes of a virtualization architecture
US10447728B1 (en) 2015-12-10 2019-10-15 Fireeye, Inc. Technique for protecting guest processes using a layered virtualization architecture
US10108446B1 (en) 2015-12-11 2018-10-23 Fireeye, Inc. Late load technique for deploying a virtualization layer underneath a running operating system
US11899585B2 (en) * 2021-12-24 2024-02-13 Western Digital Technologies, Inc. In-kernel caching for distributed cache
US11934663B2 (en) 2022-01-10 2024-03-19 Western Digital Technologies, Inc. Computational acceleration for distributed cache
US11797379B2 (en) 2022-02-04 2023-10-24 Western Digital Technologies, Inc. Error detection and data recovery for distributed cache

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6754776B2 (en) * 2001-05-17 2004-06-22 Fujitsu Limited Method and system for logical partitioning of cache memory structures in a partitoned computer system
US7130977B1 (en) 2002-04-18 2006-10-31 Advanced Micro Devices, Inc. Controlling access to a control register of a microprocessor
US8190839B2 (en) 2009-03-11 2012-05-29 Applied Micro Circuits Corporation Using domains for physical address management in a multiprocessor system
US8549249B1 (en) 2009-09-21 2013-10-01 Tilera Corporation Supporting secondary atomic operations using primary atomic operations
WO2011161774A1 (en) * 2010-06-22 2011-12-29 富士通株式会社 Multi-core processor system, control program, and control method
US10514938B2 (en) 2012-12-18 2019-12-24 Dynavisor, Inc. Making direct calls to a native device driver of a hypervisor using dynamic device driver virtualization

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10198373B2 (en) * 2016-11-30 2019-02-05 International Business Machines Corporation Uniform memory access architecture
US10599590B2 (en) 2016-11-30 2020-03-24 International Business Machines Corporation Uniform memory access architecture
CN108154054A (en) * 2016-12-02 2018-06-12 Arm 有限公司 Filter coherency protocol transaction
US10664399B2 (en) * 2016-12-02 2020-05-26 Arm Limited Filtering coherency protocol transactions
US20200285595A1 (en) * 2019-03-08 2020-09-10 International Business Machines Corporation Secure storage isolation
US11531627B2 (en) * 2019-03-08 2022-12-20 International Business Machines Corporation Secure storage isolation
CN110210214A (en) * 2019-06-03 2019-09-06 成都海光集成电路设计有限公司 Processor core partition method and device
US20210073042A1 (en) * 2019-09-05 2021-03-11 Nvidia Corporation Techniques for configuring a processor to function as multiple, separate processors
US11663036B2 (en) 2019-09-05 2023-05-30 Nvidia Corporation Techniques for configuring a processor to function as multiple, separate processors
US11893423B2 (en) * 2019-09-05 2024-02-06 Nvidia Corporation Techniques for configuring a processor to function as multiple, separate processors
US20210224392A1 (en) * 2020-01-21 2021-07-22 Wind River Systems, Inc. Tri-Level Secure Separation Kernel
US11748484B2 (en) * 2020-01-21 2023-09-05 Wind River Systems, Inc. Tri-level secure separation kernel

Also Published As

Publication number Publication date
IL250714B (en) 2019-12-31
US9436619B2 (en) 2016-09-06
EP3598309B1 (en) 2022-05-11
AU2015315801A1 (en) 2017-03-02
EP3191966A1 (en) 2017-07-19
EP3191966B1 (en) 2019-10-23
AU2015315801B2 (en) 2020-05-21
EP3598309A1 (en) 2020-01-22
WO2016039841A1 (en) 2016-03-17
IL250714A0 (en) 2017-04-30

Similar Documents

Publication Publication Date Title
US9436619B2 (en) Multi-level, hardware-enforced domain separation using a separation kernel on a multicore processor with a shared cache
US10901772B2 (en) Virtualization exceptions
US8893267B1 (en) System and method for partitioning resources in a system-on-chip (SoC)
US9519596B2 (en) Resource access control in a system-on-chip
EP3185128B1 (en) Gpu virtualisation
KR101861297B1 (en) Efficient memory and resource management
US8631212B2 (en) Input/output memory management unit with protection mode for preventing memory access by I/O devices
US9858202B2 (en) Low overhead paged memory runtime protection
Porquet et al. NoC-MPU: A secure architecture for flexible co-hosting on shared memory MPSoCs
US10257166B2 (en) Guest netfilter protection by virtual machine function
US10402576B2 (en) Safe physical function passthrough using virtual machine functions
US10552345B2 (en) Virtual machine memory lock-down
US20160188354A1 (en) Efficient enabling of extended page tables
US10671419B2 (en) Multiple input-output memory management units with fine grained device scopes for virtual machines
US20190227834A1 (en) Application memory protection using an extended page table switching virtual machine function
US10698713B2 (en) Virtual processor state switching virtual machine functions
US9086906B2 (en) Apparatus and method for guest and root register sharing in a virtual machine
US10956571B2 (en) Kernel runtime integrity using processor assists
Dévigne et al. Executing secured virtual machines within a manycore architecture
Kornaros et al. Towards full virtualization of heterogeneous noc-based multicore embedded architectures
Kegel et al. Virtualizing io through io memory management unit (iommu)

Legal Events

Date Code Title Description
AS Assignment

Owner name: RAYTHEON COMPANY, MASSACHUSETTS

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:WOOLLEY, BRANDON;REEL/FRAME:033693/0386

Effective date: 20140902

FEPP Fee payment procedure

Free format text: PAYOR NUMBER ASSIGNED (ORIGINAL EVENT CODE: ASPN); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

STCF Information on status: patent grant

Free format text: PATENTED CASE

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 4TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1551); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 4

MAFP Maintenance fee payment

Free format text: PAYMENT OF MAINTENANCE FEE, 8TH YEAR, LARGE ENTITY (ORIGINAL EVENT CODE: M1552); ENTITY STATUS OF PATENT OWNER: LARGE ENTITY

Year of fee payment: 8