CN109564555B

CN109564555B - Context-based protection system

Info

Publication number: CN109564555B
Application number: CN201780044584.4A
Authority: CN
Inventors: 简-威廉·范德瓦尔德特; 凯·迪芬巴赫; 乌维·穆斯利赫纳; 文卡特·纳塔拉詹; 杰恩斯·瓦格纳; 马蒂亚斯·塞德纳
Original assignee: Cypress Semiconductor Corp
Current assignee: Cypress Semiconductor Corp
Priority date: 2016-07-19
Filing date: 2017-07-19
Publication date: 2022-12-13
Anticipated expiration: 2037-07-19
Also published as: US11416421B2; WO2018017702A1; CN109564555A; DE112017003659T5; JP7001670B2; JP2019525319A; US20180024945A1

Abstract

A context-based protection system uses a hierarchical protection architecture that includes a main protection unit, a shared memory protection unit, a peripheral protection unit to provide security for bus transfer operations between a Central Processing Unit (CPU), a memory array or a portion of an array, and a peripheral.

Description

Context-based protection system

RELATED APPLICATIONS

The present application is international application No. 15/653, 203, filed on 7/18.2017, which application claims the benefit of 62/364, 652 united states provisional patent application filed on 20.2016 and 62/364, 246, filed on 19.2016, which application is filed on 7/653, 203, which application is hereby incorporated by reference in its entirety.

Technical Field

The present disclosure relates generally to embedded systems, and more particularly to security of communications and data within embedded systems.

Drawings

FIG. 1 illustrates an embedded system that may be configured to implement a context-based protection system, according to one embodiment.

FIG. 2 illustrates a context-based protection system, according to one embodiment.

FIG. 3 illustrates a method for evaluating security of transmissions to and from a peripheral device using a protection system, according to one embodiment.

FIG. 4 illustrates a scheme for changing the protected context of a peripheral device, according to one embodiment.

FIG. 5 illustrates a scheme for changing the protected context of a peripheral device, according to one embodiment.

SUMMARY

Embedded systems function by passing information to and from various components over a series of buses. The processing unit of the embedded system may be configured to execute instructions or access information stored in one or more memories. The processing unit may also communicate with or control other system components, such as digital and analog blocks or peripherals. The digital or analog blocks or even the peripheral devices may be hard coded (fixed function) or they may be programmable. Control of system components and access to or transfer of information may be accomplished over a series of buses or bus infrastructures.

The context-based protection system may include a Central Processing Unit (CPU) configurable to operate in multiple protection contexts. The context-based protection system may also include at least one peripheral module accessible by the CPU when the CPU is configured with a first protection context of the plurality of protection contexts and inaccessible by the CPU when the CPU is configured with a second protection context of the plurality of protection contexts.

The context-based protection system may be implemented as part of a bus infrastructure that includes a protection fabric. The protection architecture may include a Memory Protection Unit (MPU) assigned to a single bus master that distinguishes between user accesses and privileged accesses from the bus master. The protection architecture may include a Shared Memory Protection Unit (SMPU) assigned to a plurality of bus masters, the SMPU to distinguish between different protection contexts and to distinguish between secure and non-secure accesses to memory. The protection architecture may also include a Peripheral Protection Unit (PPU) assigned with a peripheral group, the PPU to distinguish between secure and non-secure access to the peripheral group.

Detailed Description

The bus transfer of information may occur simultaneously with other bus transfers. Different processing units may access different system components based on system requirements and the various tasks that the system can perform. Since so many things happen simultaneously on the bus, tracking and controlling transfer operations and attempted transfer operations is very important to ensure that the system is functioning as intended with optimal performance and requiring security.

Embedded systems may also require protection to achieve security, functional security, and performance. With respect to security, it is necessary to protect the secure memory and MMIO address regions from unauthorized access. That is, access to programs and data storage must be limited to authorized use, but so must peripheral devices that can receive commands or share data over the bus. With respect to functional security, tasks and processes must be prohibited from accessing memory and MMIO address regions associated with other tasks and processes. Isolation ensures that every operation can occur even in the presence of bus interference. On the other hand, memory and MMIO address regions must be protected from tasks and processes not associated with them so that they are available for their designated tasks and processes. All such protections can cause bus delays, affecting performance. And reconfiguration of any protection system must also be possible without delay problems.

Fig. 1 shows a system 100 that may be configured to provide security through a configurable bus architecture 140. The system 100 may include an I/O subsystem 105 coupled to a CPU subsystem 110. The CPU subsystem 100 may be configured to have a plurality of inputs and outputs, including inputs and outputs to and from the I/O subsystem 105 and from the peripheral devices groups (elements not shown, but connections to

peripheral device groups

1 and 2 are shown). Other connections to the CPU subsystem 110 may also exist, as described below.

