Patent Application
20140223052
Various processes are governed by international standards relating to safety and risk reduction. For example, IEC 61508 addresses functional safety of electrical, electronic, and programmable electronic devices, such as microcontrollers or other computers used to control industrial or other safety critical processes. IEC 61508 defines Safety Integrity Levels (SIL) based on a probabilistic analysis of a particular application. To achieve a given SIL, the application, including constituent components, must meet targets for the maximum probability of “dangerous failure” and a minimum “safe failure fraction.” The concept of “dangerous failure” is defined on an application-specific basis, but is based on requirement constraints that are verified for their integrity during the development of the safety critical application. The “safe failure fraction” determines capability of the system to manage dangerous failures and compares the likelihood of safe and detected failures with the likelihood of dangerous, undetected failures. Ultimately, an electronic device's certification to a particular SIL requires that the electronic device provide a certain level of detection of and resilience to failures as well as enable the safety critical application to transition to a safe state after a failure.
Another functional safety standard is ISO 26262, which addresses the functional safety of road vehicles such as automobiles. ISO 26262 aims to address possible hazards caused by malfunctioning behavior of automotive electronic and electrical systems. Similar to SILs defined by IEC 61508, ISO 26262 provides an automotive-specific risk-based approach to determine risk classes referred to as Automotive Safety Integrity Levels (ASIL). ASILs are used to specify a particular product's ability to achieve acceptable safety goals.
An electronic device that controls a process—industrial, automotive, or otherwise—may be used to perform multiple functions, some of which are “safety functions” while others are “non-safety functions.” A safety function is a function whose operation impacts the safety of the process; for example, a closed-loop control system that drives an electric motor used for power steering is a safety function. A non-safety function is a function whose operation does not impact the safety of the process; for example, debug functionality built into the electronic device that is used to develop software for the control functions, but is not used when the electronic device is integrated into a vehicle, is a non-safety function.
The problems noted above are solved in large part by a system including a bus slave coupled to a plurality of bus masters via one or more interconnects. The system also includes a memory protection unit (MPU) associated with the bus slave, the MPU having a set of access permissions that grants access to the bus slave from a first bus master and denies access to the bus slave from a second bus master. The MPU generates an error response as result of a transaction generated by a task on the second bus master attempting to access the bus slave.
Other embodiments of the present disclosure are directed to a method including receiving a transaction from a bus master directed at a bus slave, determining whether to grant or deny the transaction access to the bus slave, and generating an error response as a result of determining to deny access to the transaction.
Still other embodiments of the present disclosure are directed to an electronic device including a bus slave that is memory or a peripheral and first and second bus masters to execute one or more tasks. Each task generates transactions directed at the bus slave. The device also includes an interconnect to couple the bus slave to the bus master and a memory protection unit (MPU) associated with the bus slave. The MPU has a set of access permissions that grants access to the bus slave from the first bus master and denies access to the bus slave from the second bus master. The MPU generates an error response as result of a transaction generated by a task on the second bus master attempting to access the bus slave.
For a detailed description of exemplary embodiments of the invention, reference will now be made to the accompanying drawings in which:
Certain terms are used throughout the following description and claims to refer to particular system components. As one skilled in the art will appreciate, companies may refer to a component by different names. This document does not intend to distinguish between components that differ in name but not function. In the following discussion and in the claims, the terms “including” and “comprising” are used in an open-ended fashion, and thus should be interpreted to mean “including, but not limited to . . . .” Also, the term “couple” or “couples” is intended to mean either an indirect or direct electrical connection. Thus, if a first device couples to a second device, that connection may be through a direct electrical connection, or through an indirect electrical connection via other devices and connections.
As used herein, the term “transaction” refers to a request to read from/write to memory or read from/write to another piece of logic or register.
As used herein, the term “bus master” refers to a piece of logic that initiates a transaction.
As used herein, the term “bus slave” refers to a component that receives a transaction; for example, a memory region or a peripheral may be a bus slave.
As used herein, the term “interconnect” refers to a component that distributes a transaction, for example between bus masters and bus slaves.
The following discussion is directed to various embodiments of the invention. Although one or more of these embodiments may be preferred, the embodiments disclosed should not be interpreted, or otherwise used, as limiting the scope of the disclosure, including the claims. In addition, one skilled in the art will understand that the following description has broad application, and the discussion of any embodiment is meant only to be exemplary of that embodiment, and not intended to intimate that the scope of the disclosure, including the claims, is limited to that embodiment.
Safety and non-safety function may be implemented, for example, on a system on a chip (SOC) with one or more processor cores and a memory, which may be shared among processor cores. In theory, a highest level of safety is achieved when a separate SOC carries out each of the various functions of the electronic device. In this way, the operation of a particular function cannot be impaired or corrupted by other functions since a bus master that implements a particular function cannot access any bus slave(s) other than its own. However, such an approach is cost-prohibitive.
To reduce the cost of such electronic devices, safety functions may be implemented alongside non-safety functions, for example with multiple functions carried out by a single SOC. However, to maintain an appropriate SIL, certain functions should be prevented from interfering with other functions (e.g., a function should be prevented from accessing an address region memory that is not allocated to that function or by sending a transaction to a peripheral that is not allocated to that function).
Safety functions may be associated with one of a plurality of SILs. For example, a safety function with a SIL of 3 may require a high level of safety assurance while a function with a SIL of 2 or lower requires a lower level of safety assurance, while still requiring more safety assurance than a non-safety function. That is, the function with a SIL of 3 presents a greater degree of risk relative to the function with a SIL of 2 (or lower) and as such requires greater risk reduction measures. As a result, multiple safety functions may have SILs that are independent of each other. Various standards require that functions having different SIL ratings should not interfere with one another. Similarly a non-safety critical task must not interfere with a safety critical task. Thus, while a non-safety function should be separated such that the non-safety function does not corrupt the safety function(s), a higher-SIL safety function (i.e., numerically greater) should also be separated such that the lower-SIL safety function does not corrupt the higher-SIL safety function.
The SOC architecture 100 also comprises an interconnect 108 that couples the bus masters 102, 104, 106 to exemplary bus slaves, such as random access memory (RAM) 110 and read-only memory (ROM) 112. Additionally, the interconnect 108 may couple the bus masters 102, 104, 106 to peripherals 116a-116n (e.g., a serial port, a general purpose input/output port, or a timer). In some cases, a peripheral interconnect 114 is inserted between the interconnect 108 and the peripherals 116a-116n to further facilitate routing of transactions to the appropriate peripheral 116a-116n.
The SOC architecture 100 is exemplary, and it should be appreciated that multiple instances of various bus masters 102, 104, 106 may exist within an application-specific SOC. Regardless of the particular implementation, maintaining freedom from interference between various tasks at the bus slave level is important to assure that the device that carries out the various tasks achieves an acceptable level of risk. Additionally, as shown in
Turning to
Information contained in the instruction fetch and/or data access request may be used to determine whether to grant or deny access to a bus slave. Additionally, the determination by the MPU 202 of whether to grant or deny access to a bus slave may be based on one or a combination of a number of factors.
In some cases, transactions may be isolated based on the address of memory to which the transaction is directed. For example, certain addresses may be protected while other addresses are non-protected. A transaction originating from a safety function may be granted access by the MPU 202 to an address that is either protected or non-protected, while a transaction originating from a non-safety function is granted access to an address that is non-protected and denied access to an address that is protected. Additionally, in certain embodiments there may be multiple levels of address protection and a higher-level safety function is granted access to any address, while a lower-level safety function is only granted access to certain levels of protected addresses and a non-safety function is only granted access to non-protected addresses.
In other cases, transactions may be isolated based on a privilege level associated with the function or task that generates the transaction. For example, certain functions may be “privileged” and other functions may be “non-privileged.” Transactions originating from a privileged function may be granted access by the MPU 202 to bus slaves that require a privileged level and transactions originating from a non-privileged function may be denied access to bus slaves that require a privileged level. Similarly, transactions may be isolated based on a security level where some functions comprise trusted code while other functions comprise non-trusted code. Transactions originating from trusted code are granted access by the MPU 202 to secure bus slaves and transactions originating from non-trusted code are denied access to secure bus slaves.
Additionally, transactions may be isolated based on a task identification (ID) associated with the function or task that generates the transaction. For example, the bus master or a CPU 102 may assign a task ID to each task that is running, which can be used by the MPU 202 to discriminate permissions on a per task basis. Alternately, transactions may be isolated based on whether the transaction originated from a function or task executed by a bus master that is a “functional unit” or executed by a bus master that is a “debug unit.” The MPU 202 may grant access to certain bus slaves for tasks originating from a functional unit and deny access to those bus slaves for tasks originating from a debug unit.
Referring to
In the event of an attempted violation of access rules implemented by the MPU 202, various actions may be taken. For example, the MPU 202 may report the attempted access violation to a system-level monitoring task executing on the CPU 102. In some cases, the MPU 202 blocks the transaction from occurring, while in other cases the MPU 202 tags the transaction as having an error. Further, in security-sensitive applications where a transaction tagged as having an error may provide useful information to a malicious entity attempting to gain access to secure memory, a response may be generated that mimics a normal response, but which contains false data.
In the above examples, a MPU 202, 302 facilitates protection of certain regions of memory and/or certain peripherals by limiting access by lower-level or non-safety functions where appropriate. As a result, an acceptable level of safety is achieved by the overall device on which the SOC architecture 100 is implemented while reducing the cost of the device by implementing many functions on a single SOC.
In the event of an attempted violation of access rules implemented by the MPU 202, various actions may be taken. For example, the MPU 202 may report the attempted access violation to a system-level monitoring task executing on the CPU 102. In some cases, the MPU 202 blocks the transaction from occurring, while in other cases the MPU 202 tags the transaction as having an error. Further, in security-sensitive applications where a transaction tagged as having an error may provide useful information to a malicious entity attempting to gain access to secure memory, a response may be generated that mimics a normal response, but which contains false data.
In accordance with various embodiments, a non-programmable bus master, such as the DMA controller 104, may implement multiple tasks to perform various functions. Unlike a bus master such as the CPU 102, which may reconfigure its MPU 202 with software executing tasks on the CPU 102, the DMA controller 104 does not execute software to optimize its performance during DMA operations, and thus is non-programmable.
Turning to
In some embodiments, the DMA controller 104 implements automated task-switching by automatically changing the configuration of the integrated MPU 402 when the DMA controller 104 switches tasks. However, in other embodiments, the DMA controller 104 may provide task identification (ID) to the MPU 402 and, as a result of receiving a different task ID, the MPU 402 changes its configuration. This allows the MPU 402 to be less closely integrated to the DMA controller 104.
As explained above, for a transaction generated by one of the tasks implemented by the DMA controller 104, the MPU 402 determines whether to grant or deny access to a bus slave for that transaction. This determination may be based on the address of memory to which the transaction is directed, a privilege level of the transaction or the task that generates the transaction, or a security level of the task that generates the transaction.
Thus, the DMA controller 104 enables automated task-switching for the MPU 402 configurations to apply different access permissions to each task executed by the DMA controller 104. As such, memory protection is enabled, achieving an acceptable level of risk, even in systems where a non-programmable bus master such as the DMA controller 104 implements multiple tasks, which include safety and non-safety functions.
In accordance with various other embodiments, a bus master, such as the CPU 102, may implement multiple instances of virtualized hardware to perform various functions. Turning to
In accordance with various embodiments, a virtual CPU ID is associated with each virtual CPU 502, 504 simulated on the physical CPU 102. Additionally, a virtual task ID may be associated with each virtual task running on the virtual CPUs 502, 504. An MPU 506 associated with a bus master that implements virtualized hardware (e.g., the physical CPU 102 implementing one or more virtual CPUs 502, 504) grants or denies access to a peripheral, memory region, or other bus slave based on the virtual CPU ID and/or the virtual task ID. As such, memory protection is enabled, achieving an acceptable level of risk, even in systems where safety and non-safety functions are implemented in virtualized hardware.
Further, the physical CPU 102 may execute tasks (e.g., task E) independently of tasks (e.g., tasks A-D) executed by the virtual CPUs 502, 504. In such cases, the MPU 506 does not only grant or deny access based on virtual CPU ID or virtual task ID, but rather grants and denies access generally based on virtual CPU ID and CPU ID or virtual task ID and task ID. In this way, the MPU 506 applies an equal permission scheme to CPUs, regardless of whether they are virtual CPUs 502, 504 or a physical CPU 102. Similarly, the MPU 506 applies an equal permission scheme to tasks, regardless of whether they are tasks implemented by virtual hardware (i.e., tasks A-D implemented by virtual CPUs 502, 504) or tasks implemented by physical hardware (i.e., task E implemented by CPU 102).
Turning now to
In a second example, a MPU 606 is integrated into the interconnect 108. In this context, being integrated refers to an interconnect 108 design in which the MPU 606 is included directly into the datapath at the time of design of the interconnect 108 rather than added to the datapath design after the interconnect 108 has been designed. As a result, the MPU 606 may provide additional capability relative to the MPU 604, such as reduced latency (i.e., improved overall performance), reduced power consumption, reduced physical size, and improved response time.
In a third example, a MPU 608 is integrated into the bus slave 602 itself. Similar to being integrated into the interconnect 108, in this context, integrated refers to the fact that the MPU 608 is part of the base design of the bus slave 602 itself. Thus, the MPU 608 may be optimized for the behavior of the particular bus slave 602. As a result, the MPU 608 may be optimized in particular for the bus slave 602 to which it is integrated. For example, optimization such as reduced latency, reduced power consumption, reduced physical size, and improved response time are possible.
Regardless of the particular location and implementation of the slave-based MPU 604, 606, 608, the MPU 604, 606, 608 includes a set of access permissions that grants access to the bus slave 602 when certain conditions are met and denies access to the bus slave 602 when at least one of those conditions are not met. More particularly, granting and denying access is often determined on a transaction by transaction basis, where the transaction is generated by a task executing on a bus master. For example, the MPU 604, 606, 608 may deny access to the bus slave 602 based on an address to which the transaction is directed, a privilege level associated with the task that generated the transaction, a security level associated with the task that generated the transaction, or whether the transaction was generated by a functional unit of the bus master or a debug unit of the bus master.
In some embodiments, the MPU 604, 606, 608 grants or denies access to the bus slave 602 based on the bus master that generated the transaction. For example, transactions generated by tasks on a first bus master may be generally granted to access the bus slave 602 while transactions generated by tasks on a second bus master are denied access to the bus slave 602. In this way, while MPUs associated with bus masters (e.g., as shown in
In the event of an attempted violation of access rules implemented by the MPU 604, 606, 608, various actions may be taken. For example, the MPU 604, 606, 608 may report the attempted access violation to a system-level monitoring task executing on the CPU 102. In some cases, the MPU 604, 606, 608 blocks the transaction from occurring, while in other cases the MPU 604, 606, 608 tags the transaction as having an error and generates a bus error response via the interconnect 108. Further, in security-sensitive applications where a transaction tagged as having an error may provide useful information to a malicious entity attempting to gain access to secure memory (e.g., bus slave 602), a response may be generated that mimics a normal response, but which contains false data.
Thus, in some embodiments a system-wide memory protection scheme is disclosed, in which MPUs are implemented at both the bus master level and the bus slave level. As a result, an acceptable level of safety is achieved by the overall device on which the system-wide memory protection scheme (e.g., including SOC architecture 100) is implemented while reducing the cost of the device by implementing many functions on a single SOC.
The method 700 continues in block 704 with the MPU determining whether to grant or deny the transaction access to the bus slave. If it is determined to deny the transaction access to the bus slave in block 704, the method 700 continues in block 706 with generating an error response. The error response may include a bus error response (e.g., an error message is transmitted via the interconnect), transmission of false information intended to appear as a normal response, or blocking the transaction from accessing the bus slave. Denial of a transaction, and thus subsequent generation of an error response, may occur as a result of an identification of the bus master that generated the transaction, an address to which the transaction is directed, a privilege or security level associated with the task that generated the transaction, or whether the transaction was generated by a functional unit of the bus master or a debug unit of the bus master.
As explained above, in some embodiments a system-wide memory protection scheme is disclosed, in which MPUs are implemented at both the bus master level and the bus slave level. In such embodiments, the method 700 may comprise additional steps not shown in
As another example, the method 700 may further comprise a MPU associated with a virtual CPU (implemented on a physical CPU) receiving a transaction from the virtual CPU directed at a bus slave. The transaction may be associated with a virtual CPU ID or a virtual task ID. The MPU determines whether to grant or deny access to the bus slave based on the virtual CPU ID or the virtual task ID. In either case, the virtual CPU ID or virtual task ID is different than an ID of the physical CPU on which the virtual CPU is implemented or an ID of a task executed on the physical CPU, respectively.
As a result, the method 700 enables bus slave-based memory protection, where access to a bus slave is determined at least party based on the bus master from which a transaction originates. Additionally, the method 700 facilitates a system-wide memory protection scheme, in which MPUs are implemented at both the bus master level and the bus slave level. As a result, an acceptable level of safety is achieved by the overall device on which the system-wide memory protection scheme (e.g., including SOC architecture 100) is implemented while reducing the cost of the device by implementing many functions on a single SOC.
The above discussion is meant to be illustrative of the principles and various embodiments of the present invention. Numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to embrace all such variations and modifications.
The present application claims priority to U.S. Provisional Patent Application No. 61/762,212, filed on Feb. 7, 2013 (Attorney Docket No. TI-73288PS); which is hereby incorporated herein by reference. The present application is also related to co-pending U.S. patent application Ser. No. 14/015,561 (Attorney Docket No. 1962-85400, Titled “System And Method For Per-Task Memory Protection For A Non-Programmable Bus Master), which is hereby incorporated herein by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 61762212 | Feb 2013 | US |