CPU subsystem 110 may include a debug infrastructure 115 and a test controller 117, both coupled to I/O subsystem 105 and to the first processing core and the second processing core. The first processing core may be implemented as an ARM Cortex M4, CM4 core 120. The CM4 core 120 may include a CM4 Central Processing Unit (CPU) 126, interrupt functions 122, and debug components 124. The CM4 core 120 may be configured to run at faster processing speeds and meet higher processing and performance requirements. The second processing core may be implemented as an ARM Cortex M0+, CM0+ core 130. The CM0+ core 130 may include a CM0+ CPU 136, interrupt functions 132, and debug components 134. The CM0+ core 130 may be configured to run at a slower processing speed (frequency) and may act as an auxiliary processor.

The CPU subsystem 110 may also include a configurable bus architecture 140, which may include a fast infrastructure 142 and a slow infrastructure 144. The configurable bus architecture 140 may be configured to provide security for data and commands passing from the processing cores, memory, and peripheral units. Configurable bus architecture 140 may be coupled to a flash controller 161 for flash 162, to a ROM controller 163 for ROM 164, and to an SRAM controller 165 for SRAM 166. In one embodiment, there may be multiple SRAM modules and associated SRAM controllers for each module. In various embodiments, the memory locations may be part of CPU subsystem 110 or part of a separate system component.

The fast infrastructure 142 may be coupled to the CM4 core 120 through a system interface (Sys I/F) and a Code interface (Code I/F) to receive information and commands from the CM4 core 120. The fast infrastructure 142 may also be coupled to peripheral interfaces and slaves that run at faster processing speeds (fast external slaves).

The slow infrastructure 144 may be coupled to the test controller 117 and to a slow external master and password (crypt) block 170 and a pair of data lines: data line 0 172 and data line 1 174. The slow infrastructure 144 may also be coupled to a slow external slave, the CM0+ core 130, and to a pair of

data lines

172 and 174. Slow infrastructure 144 may also be coupled to peripheral units external to CPU subsystem 110. The external peripheral device may include a slow external slave device.

Configurable bus architecture 140, including fast infrastructure 142 and slow infrastructure 144, may provide protection or security by implementing protection logic that allows or restricts transmissions over the bus based on bus transmission characteristics. Bus transfer characteristics may include bus address ranges and different attributes including read/write, execute, privileged/user, secure/non-secure, and others. Protection for the memory may be provided by a Memory Protection Unit (MPU) and a Shared Memory Protection Unit (SMPU). Protection for the peripheral device may be provided by a peripheral device protection unit (PPU). The SMPU and PPU may support context-based protection tracking based on bus master's protection context attributes. With this configuration, a single bus master can operate in multiple protection roles by reprogramming the fields associated with the protection context.

The CPU subsystem 110 may include protection MMIO registers 150, fault detection MMIO registers 180, CPU subsystem (CPU ss) MMIO registers 182, and inter-processor communication (IPC) MMIO registers 184 to control and configure the various elements of the CPU subsystem and provide the functions of the protection system.

FIG. 2 illustrates a block diagram of a protection system 200 that may implement a protection context, according to one embodiment of the invention. In one embodiment, the protection system 200 may be implemented in part in the configurable bus architecture 140 of fig. 1. Various elements of the protection system 200 may be implemented as register locations accessible by the system bus architecture 210 and the CPU subsystem 110 of fig. 1.

Protection system 200 may include a plurality of bus masters 201.0-201.N. Bus masters 201.0-201.N can control traffic on system bus architecture 210 when information is read from and written to memory locations of memory array 220 and to peripherals that may be part of a set of peripherals 250.0-250. N. The bus masters 201.0-201.N can each have a Memory Protection Unit (MPU) 203.0-203.N. The MPUs 203.0-203.N may be integrated into the bus masters, as shown by bus masters 201.0 and 201.3, or they may be separate elements, implemented as separate units (bus masters 201.1 and 201.2), or as part of the system bus architecture (not shown).

When the MPU is implemented as part of the bus master, as is the case for bus masters 201.0 and 201.3, the MPU may be implemented as part of the CPU and may be under the control of an Operating System (OS) or kernel. When the MPU is implemented independently of the bus master, as is the case for MPUs 203.1 and 203.2, the MPU can be implemented as part of the bus architecture (e.g., system bus architecture 210). In such embodiments, the MPU may be under the control of the OS or kernel of the CPU that "owns" or uses the bus master. For example, MPU 203.1 may be under the control of the OS or kernel of the CPU owning bus master 201.1. An MPU implemented as part of system bus architecture 210 may be associated with a bus master (such as a USB controller, an ethernet controller for a graphics controller). This list is not intended to be exhaustive; other bus masters may be used with system bus infrastructure 210. In one embodiment, MPUs similar to those illustrated as MPUs 203.0 and 203.3 can be implemented as part of the CPU to ensure a consistent software interface. In such embodiments, the MPU may be associated with a particular memory region and may be assigned a particular access attribute definition. As described below, the particular access attributes define how and why access to various system components and memory locations may be provided.

The MPUs 203.0-203.n can distinguish between user accesses and privileged accesses to a single bus master (201.1-201.n, respectively). The MPU may also perform access control for secure/non-secure attributes. MPU settings may be updated by the OS or kernel software if a bus master (e.g., bus masters 201.0-201. N) changes tasks, or if a non-CPU master associated with a separate MPU changes ownership.

In one embodiment, a Direct Memory Access (DMA) controller may be implemented with an MPU. In this embodiment, the DMA controller may inherit the access control attributes of the bus transfer (or bus transfers) that programs the channel to which the DMA controller is connected.

Protection system 200 may also include a plurality of Shared Memory Protection Units (SMPUs) 205.0-205.N. The SMPUs 205.1-205.N may each be associated with a bus master (201.1-201. N, respectively) and, if implemented, may be disposed between the MPU and the system bus architecture 210. SMPU may be shared by all bus masters 201.1-201.n; this is in contrast to MPUs 203.1-203.N, which MPUs 203.1-203.N may be dedicated to a single bus master. SMPUs 205.1-205.N may distinguish between different protected contexts and between secure and non-secure accesses. SMPUs 205.1-205.N may also perform access control based on user/privilege mode attributes.

Protection system 200 may include a system bus architecture 210 coupled to bus masters 201.1-201.N and to a memory subsystem 220. Memory subsystem 220 may include at least one memory array (illustrated as three memory arrays 223.0-223.2) and at least one memory controller (illustrated as three memory controllers 221.0-221.2). Memory controllers 221.0-221.2 may control read and write operations to memory locations in memory arrays 223.0-223.2 based on bus transfers and commands on system bus architecture 210 as indicated by bus masters 201.1-201. N. Access to the memory locations of memory arrays 223.0-223.2 may be controlled by MPUs 203.1-203.n and SMPUs 205.1-205.n.

The protection system 200 may also include a peripheral bus architecture 230 coupled to the system bus architecture 210. Peripheral bus architecture 230 may include at least one master/slave (MS) interface 231.1-231.n coupled to system bus architecture 210 for receiving bus transfers from bus masters 201.1-201.n. MS interfaces 231.1-231.n may include Peripheral Protection Units (PPUs) 233.1-233.n.

Peripheral bus architecture 230 may include arbiters 235.0-235.N for handling traffic between MS interfaces 231.1-231.N and peripheral groups 250.0-250. N. For ease of description, only the peripheral unit 250.0 is described below, but the peripheral groups 250.1-250.N may be constructed in the same manner. Peripheral group 250.0 may include PPU 251.0, PPU MMIO registers 252.0 and 253.0, SMPU MMIO registers 254.0, MPU MMIO registers 255.0, and peripheral MMIO registers 256.0. Various MMIO registers may be used to implement the security and protection implemented by system bus architecture 210 and bus architecture 140 in fig. 1.

Protection system 200 may allow each bus master to access peripheral subsystems through exactly one master/slave interface (MS 0-MS 3). As long as the access is made via different master interfaces and directed to different peripheral groups of the peripheral subsystem, the four master/slave interfaces MS are able to make up to four concurrent accesses to the peripheral.

Each master/slave interface may include a fixed PPU structure corresponding to each peripheral group and a programmable PPU structure. In each of the peripheral groups, there may be a fixed PPU structure for the peripheral sub-regions (e.g., 252 and 253) and a fixed PPU structure for each peripheral (e.g., 251). For certain protection contexts, a fixed PPU structure for a peripheral group may deny or restrict access to the entire peripheral group. In such an embodiment, exceptions to certain sub-address ranges within a peripheral group may not be allowed. Fixed PPU structures for groups of peripherals may be given highest priority and they may be located in the master/slave interface (as part of PPU 233). With this embodiment, when access is denied, the access will not reach the target set of peripheral devices; the set of peripheral devices may be simultaneously accessed by another host interface.

The fixed PPU structure for a sub-region of peripherals, as well as for the entire peripheral, may include a range of addresses that is smaller than the group of peripherals. Thus, they may be located within the peripheral group itself. Since the fixed PPU structures for the peripheral sub-regions generate exceptions according to the protection attributes of the entire peripheral, they may have a higher priority than the fixed PPU structures defined for the entire peripheral.

The programmable PPU structure may cover a combined address range for all peripheral groups. Thus, the programmable PPU structure may be located in the master/slave interface. In other embodiments, the programmable PPU structure may be located within a peripheral group. In a first embodiment, there may be duplicate programmable PPU structures in each peripheral group. In a second embodiment, the programmable PPU structures may be distributed among a set of peripherals.

FIG. 3 illustrates a method 300 of ensuring evaluation of a programmable PPU structure after a fixed PPU structure in a peripheral group. In step 310, the programmable PPU structure is evaluated. If a violation is detected in decision step 315, the information may be tagged with the violation. The fixed PPU structure may be evaluated in step 320. In one embodiment, step 320 may occur simultaneously with step 310 or independently of step 310. If no violation is detected in decision step 325, the tag information from step 330 may be evaluated in step 340. If no violation is detected in decision step 345, access may be granted in step 350. If no violations are detected in decision step 315, access may also be granted in step 350. If a violation is detected in decision step 325 or decision step 345, access may be denied in step 360.

The protection system 200 in FIG. 2 may provide a context-based protection scheme with MPUs, SMPUs, and PPUs that allows support of multiple protection structures, each specifying address ranges in a unified memory architecture and access attributes that govern how access to a given address range is allowed. The violations detected or prohibited by the protection system may be due to mismatches between the address region and access attributes of the bus transfer and the address range and access attributes of the protection fabric. When a violation is detected, the violation may be captured in a fault reporting structure, such as the faulty MMIO 180 of FIG. 1, which may allow for future analysis. It may be useful to know the cause of the error. Failures in operation may be due to defects in programming or system definition. The failure may be due to an unauthorized attempt to access or control. The fault reporting structure may generate an interrupt to indicate the occurrence of the fault. In one embodiment, interrupts may be used to indicate to a processing device external to the system that a fault has occurred and that analysis is necessary. This may be particularly useful when the bus master itself is unable to resolve a bus error, but another bus master is required on its behalf to resolve the bus error.

Violations of the protection system result in bus errors, prohibiting the bus transfer from reaching its target. For example, MPU or SMPU violations targeted by a peripheral unit do not reach the PPU of the peripheral.

Protecting contexts

Each bus master may have an MPU protection context field, PC [ ]. The protection context may be used as a protection context attribute for all bus transfers initiated by the bus master. The SMPU and PPU may allow or disallow (limit) bus transfers initiated by a bus master to memory and peripheral locations based on the protection context assigned to the bus transfer.

In one embodiment, multiple bus masters may share a protection context. For example, a CPU and a USB controller under the control of the CPU may share the same protection context. In this example, the CPU and USB controller may have the same SMPU and PPU access restrictions, and may allow or disallow bus transfers from the respective (CPU and USB controller) to the same memory or peripheral location under the same conditions.

The protection context of the bus master can be changed by reprogramming the PC [ ] field (PC [ ]). However, since the protection context acts to enable or disable bus transfers, changes to the PC [ ] field must be controlled. That is, changes to the PC [ ] field must maintain the security of the system. Failing to maintain the same security level for updates of the PC [ ] field may allow unexpected security of the system or may circumvent changes in the protection context. Furthermore, changes to the protection context should result in minimal CPU overhead so that the protection context can change frequently without adversely affecting bus latency and performance. To enable frequent and secure changes to the protection context, each bus master may have an SMPU protection context mask field that identifies the available protection contexts that may be programmed to the bus master PC [ ] field. The following fields may provide the necessary security for the bus master protection context control:

MPU protection context-under control of bus master; with the same access restrictions as the MPU MMIO registers of the bus master.

Protection context mask-under the control of the secure CPU; with the same access restrictions as the SMPU MMIO registers.

The SMPU and PPU allow and restrict bus transfers based on protection context attributes assigned to the bus transfers. Thus, the protection context provides a protection step between the bus master and the SMPU and PPU protections. This embodiment allows a single bus master to identify multiple protection roles by reprogramming the PC [ ] field. Changes to the protection context limit CPU overhead because the SMPU and PPU do not need to be reprogrammed.

Special functions

It may be desirable to have a protection context with dedicated functionality. In one embodiment, a dedicated function may be assigned to protection context 0. Protection context 0 may have full access to all system components. It is important to establish a root of trust. Bus master 0 may be used or allowed to act as a "secure CPU" so that the secure CPU can execute both manufacturer code and customer code. The manufacturer code for the CPU may be stored in a Read Only Memory (ROM) or flash memory, such as ROM 164 and flash memory 162. Manufacturer ROM can be considered trustworthy (root of trust) and used to authenticate manufacturer flash memory. In various embodiments, manufacturer code may be used to provide flash programming, eFUSE programming, or other manufacturer-specific functionality.

The guest code executed by the secure CPU may be programmed in flash memory. The manufacturer may not have control over the code. Thus, the client code may not be assumed to be trustworthy. The execution of the customer code should not compromise the trusted quality of the manufacturer code.

Since trusted manufacturer code and untrusted client code may be executed by the same CPU, it may be necessary to provide a protection scheme that is not only based on the master-specific protection context. The special meaning assigned to protection context 0 may provide hardware support and control of the secure CPU protection context. Protection context 0 may provide unrestricted (unprotected) access to all memory and peripheral locations. In both cases, protection context 0 may be changed (or entered); thus, the use of protection context 0 may be limited.

In the first case, the secure CPU may be reset by executing a reset exception handler. In this case, the vector address may be provided from a specific ROM address. Because the ROM address is provided by the manufacturer and the vector address is provided from the ROM, the vector address may be trusted. Thus, the entry point of the handler may be trusted. After a secure CPU reset, all interrupts may be disabled, and CPU execution may be deterministic (i.e., determined entirely by the reset exception handler).

In the second case, a secure CPU exception or interrupt handler may be received. In this case, the handler vector address may be provided by a vector table having a configurable base address. When the secure CPU is reset, the base address may be set to a default value and the handler vector address may be written. Since the handler vector address is a ROM address, it can be trusted. However, the CPU can relocate from the vector table base to the SRAM address, and the handler vector address can be programmed to any value. The programmed values may result in the handler code being provided by the customer. In this case, the entry point of the handler may not be trusted. However, the protection context can be changed to 0 only when the secure CPU vector handler address is the same as the specific vector address. It is possible for the client code to relocate the vector table, but a change to protection context 0 requires that the vector address not be modified. The protection context is not changed to 0 when the system detects that the secure CPU vector address is different from the handler. If it is already 0, it may be changed back to the value before it was changed to 0.

Security for protecting context 0 is critical because protecting context 0 identifies trusted manufacturer code and provides unrestricted access (by SMPU and PPU).

Protection structure

The protection system of the present invention is intended to allow or limit bus transfers over a bus infrastructure (also referred to herein as a system bus architecture). The bus transfer of the protection system specifies a plurality of attributes including:

the address range accessed by the bus transfer;

read/write attributes;

an execution attribute;

user/privilege attributes;

secure/non-secure attributes; and

protection context attributes.

The bus transfer address range specifies the memory location or peripheral MMIO register to which the bus transfer is to be directed. From a structural point of view, there is little difference between memory protection and peripheral protection. However, implementation of security measures in a system benefits from the separation of memory protection and peripheral protection. In some embodiments, this separation is achieved by providing memory protection in the CPU subsystem and peripheral protection in the peripheral subsystem.

The read/write attributes may provide protection for memory or peripheral capabilities to be read or written to by a particular master. The execution attribute may be used to set access to code or data for a particular memory or peripheral. That is, in one embodiment, the bus transfers code that may seek to access a particular command or peripheral. In yet another embodiment, once executed, the bus transfer may seek to access the output of the code or command. The user/privilege attribute may be used to distinguish between OS or kernel access and task or thread access. The secure/non-secure attributes may be used to distinguish between secure and non-secure access. Finally, the protection context attribute may be used for soli for certain peripherals, groups of peripherals, or masters.

As described with respect to fig. 1, there may be a multi-level protection architecture including a Memory Protection Unit (MPU), a Shared Memory Protection Unit (SMPU), and a Peripheral Protection Unit (PPU). The MPU may be associated with a single master and may distinguish between user accesses and privileged accesses from a single associated master. The MPU may also perform access control for secure/non-secure attributes. Some masters may have built-in MPUs, such as bus masters 201.0 and 201.3 of fig. 1. For other bus masters, the MPUs may be implemented as part of the bus infrastructure, such as MPUs 203.1203.2 and 203.n of fig. 1.

The SMPU may be shared by all bus masters. In one embodiment, the SMPU may be shared by a subset of the bus masters, but not all bus masters of the system. The SMPU can distinguish between different protected contexts and between secure and non-secure accesses. The SMPU may also perform access control to user/privilege mode attributes. Since the SMPUs are shared, they are not implemented as part of a particular or single bus master. Rather, the SMPUs may be implemented as part of a system bus architecture so that they can be accessed by as many bus masters as they are needed.

The PPU may be implemented as part of a master/slave interface and as part of a peripheral group. Each bus master may access the peripheral subsystems through a master/slave interface (e.g., MS interface 231 of fig. 2) that includes a PPU. A peripheral group may be accessed by multiple masters through multiple master interfaces via a PPU dedicated to the peripheral group (e.g., peripheral group 251 of fig. 2). A peripheral group may consist of multiple peripheral units with a shared AHB-Lite bus infrastructure. The PPU may distinguish between different protection contexts, between secure and non-secure accesses, and between user mode and privileged mode accesses.

Each protection structure of the protection system may be defined by an address area and at least one access control attribute. The protection structure may be aligned with a given location of the memory space. Two registers, respectively assigned to the protection structure address and the attribute, may allow for protection of the protection structure.

The following resources may require protection implemented by the protection scheme: a peripheral device within the peripheral device group; and MMIO registers within the peripherals such as various IPC structures, data line or Direct Memory Access (DMA) controller channel structures, SMPU protected area structures, and PPU protected area structures. The resources may cover a fixed address range, or a range of addresses known at design time.

The protection units, such as the MPU, and SMPU, or PPU, may include multiple protection structures, and these multiple protection structures may be evaluated in descending order. The structure of higher indices may be prioritized over the structure of lower indices. For sufficient security, it should not be possible for a non-secure protected context to add a protection structure with a higher index than the protection structure providing secure access. In this case, it is possible to program the protection structure with the higher index to allow non-secure access. In a security system, a higher-index programmable protection structure is protected to allow only restricted access.

The PPU may have a relatively large number of protection regions compared to the MPU and SMPU. Resources that may need protection provided by the PPU may include all peripherals in the peripheral group or a group of MMIO registers in the peripherals. MMIO registers within the peripheral device may include various IPC structures, DMA controller channel structures, SMPU protected area structures, and PPU protected area structures.

The PPU protection structure may include a resource with a known address range for which design-time configuration requiring protection of the address range may be implemented. For resources with unknown address ranges, such as resources identified by device usage, full programmability of the address ranges of the protection zones may be used.

Access control Properties

As described above, the access attribute may specify access control to the region. A region, or address region, may be defined by a base address, a size of the region, and a sub-region within the region that may be enabled or disabled. In one embodiment, there may be eight sub-regions. However, more or fewer sub-regions may be implemented.

Access control to a region may be applied to all sub-regions within the region. Access control is performed by evaluating the access attributes of the transmission. In various embodiments, the following access control fields may be implemented:

control of read access in user mode;

control of write access in user mode;

control of execution access in user mode;

control of read access in privileged mode;

control of write access in privileged mode;

control of execution access in privileged mode;

control over secure access;

control of individual protection contexts, which may exist only in SMPU and PPU; and

control of "matching" and "access evaluation process", which may exist only in the SMPU and PPU.

For example, using the access control fields described above, protection context 2 may be defined for read and write operations in privileged mode for non-secure accesses, with the following settings:

three separate access evaluation sub-processes can be distinguished. The first sub-process may evaluate access based on read/write, execute, and user access/privilege access attributes. The second sub-process may evaluate access based on the secure/non-secure attributes. A third sub-process may evaluate access based on protection context attributes (used by the SMPU and PPU).

If all access evaluations are successful, then access may be allowed. If any of the access evaluations are unsuccessful, access may be prohibited. The denial of access may be stored in a failed MMIO register, such as failed MMIO register 180 of fig. 1.

Matching

The matching of bus transfer addresses and the evaluation of accesses by bus transfers can be performed in two separate processes. To match, the first process may identify transport addresses contained within the address range for each protection structure. The first process may then determine whether the appropriate bit corresponding to the given protection context is a "1". This will identify matching regions. For access evaluation, the second process may evaluate the bus transfer attribute against the access control attribute.

There may be a plurality of protection structures in the protection unit. In one embodiment, the protection unit may evaluate the protection structures in descending order. The structure of the higher index may be prioritized over the structure of the lower index. The structure of the higher index may have more control or access than the structure of the lower index, so access to the structure of the higher index may be evaluated first to prevent the structure of the lower index (where it should not be allowed) from allowing access. Not following this paradigm, a non-secure context may be allowed to add a protection structure with a higher index than the protection structure that provides secure access. In other words, the protection structure with the higher index may be programmed incorrectly to allow non-secure access.

Protection of a protective structure

The protection structure may be set once at boot time or may be dynamically changed during device execution. In one embodiment, the CPU RTOS may change the MPU MMIO settings of the CPU. As described above, the secure CPU may change SMPU and PPU MMIO settings. Since the MPU, SMPU, and PPU MMIO registers are MMIO registers similar to other peripheral MMIO registers, they can be similarly changed. Furthermore, the address range of the protection structure may include the protection structure itself. Using this synonymous iteration, it is possible to use a protection scheme to protect the protection structure itself; thus, the protection scheme is more difficult to circumvent.

FIG. 4 shows a scheme 400 for protecting a peripheral device (A) 410 according to one embodiment. Peripheral A may be shared by two protection contexts PC [1]401 and PC [2] 402. Peripheral a410 may have an address region 415. A42 byte PPU protection structure 422 at address 0x4000. Protection structure 422 may be one of several protection structures associated with PC [1]401 and PC [2] 402. The protection structures may be grouped to be co-located with PC [1]401 and PC [2]402 in PPU protection structures 420.1 and 420.2, respectively. Ownership of peripheral A410 may be transferred from PC [1]401 to PC [2] by PC [1]401 reprogramming the protection control attributes of the protection fabric to align with PC [2] 402. This is shown in FIG. 4 as PC [1]401 reprogramming PPU protection structure 422 so that PC [2] can access peripheral A410. Similarly, when PC [2]402 "owns" peripheral A410, it can assign peripheral A410 to PC [1]401.

Fig. 5 illustrates a scheme 500 for protecting peripheral device (B) 510 that can prevent a protection context that does not own peripheral device B510 from assigning ownership to itself by reprogramming the protection context control attributes. Two 32-byte PPU protection structures 515 and 517 at addresses 0xt4000 (up to 0xt4000 001f) and 0xt4000. Protection structure 517 may be used to protect protection structure 515 and itself. Protection structure 515 may be a slave protection structure and protection structure 517 may be a master protection structure. The master and slave protection structures may be protection pairs 513.

In the PPU, protection structure 520 may correspond to protection structures 515 and 517 of peripheral B510. The slave guard structure 522 may be aligned with the guard structure 515. The primary protection structure 524 may be aligned with the protection structure 517. Initially, the PPU protection structure 520.0 may have a slave protection structure 522, where ownership of peripheral B is assigned to PC [1]501 and a master protection structure 524 is assigned to PC [1]. In a first step, PC [1]501 may change ownership of peripheral B510 to PC [2]502, such that PPU protection structure 520.1 may have slave protection structure 522, where ownership of peripheral B is assigned to PC [2]502 and master protection structure 524 is assigned to PC [1]501. In a second step, PC [1]501 may change the master/slave ownership of peripheral B510 to PC [2]502, such that PPU protection structure 520.2 may have slave protection structure 522, where ownership of peripheral B510 is assigned to PC [2]502 and master protection structure 524 is assigned to PC [2]502.

Changing ownership from PC [2]502 to PC [1]501 may follow a similar pattern. In a first step, PC [2]502 may change ownership of peripheral B510 to PC [1]501, such that PPU protection structure 520.3 may have slave protection structure 522, where ownership of peripheral B is assigned to PC [1]501 and master protection structure 524 is assigned to PC [2]502. In a second step, PC [2]502 may change the master/slave ownership of peripheral B510 to PC [1]501, such that PPU protection structure 520.0 may have slave protection structure 522, where ownership of peripheral B510 is assigned to PC [1]501 and master protection structure 524 is assigned to PC [1]501.

In other words, the first step changes the peripheral ownership to other protection contexts, and the second step changes the capabilities to change the master/slave ownership to other protection contexts. This scheme can prevent a protection context that does not own a peripheral from assigning ownership to itself by reprogramming the protection context control attributes.

For the solution shown in fig. 5, it may be preferred that the protective structures are adjacent. For example, the PPU and SMPU protection structures may be aligned in pairs. The first protection architecture may protect resources (i.e., peripherals) and the second protection architecture may protect protection architectures. In various other embodiments of the scheme shown in fig. 5, peripheral ownership may be shared by more than two protection contexts, while the ability to change peripheral ownership may be limited to a single protection context.

In the description above, numerous details are set forth. However, it will be apparent to one having ordinary skill in the art having had the benefit of the present disclosure that the embodiments of the invention may be practiced without these specific details. In some instances, well-known structures and devices are shown in block diagram form, rather than in detail, in order to avoid obscuring the present description.

Some portions of the detailed description are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. The steps are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the above discussion, it is appreciated that throughout the description, discussions utilizing terms such as "encrypting," "decrypting," "storing," "providing," "originating," "obtaining," "receiving," "authenticating," "deleting," "executing," "requesting," "communicating," "initializing," or the like, refer to the action and processes of a computing system, or similar electronic computing device, that manipulates and transforms data represented as physical (e.g., electronic) quantities within the computing system's registers and memories into other data similarly represented as physical quantities within the computing system memories or registers or other such information storage, conversion or display devices.

The words "example" or "exemplary" are used herein to mean serving as an example, instance, or illustration. Any aspect or design described herein as "exemplary" or "exemplary" is not necessarily to be construed as preferred or advantageous over other aspects or designs. Moreover, use of the word "example" or "exemplary" is intended to present concepts in a concrete fashion. As used in this application, the term "or" is intended to mean an inclusive "or" rather than an exclusive "or". That is, unless specified otherwise, or clear from context, "X includes a or B" is intended to mean any of the naturally-included permutations. That is, if X includes A; x comprises B; or X includes both a and B, then "X includes a or B" is satisfied under any of the foregoing examples. In addition, the articles "a" and "an" as used in this application and the appended claims should generally be construed to mean "one or more" unless specified otherwise or clear from context to be directed to a singular form. Furthermore, the use of the terms "an embodiment" or "one embodiment" or "an implementation" or "one implementation" throughout is not intended to mean the same embodiment or implementation unless described as such.

The specific commands or messages associated with the above protocols are intended to be illustrative only. Those of ordinary skill in the art will understand that commands of different specific wording, but similar functionality, may be used and still fall within the scope of the above description.

Embodiments described herein may also relate to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a non-transitory computer readable storage medium, such as, but is not limited to, any type of disk including floppy disks, optical disks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs), random Access Memories (RAMs), EPROMs, EEPROMs, magnetic or optical cards, flash memory, or any type of media suitable for storing electronic instructions. The term "computer-readable storage medium" should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term "computer-readable medium" shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present embodiments. The term "computer-readable storage medium" shall accordingly be taken to include, but not be limited to, solid-state memories, optical media, magnetic media, any medium that is capable of storing a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present embodiments.

The algorithms and displays presented or referenced herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will appear from the description below. In addition, the present embodiments are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of the embodiments as described herein.

The above description sets forth numerous specific details such as examples of specific systems, components, methods, etc., in order to provide a thorough understanding of several embodiments of the present invention. It will be apparent, however, to one skilled in the art that at least some embodiments of the invention may be practiced without these specific details. In other instances, well-known components or methods are not described in detail or are presented in simple block diagram form in order to avoid unnecessarily obscuring the present invention. Accordingly, the specific details set forth above are merely exemplary. Particular embodiments may differ from these exemplary details and still be considered within the scope of the present invention.

It is to be understood that the above description is intended to be illustrative, and not restrictive. Many other embodiments will be apparent to those of skill in the art upon reading and understanding the above description. The scope of the invention should, therefore, be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.

Claims

1. A system, comprising:

a first Central Processing Unit (CPU) configurable to operate in a plurality of protection contexts; and

a peripheral subsystem, the peripheral subsystem comprising:

at least one peripheral module accessible by the first CPU when the first CPU is configured with a first protection context of the plurality of protection contexts and inaccessible by the first CPU when the first CPU is configured with a second protection context of the plurality of protection contexts; and

at least one peripheral protection unit, wherein the at least one peripheral protection unit distinguishes between:

the first protection context and the second protection context of the plurality of protection contexts,

secure access and non-secure access, an

User mode access is relative to privileged mode access.

2. The system of claim 1, further comprising a CPU subsystem, the CPU subsystem comprising:

the first CPU;

at least one memory protection unit; and

at least one shared memory protection unit.

3. The system of claim 2, wherein the at least one memory protection unit distinguishes between user accesses and privileged accesses from a single bus master.

4. The system of claim 2, wherein the at least one shared memory protection unit distinguishes the first and second protected contexts of the plurality of protected contexts and distinguishes secure and non-secure access by the first CPU.

5. The system of claim 1, wherein access to the peripheral module is controlled by a value of a pair of vectors, a first vector of the pair of vectors to control read access to the peripheral module and a second vector of the pair of vectors to control write access to the first vector of the pair of vectors.

6. The system of claim 1, wherein a first CPU operation that is transitioned from the first protection context to the second protection context is gated by an interrupt factor associated with the second protection context.

7. The system of claim 1, wherein the peripheral module is a memory.

8. The system of claim 1, further comprising a second CPU configurable to operate in at least one of the plurality of protection contexts.

9. A bus infrastructure comprising a plurality of protection fabrics, the plurality of protection fabrics comprising:

a Memory Protection Unit (MPU) assigned to a single bus master, the MPU to distinguish between user accesses and privileged accesses made from the bus master;

a Shared Memory Protection Unit (SMPU) assigned to a plurality of bus masters, the SMPU to distinguish between different protection contexts and to distinguish between secure and non-secure accesses to memory; and

a Peripheral Protection Unit (PPU) assigned with a peripheral group, the PPU to distinguish between secure and non-secure access to the peripheral group.

10. The bus infrastructure of claim 9, wherein the PPU distinguishes between secure and non-secure accesses to the set of peripherals by validating a user mode and a privileged mode, wherein accesses allowed in user mode are different from accesses allowed in privileged mode.

11. The bus infrastructure of claim 9, wherein each of the plurality of protection fabrics is defined by:

an address area; and

an access control attribute, wherein the access control attribute specifies access control to a memory location.

12. The bus infrastructure of claim 9, wherein the PPU comprises a plurality of protection zones, including at least one of:

all peripheral devices in the peripheral device group; and

a subset of peripherals of the set of peripherals includes an individual inter-processor communication (IPC) fabric, a DMA controller channel fabric, an SMPU protected area fabric, or a PPU protected area fabric.

13. A bus infrastructure as in claim 9, where the bus master is a Central Processing Unit (CPU) operating in a first protection context and a second protection context.

14. A bus infrastructure as defined in claim 13, wherein the bus master accesses the set of peripherals when the CPU operates in the first protection context and the bus master is prohibited from accessing the set of peripherals when the CPU operates in the second protection context.

15. The bus infrastructure of claim 9, wherein access to the set of peripherals is controlled by values of a pair of vectors of the PPU, a first vector of the pair of vectors to control read access to the set of peripherals and a second vector of the pair of vectors to control write access to the first vector of the pair of vectors.

16. A method for controlling access to a peripheral module, the method comprising:

comparing a first protection context of a plurality of protection contexts of a Central Processing Unit (CPU) with an allowed protection context of a first peripheral module;

allowing the CPU to access the first peripheral module if the first protection context of the CPU matches the allowed protection context of the first peripheral module;

changing a protection context of the CPU from the first protection context to a second protection context;

if the second protection context does not match the allowed protection context of the first peripheral module, then prohibiting the CPU from accessing the first peripheral module;

allowing the CPU to access a second peripheral module if the second protection context of the CPU matches an allowed protection context of the second peripheral module, wherein the first protection context is different from the second protection context; and

distinguished by at least one peripheral protection unit:

secure access and non-secure access, an

User mode access is relative to privileged mode access.

17. The method of claim 16, wherein access to the peripheral modules is defined by a pair of vectors for each peripheral module, and wherein the pair of vectors includes a first vector of the pair of vectors to control read access to the peripheral module and a second vector of the pair of vectors to control write access to the first vector of the pair of vectors.