Data processing system with secure memory sharing

Abstract

The invention relates to a data processing system with secure memory sharing. A trusted execution environment (TEE) includes a first requester, a first local interconnect, an access controller, and a first memory encryption circuit, and the access controller allows or denies access requests to a shared memory external to the TEE. A normal execution environment (NEE) communicates with the TEE via a set of address lines and a set of data lines, and includes a second requester and a second local interconnect. The first memory encryption circuit encrypts write data before the TEE provides the write data corresponding to an access-allowed request to the shared memory generated by only one of the first requester and the second requester to store in the shared memory. Any write data corresponding to an allowed access request to the shared memory generated by the other of the first requester and the second requester is provided as unencrypted write data to be stored in the shared memory.

Description

Technical Field

[0001] The present disclosure relates generally to data processing systems, and more particularly to secure memory sharing within a data processing system. Background Art

[0002] As data processing systems become more complex, it becomes increasingly challenging to implement robust security protection, especially when limited by constraints such as power consumption and die size. In order to provide strong protection, some currently available data processing systems include a secure subsystem or secure enclave that performs security operations for the data processing system. Typically, such a secure subsystem includes an internal secure memory for performing the required security operations. However, as the complexity and number of security operations increase, the memory size required for such internal secure memory also increases, thereby increasing the overall die size, for example, in the case of a system on a chip (SoC). However, the increase in die size has a negative impact on the power consumption and cost of the SoC. Summary of the invention

[0003] The following are various embodiments of the present invention. It should be noted that any of the following aspects can be used in any combination with each other and in combination with any disclosed embodiment.

[0004] In one embodiment, a data processing system includes: a shared memory; a trusted execution environment (TEE), the TEE including a first requester, a first local interconnect, an access controller, and a first memory encryption circuit, the first requester and the access controller are coupled to the first local interconnect, and the access controller is configured to allow or deny access requests to the shared memory, wherein the shared memory is external to the TEE; and a normal execution environment (NEE), the NEE is configured to communicate with the TEE via a set of address lines and a set of data lines, the NEE includes a second requester and a second local interconnect, the second local interconnect is coupled to the second requester, the set of address lines and the set of data lines. In this embodiment, the first memory encryption circuit is configured to encrypt the write data corresponding to the access permission request to the shared memory generated by only one of the first requester and the second requester before the TEE provides the write data for storage in the shared memory, and any write data corresponding to the access permission request to the shared memory generated by the other of the first requester and the second requester is provided as unencrypted write data for storage in the shared memory. In one aspect, the first memory encryption circuit is further configured to decrypt the read data from the shared memory corresponding to the access permission request generated by only one of the first requester and the second requester before the TEE returns the read data to the only one of the first requester and the second requester, wherein any read data corresponding to the access permission request for the shared memory generated by the other of the first requester and the second requester is returned to the other of the first requester and the second requester as plaintext read data without any encryption or decryption. In another aspect, the access request to the shared memory includes a write access request and a read access request. In another aspect, the access request includes a corresponding access address and corresponding control information, wherein the access controller is configured to allow or deny the access request to the shared memory based on the corresponding control information. In another aspect, the corresponding control information includes a security identifier that identifies which requester within the data processing system generated the received access request. In another aspect of the above embodiment, the first memory encryption circuit is configured to encrypt the write data before the TEE provides the write data corresponding to the access permission request for the shared memory generated by the first requester for storage in the shared memory, wherein any write data corresponding to the access permission request for the shared memory generated by the second requester is provided as unencrypted write data for storage in the shared memory.In yet another aspect, the first memory encryption circuit is configured to encrypt the write data before the TEE provides the write data corresponding to the access permission request to the shared memory generated by the second requestor for storage in the shared memory, wherein any write data corresponding to the access permission request to the shared memory generated by the first requestor is provided as unencrypted write data for storage in the shared memory. In another aspect, the TEE further includes a second memory encryption circuit, and the data processing system further includes a second NEE, the second NEE being configured to communicate with the TEE via a second set of address lines and a second set of data lines, wherein the second memory encryption circuit is configured to encrypt the write data before the TEE provides the write data corresponding to the access permission request to the shared memory generated by the requestor of the second NEE for storage in the shared memory. In another aspect, the TEE further includes a set of memory encryption circuits, and the data processing system further includes a plurality of NEEs, including the NEEs, each NEE being configured to communicate with the TEE via a corresponding set of address lines and a corresponding set of data lines, wherein each memory encryption circuit in the set of memory encryption circuits is configured to encrypt the received write data before the TEE provides the received write data corresponding to the access permission request to the shared memory generated by the requestor within the corresponding NEE in the plurality of NEEs for storage in the shared memory. In yet another aspect, each memory encryption circuit in the set of memory encryption circuits is configured to encrypt the received write data corresponding to the access permission request to the shared memory generated by the requestor within the plurality of corresponding NEEs in the plurality of NEEs. In yet another aspect of the above embodiment, the data processing system is further characterized as a system on chip (SoC).

[0005] Another embodiment includes a method in a data processing system, wherein the data processing system includes a trusted execution environment (TEE), a normal execution environment (NEE), and a shared memory external to the TEE, wherein the TEE includes a memory encryption circuit corresponding to only one of the TEE and the NEE. The method includes: receiving, by an access controller within the TEE configured to control access to the shared memory, a write access request generated by a requestor located within the TEE or the NEE; and in response to the access controller allowing the requested write access to the shared memory, providing corresponding write data to the shared memory, wherein if the requestor is located in only one of the TEE and the NEE, the write data is encrypted by the memory encryption circuit before being provided to the shared memory, otherwise, the write data is provided to the shared memory as unencrypted plaintext data. In one aspect of the other embodiment, write data from only one of the TEE and the NEE is encrypted before being stored in the shared memory, while write data from the other of the TEE and the NEE is stored in the shared memory only as unencrypted plaintext data. In another embodiment, the method further includes: receiving, by the access controller, a read access request generated by a second requestor located within the TEE or the NEE; in response to the access controller allowing the requested read access to the shared memory, the TEE receiving read data from the shared memory; and if the second requestor is located in only one of the TEE and the NEE, decrypting the read data by the memory encryption circuit before transmitting the decrypted read data back to the second requestor, otherwise transmitting the read data back to the second requestor as plaintext read data without decryption.In another embodiment, the only one of the TEE and the NEE corresponds to the NEE, and the data processing system includes multiple NEEs, including the NEE, and the TEE includes multiple memory encryption circuits, including the memory encryption circuit, and the method further includes: receiving a write access request from a requester by the access controller, each requester is located in one of the multiple NEEs or in the TEE; when the access controller allows a first write access request generated by a first requester, selectively encrypting the write data corresponding to the first write access request, wherein the selective encryption includes encrypting the write data corresponding to the first write access request by a corresponding memory encryption circuit in the multiple memory encryption circuits when the first requester is located in one of the multiple NEEs, but not encrypting the write data corresponding to the first write access request when the first requester is located in the TEE; and storing the selectively encrypted write data corresponding to the first write access request in the shared memory at a first access address corresponding to the first write access request. In another aspect, the method further includes: receiving, by the access controller, a read access request from the requestor; receiving, in response to the access controller allowing a first read access request generated by a second requestor, read data corresponding to the first read access request; selectively decrypting the read data corresponding to the first read access request, wherein the selective decryption includes decrypting the read data corresponding to the first read access request by a second corresponding memory encryption circuit among the multiple memory encryption circuits when the second requestor is located in one of the multiple NEEs, but not decrypting the read data corresponding to the first read access request when the second requestor is located in the TEE; and transmitting the selectively decrypted read data corresponding to the first read access request back to the second requestor.

[0006] In yet another embodiment, a data processing system includes: a shared memory; a trusted execution environment (TEE), the TEE including a first requester, a first local interconnect, an access controller, and a set of memory encryption circuits, the first requester and the access controller being coupled to the first local interconnect, and the access controller being configured to allow or deny access requests to the shared memory, wherein the shared memory is external to the TEE; and a set of normal execution environments (NEEs), each NEE being configured to communicate with the TEE via a corresponding set of address lines and a corresponding set of data lines. In this further embodiment, a corresponding memory encryption circuit in the set of memory encryption circuits is configured to encrypt write data corresponding to a request for access to the shared memory generated by any requester in the set of NEEs before the TEE provides the write data for storage in the shared memory, and any write data corresponding to the request for access to the shared memory generated by the first requester is provided as plaintext write data for storage in the shared memory without any encryption or decryption. In one aspect, each memory encryption circuit in the set of encryption circuits in the TEE corresponds to one or more requestors in the set of NEEs, each memory encryption circuit utilizing a different key. In another aspect, the corresponding memory encryption circuit in the set of memory encryption circuits is configured to decrypt the read data corresponding to a request for access to the shared memory generated by any requestor in the set of NEEs before the TEE returns the read data to any NEE in the set of NEEs, wherein any read data corresponding to a request for access to the shared memory generated by the first requestor is returned from the shared memory to the first requestor without any encryption or decryption. In yet another aspect, the data processing system is further characterized as a system on a chip (SoC). BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The present invention is illustrated by way of example and not limitation in the accompanying drawings, in which like reference numerals indicate like elements. Elements in the drawings are illustrated for simplicity and clarity and are not necessarily drawn to scale.

[0008] Figure 1-3 Various data processing systems according to embodiments of the present invention are shown, each having a normal execution environment, a trusted execution environment, and a shared memory. DETAILED DESCRIPTION

[0009] In one aspect, the size of a data processing system having a secure subsystem (implementing a trusted execution environment (TEE)) is reduced by allowing memory to be shared between the secure subsystem and other subsystems of the data processing system (implementing an untrusted normal execution environment (NEE)). Since memory is an expensive resource, shared memory can allow for reduced cost and size. However, when memory is shared, the risk of confidential data leakage or one execution environment destroying the integrity of another execution environment increases significantly. Therefore, a hardware-implemented method using memory encryption is implemented to control access to shared memory, wherein such a hardware-implemented method cannot be manipulated by potential untrusted software. In one embodiment, the shared memory can be accessed via at least two different physical data paths, each for each execution environment that can supposedly access the shared memory. One of the execution environments is a TEE that regulates memory access to the shared memory. In order to protect the shared memory, a memory encryption engine is implemented in each of the different physical data paths except the physical data path from the TEE. Alternatively, the memory encryption engine is implemented only for the data path from the TEE rather than in the data path from the NEE. In this way, the memory contents of the shared memory will remain protected from any execution environment (any NEE) that does not speculatively have access to the shared memory.

[0010] Figure 1A data processing system 10 having an NEE 12, a TEE 18, and a shared memory 32 is shown according to an embodiment of the present invention. The data processing system 10 may be implemented as a SoC, and therefore may be referred to as a SoC 10. The SoC 10 may also include additional NEEs (2-N) 34, for a total of N NEEs, where N may be any integer greater than or equal to 2. In the illustrated embodiment, the NEE 12 includes a central processing unit (CPU) 14 and a local bus 16 that may transmit address, data, and control information. In addition to the CPU 14 and the local bus 16, the NEE may include any number of elements, such as additional cores or CPUs, peripheral devices, input / output (I / O) ports, memory, etc., each of which may be bidirectionally coupled to the local bus 16, or may be directly coupled to the CPU 14 (or other cores or elements of the NEE) via sideband signals external to the bus 16, or both. (Note that the description of NEE 12 also applies to any NEE in NEE 34, each of which may include any combination of cores, CPUs, or other elements.) In the illustrated embodiment, TEE 18 includes CPU 20, local bus 22, access controller 26 (also referred to as access control circuitry), and memory encryption circuitry 24. Similar to NEE 12, TEE 18 may also include any number of additional elements, such as additional cores or CPUs, peripherals, input / output (I / O) ports, memory, etc., each of which may be bidirectionally coupled to local bus 22, or may be directly coupled to CPU 20 (or other cores or elements of the TEE) via sideband signals external to bus 16, or both. In the case where SoC 10 includes additional NEEs 34, TEE 18 may also include additional memory encryption circuitry (2-N) 36 (referred to as MEC 36). In alternative embodiments, it should be noted that each of the buses 16 and 22 may be referred to as an interconnect or a local interconnect and may be implemented with any type of interconnect known in the art, such as a crossbar switch or interconnect structure.

[0011] In the illustrated embodiment, the TEE 18 is mutually exclusive with the NEE 12 (and with any of the NEEs 34). The NEE 12 is coupled to communicate with the TEE 18 via address and control lines coupled to the access controller 26 and data lines coupled to the memory encryption circuit 24. Within the TEE 20, the memory encryption circuit 24 is configured to encrypt / decrypt data with a key generated by the CPU 20. The CPU 20 (e.g., software executed on the CPU 20) configures and controls the access controller 26. The access controller 26 is configured to control or gate access to the shared memory 32. Only those access requests that are allowed or granted by the access controller 26 are provided to the shared memory 32. The access controller 26 receives access requests from the NEE 12 (e.g., from the CPU 14 via the bus 16) and from within the TEE 18 (e.g., from the CPU 20 via the bus 22), wherein each access request includes a corresponding access address and corresponding control information. For example, the corresponding control information may indicate the access type (e.g., read or write access) and may provide a security identifier (ID) identifying the requester (i.e., the element initiating the access request). Note that if the access request is a write access request, the access request additionally includes corresponding write data.

[0012] Any element or device in SoC 10 that can generate an access request to shared memory 32 can be referred to as a requestor (i.e., a master). In one embodiment, each element or device within SoC 10 has an assigned security ID to uniquely identify the element or device. This security ID can be included as part of any access request routed within SoC 10 to identify the source of the access request. Therefore, an access request from NEE 12 or from TEE 18 can be made by any requestor (e.g., a master or initiator device) within the corresponding environment. In the example shown, CPU 14 is the requestor of NEE 12, and CPU 20 is the requestor of TEE 18.

[0013] The TEE 18 operates a secure subsystem or secure enclave of the SoC 10 that performs security-related functions of the SoC 10. For example, the TEE 18 may implement secure booting of the SoC 10, control access to the SoC 10 (e.g., at debug ports and test ports), perform security functions such as encryption / decryption of the SoC 10, and control access to shared memory 32. The remainder of the SoC 10 outside of the TEE 18 may include any number (i.e., one or more) of NEEs, each of which may be coupled to communicate with the TEE 18 via address and control lines coupled to the access controller 26 and data lines coupled to corresponding memory encryption circuits of the TEE 18. Thus, the SoC 10 may include the NEE 12 and no additional NEEs, or the SoC 10 may also include an additional NEE 34. As a secure enclave, access to circuit systems or storage devices within TEE 18 is strictly restricted, where invasive physical security breaches or sabotage attempts by malicious users or attackers often occur at the inputs and outputs of TEE 18, or by corrupting storage bits or interfering with the power supply of TEE 18 (for example, injecting voltage glitches at the power supply terminal).

[0014] In the illustrated embodiment, the TEE 18 is configured to use the shared memory 32 to perform security-related functions. Therefore, the TEE 18 may not include any local memory with the TEE 18 (or may include only a small amount of local memory). However, as needed, the TEE 18 may include other storage elements, such as security registers and buffers. Although the request to use the shared memory 32 can come from any NEE, only the TEE 18 (and no one NEE) controls access to the shared memory 32. The TEE 18 controls access by configuring the access controller 26 to allow or deny other NEEs' access requests to the shared memory 32. For example, the TEE 18 may allow another NEE to access the shared memory 32 only when the other NEE is not using the shared memory. In addition, as will be discussed below, since the TEE 18 controls whether and when another NEE can access the shared memory 32, the TEE 18 can also take precautions before transferring access rights to the NEE, such as clearing or overwriting sensitive data from the shared memory. As will be discussed further below, use of shared memory external to TEE 18 needs to be protected to prevent access to any sensitive data temporarily or permanently stored within shared memory 32 (where shared memory 32 may be implemented as volatile or non-volatile memory).

[0015] In operation, the access controller 26 is configured by the CPU 20 to control access to the shared memory 32. In one embodiment, the access controller 26 can be implemented as a hardware block controlled by software executed on the CPU 20. For example, the access controller 26 can store configuration information such as security IDs and corresponding address ranges in registers that are allowed to access the shared memory 32. Therefore, in response to comparing the address and control information of the received access request with the stored configuration information, the access controller 26 can grant or deny access to the shared memory 32. (It should be noted that other hardware implementations that can be configured by the CPU 20 or other elements of the TEE 18 can be used to implement the access controller 26.) If access is granted, the access controller 26 provides any required address and control information to the shared memory 32. If the granted access is a write access, the access controller 26 also provides the corresponding write data to the shared memory 32 (or allows the corresponding write data to be provided to the shared memory 32). If the granted access is a read access, the access controller 26 receives the read data from the shared memory 32. However, depending on which environment is granted access to the shared memory 32, the write data or read data corresponding to the granted access request may or may not be encrypted or decrypted, respectively, by the memory encryption circuitry.

[0016] In the illustrated embodiment, the TEE 18 includes a memory encryption circuit 24 in the data path from the NEE 12 to the access controller 26. The memory encryption unit 24 is coupled to receive plaintext data from the CPU 14 (or from another requestor of the NEE 12) via the bus 16, encrypt the plaintext data, and output the encrypted data. The memory encryption 24 may also receive encrypted data from the shared memory 32 via the access controller 26, decrypt the encrypted data, and transmit the plaintext data back to the NEE 12. The keys used by the memory encryption circuit 24 for encryption / decryption are generated and stored within the TEE 18. For each request from the NEE 12 (whether a read request or a write request), the corresponding address and control information are provided to the access controller 26, which determines whether to grant access, as explained above.

[0017] For a write access request, the NEE 12 also provides the corresponding write data as plaintext data to the memory encryption 24. If the access controller 26 grants the write access request, the corresponding access address and any required portion of the control information and the memory write data are provided to the shared memory 32, wherein the encrypted data from the memory encryption 24 is provided as the memory write data to be written at the corresponding access address (i.e., the write address) of the shared memory 32. For a granted read access request, the corresponding access address and any required portion of the control information are provided to the shared memory 32, and in response, the read data stored at the corresponding access address (i.e., the read address) is received from the shared memory 32. This read data is provided to the memory encryption circuit 24, which decrypts the read data and transmits the decrypted read data back to the NEE 12 (back to the requester of the NEE 12) as plaintext data.

[0018] The access permission request from the CPU 20 (or other requester of the TEE 18) is similarly provided to the shared memory 32, except that encryption / decryption is not performed on the write data or the read data. That is, the memory encryption circuit 24 only encrypts / decrypts the data from or to the NEE 12, and does not encrypt / decrypt for the TEE 18. In addition, in the illustrated embodiment, the memory encryption 24 does not encrypt / decrypt the data from or to any other NEE. Since the TEE 18 does not include a memory encryption circuit in the data path between its requester (e.g., the CPU 20) and the access controller 26, any write data from the TEE 18 to the shared memory 32 is provided as unencrypted plaintext data, and any read data from the shared memory 32 back to the TEE 18 is also provided as unencrypted plaintext data to the requesting master. Thus, in response to read and write access requests granted from the TEE 18 to the shared memory 32 , only unencrypted plaintext data is passed between the CPU 20 (or any other requestor of the TEE 18 ) and the shared memory 32 .

[0019] It should be noted that the shared memory 32 can operate as known in the art to perform read or write operations received from the access controller 26. Also, it should be noted that any write data to the shared memory 32, whether in plain text or encrypted, can be stored in the write buffer of the TEE 18 as needed before being sent to the shared memory 32, and any read data returned from the shared memory 32 can also be stored in the read buffer of the TEE 18 as needed. In one embodiment, the write data for the write access request is provided to the shared memory 32 via the access controller 26. Alternatively, the access controller 26 can instead indicate to the write buffer that the write data is provided to the shared memory 32. Therefore, the routing of write and read data for the access request can be managed in different ways.

[0020] In one example of transferring ownership (i.e., control) of the shared memory 32, when the TEE 18 is granted access to the shared memory 32 by the access controller 26 (as configured by the TEE 18), the TEE 18 receives an access request to the shared memory 32 from the NEE 12. In response to this received access request, the TEE 18 can first ensure that the request is authentic (e.g., the request actually originates from the NEE 12, which can be done via a dedicated hardware signal or via a cryptographically signed message). Assuming that the access request is authentic, the TEE 18 ensures that the shared memory 32 is not required for any of its internal security operations. Once the shared memory 32 is free or no longer required by the TEE 18, the TEE 18 can clean up the memory contents of the shared memory 32. For example, the CPU 20 can clear the contents by overwriting the contents of the memory with randomly generated data to protect any sensitive data that may have been written to the shared memory 32 by the TEE 18. After the memory contents have been cleared, TEE 18 reconfigures access controller 26 to grant NEE 12 access to shared memory 32 .

[0021] Once NEE 12 completes its operations that require the use of shared memory 32, NEE 12 may inform TEE 18 (e.g., inform CPU 20) that TEE 18 may withdraw control of shared memory 32. At this point, TEE 18 reconfigures access controller 26 to allow TEE 18 access to shared memory 32 and prevent NEE 12 (and any other NEEs) from accessing shared memory 32. In one embodiment, TEE 18 again cleans up the contents of shared memory 32 and then resumes operations using shared memory 32 as needed for its operations.

[0022] In one example of an attack scenario, when ownership of the shared memory 32 is transferred between the TEE 18 and the NEE 12, a physical fault attack may occur (e.g., by destroying gates or bits, injecting voltage glitches, corrupting logic states, etc.), which may result in manipulating the integrity of the decisions made by the access controller 26. For example, when the TEE 18 has ownership of the shared memory, the access controller 26 can be manipulated to maliciously grant access to the NEE 12. In this case, an attacker running inside the NEE 12 may gain unauthorized access to confidential information stored in the shared memory 32. However, with the addition of memory encryption 24 between the NEE 12 and the shared memory 32, if the NEE 12 accesses any data within the shared memory 32 stored by the TEE 18 during its ownership of the shared memory, the NEE 12 will only be able to receive useless (e.g., corrupted) data. That is, because data from the TEE 18 is written to the shared memory 32 as plain text unencrypted data, but any read data accessed by the NEE 12 from the shared memory 32 is decrypted by the memory encryption 24 before being transmitted back to the NEE 12, the read data actually transmitted back to the NEE 12 is improperly decrypted, thereby effectively destroying the sensitive information being accessed.

[0023] In another example of an attack scenario, while the NEE 12 has ownership of the shared memory 32, an attacker may attempt to load malicious code into the shared memory 32 and inject a fault attack in an attempt to skip the memory cleanup process performed by the TEE 18. As a result, this may cause the TEE 18 to execute malicious code that provides access to sensitive processes and information. However, with the addition of the memory encryption circuit 24, the content (e.g., malicious code) to be written to the shared memory 32 is first encrypted. Since the CPU 20 of the TEE 18 accesses the read data from the shared memory 32 as plaintext data (without any encryption / decryption), the encrypted malicious code will not be decrypted and is therefore effectively garbage to the CPU 20. In this way, the attacker cannot control what will ultimately be written to the shared memory 32 because the content will always be first encrypted by the memory encryption 24 before being stored in the shared memory 32.

[0024] Figure 2SoC 40 is shown according to one embodiment of the present invention, which is similar to SoC 10, but the memory encryption circuit within the TEE has a different configuration, where the same reference numerals between SoC 10 and SoC 40 indicate the same elements. Therefore, in SoC 40, memory encryption circuit 24 is not present in the data path between NEE 12 and access controller 26, so that plaintext (unencrypted) data is written to shared memory 32, and data read from shared memory 32 is likewise not decrypted, similar to the way TEE 18 accesses shared memory 32 in SoC 10 without memory encryption. In fact, memory encryption unit 42 is located in the data path between CPU 20 and access controller 26, where any write data for a write access request allowed from TEE 18 is first encrypted by memory encryption 42, so that the encrypted data is provided to shared memory 32 as memory write data. Similarly, any read data returned from shared memory 32 for a read access request allowed is first decrypted by memory encryption circuit 42 before being provided back to CPU 20. Similar to memory encryption 24, the keys used by memory encryption circuit 42 are also generated by TEE 18 and stored in TEE 18. This configuration is also immune to the example attack scenarios described above, because if TEE 18 has ownership, but access controller 26 is manipulated to allow NEE 12 to access shared memory 32, only encrypted data that cannot be decrypted by NEE 12 will be accessed, thereby preventing access to sensitive information. Similarly, if NEE 12 has ownership and is able to load malicious code into shared memory 32 (which will not be encrypted), when TEE 18 loads the malicious code from shared memory 32, the malicious code will first be decrypted by memory encryption circuit 42, resulting in the malicious code being corrupted or making the malicious code non-executable in TEE 18.

[0025] Thus, in one embodiment, each environment of a SoC including a TEE and any number of NEEs (e.g., NEE 12 and NEE 34, if present) has a respective physical data path that is distinct from the other physical data paths to access shared memory 32 via access controller 26. For example, NEE 12 transmits its access requests via a set of conductors between bus 16 and access controller 26, and TEE 18 transmits its access requests via a set of conductors between bus 22 and access controller 26. If there are other requestors (e.g., masters) in either NEE 12 and TEE 18 that are capable of accessing shared memory 32, then the other requestors will each include their own respective data paths to access controller 26 so that access controller 26 can appropriately decide which access requests are granted (and therefore forwarded to shared memory 32) or denied. Similarly, if additional NEEs 34 are present, each of the NEEs 34 (or each requestor within those NEEs) will also include its own physical data path to access the shared memory 32 via the access controller 26. Thus, the access controller 26 can be coupled to receive access requests from any number of environments, including access requests from any number of requestors within an environment (where each requestor will have its own assigned unique security ID). The TEE 18 can therefore configure the access controller 26 to transfer ownership to any other environment as needed.

[0026] In an embodiment of a SoC with multiple NEEs, the TEE 18 will include an instantiation of a memory encryption circuit (MEC) for each physical data path into the access controller 26, wherein each instantiation will use a different key (generated by and stored within the TEE 18). For example, similar to the memory encryption circuit 24 corresponding to the NEE 12, the TEE 18 will include additional (2-N) MECs 36 corresponding to the (2-N) NEEs, one MEC for each physical data path between a respective NEE and the access controller 36. The MECs 36 will each be coupled and operated similarly to the MEC 24 (with respective address / control lines coupled between each of the NEEs 34 and the access controller 26, and with respective data lines coupled between each of the NEEs 34 and a respective one of the MECs 36). In this way, for any requester in any NEE having a corresponding memory encryption circuit within TEE 18, plaintext data is transferred between the requester and the corresponding memory encryption circuit, and after the access controller 26 grants the request, only the encrypted data (memory write data or memory read data) for which the request is allowed is transferred between the shared memory 32 and TEE 18. It should be noted that any memory encryption circuit (e.g., 24, 42, and 36) described herein can be implemented with any known memory encryption engine.

[0027] Figure 3 A SoC 50 is shown according to one embodiment of the present invention, which is similar to SoCs 10 and 40, where like reference numerals indicate like elements, but where a shared memory 52 is located outside the SoC. In this example, the TEE 18 includes an instantiation of memory encryption circuitry for each physical data path between any requestor and the access controller 26, each instantiation using a different key (generated by and stored in the TEE 18). In this scenario, security may not be as strong because the contents of the external shared memory may be directly accessible to an attacker. Therefore, encryption circuitry for all data paths provides additional security for this scenario. (It should be noted that in the SoC 50, there may also be additional NEEs and additional MECs, as described above with respect to Figure 1 and 2 34 and MEC 36.)

[0028] Return to view Figure 1In a SoC 10 where there are additional NEEs 34, alternative embodiments may implement memory encryption in different ways. For example, because a memory encryption engine may be expensive in terms of area and performance, rather than having one instantiation of the MEC for each NEE, a single memory encryption engine may be shared between two or more NEEs. In this example, a fault attack may affect the memory isolation of the shared memory 32 between different NEEs having a shared memory encryption engine, but the isolation between the NEE and the TEE 18 remains intact, making any sensitive content stored by the TEE 18 not vulnerable to such attacks.

[0029] Return to view Figure 2 In the case of a SoC 40 in which additional NEEs 34 are present, one or more additional MECs may be included within the TEE 18 in addition to the memory encryption circuit 42, wherein some or all of the NEEs of the SoC 40 have their own corresponding MECs in the TEE 18. For example, only a subset of the NEEs (i.e., less than all) may each have a corresponding MEC in the TEE 18. Alternatively, any of the one or more additional MECs may be shared among multiple NEEs.

[0030] Thus, while using a memory encryption engine with different keys for different environments generally provides some protection, in a SoC with a TEE and a NEE, improved protection against physical fault attacks can be achieved by having a memory encryption engine on only a single data path (from either the NEE or the TEE) to the shared memory, as discussed in relation to Figure 1 and 2 As described in the physical attack examples provided (where memory encryption is only on the data path corresponding to NEE 12 but not on the data path for TEE 18, or where memory encryption is only on the data path corresponding to TEE 18 but not on the data path for NEE 12). Alternatively, improved protection against such attacks can be provided by having a memory encryption engine for the data path corresponding to the NEE but not on the data path for TEE 18. By distinguishing whether encryption is provided in the data path for the TEE and the NEE, improved protection of sensitive content in the shared memory can be achieved. For example, this includes encryption only in the TEE data path but not in any NEE data path, or encryption not in the TEE data path but in the NEE data path (or in at least one or more NEE data paths).

[0031] It should be noted that Figure 1 , 2In 3 and 4, the conductors between the elements may be shown with or without hash lines indicating multiple conductors. However, any of the conductors shown, whether or not with hash lines, may represent multiple conductors. As used herein, the term "bus" is used to refer to multiple signals or conductors that can be used to transmit one or more various types of information, such as data, address, control, or status. Also, the conductors as discussed herein may be shown or described with reference to a single conductor, multiple conductors, unidirectional conductors, or bidirectional conductors. However, different embodiments may change the implementation of the conductors. For example, a separate unidirectional conductor may be used instead of a bidirectional conductor, and vice versa. Also, multiple conductors may be replaced by a single conductor that transmits multiple signals in serial or in a time-multiplexed manner. Likewise, a single conductor carrying multiple signals may be separated into various different conductors that carry subsets of these signals. Therefore, there are many options for transmitting signals.

[0032] Since the devices implementing the present invention are largely composed of electronic components and circuits known to those skilled in the art, in order to understand and appreciate the basic concepts of the present invention and in order not to confuse or deviate from the teachings of the present invention, the circuit details will not be explained to any greater extent than is deemed necessary as described above.

[0033] Where appropriate, some of the above embodiments may be implemented using a variety of different information processing systems. Figure 1-3 The present invention and its discussion describe an exemplary information processing architecture, but this exemplary architecture is presented only to provide a useful reference when discussing various aspects of the present invention. Of course, for the purpose of discussion, the description of the architecture has been simplified, and it is only one of many different types of suitable architectures that can be used in accordance with the present invention. Those skilled in the art will recognize that the boundaries between logic blocks are merely illustrative, and alternative embodiments may merge logic blocks or circuit elements, or impose alternative decompositions of functionality on various logic blocks or circuit elements. Therefore, it should be understood that the architectures depicted herein are merely exemplary, and that many other architectures that achieve the same functionality may actually be implemented.

[0034] Also, for example, in one embodiment, the illustrated elements of data processing system 10 are circuit systems located on a single integrated circuit or within the same device. Alternatively, system 10 may additionally include any number of separate integrated circuits or separate devices interconnected with each other. For example, memory, peripherals, etc. may be located on the same integrated circuit CPU 14 and 20, or on separate integrated circuits or devices.

[0035] In addition, those skilled in the art will recognize that the boundaries between the functionality of the operations described above are merely illustrative. The functionality of multiple operations can be combined into a single operation, and / or the functionality of a single operation can be distributed in additional operations. In addition, alternative embodiments can include multiple instances of a particular operation, and the order of the operations can be changed in various other embodiments.

[0036] Although the present invention is described herein with reference to specific embodiments, various modifications and changes may be made without departing from the scope of the present invention as set forth in the appended claims. For example, any type of core may be used in place of CPUs 14 and 12. Therefore, the description and drawings should be viewed in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of the present invention. It is not intended that any benefit, advantage, or solution to a problem described herein with respect to a specific embodiment be construed as a key, required, or essential feature or element of any or all claims.

[0037] As used herein, the term "coupled" is not intended to be limited to a direct coupling or a mechanical coupling.

[0038] Furthermore, the term "a / an" as used herein is defined as one or more than one. Also, the use of introductory phrases such as "at least one" and "one or more" in the claims should not be interpreted as implying that the introduction of another claim element by the indefinite article "a" or "an" will limit any particular claim containing this introduced claim element to an invention containing only one such element, even when the same claim includes the introductory phrase "one or more" or "at least one" and an indefinite article such as "a" or "an". The same applies to the use of definite articles.

[0039] Unless otherwise stated, terms such as "first" and "second" are used to arbitrarily distinguish between the elements these terms describe. Therefore, these terms are not necessarily intended to indicate temporal or other prioritization of such elements.

Claims

1. A data processing system, characterized in that: include: Shared memory; a trusted execution environment (TEE), the TEE comprising a first requestor, a first local interconnect, an access controller, and a first memory encryption circuit, the first requestor and the access controller being coupled to the first local interconnect, and the access controller being configured to allow or deny access requests to the shared memory, wherein the shared memory is external to the TEE; as well as a normal execution environment (NEE) configured to communicate with the TEE via a set of address lines and a set of data lines, the NEE comprising a second requestor and a second local interconnect coupled to the second requestor, the set of address lines, and the set of data lines, The first memory encryption circuit is configured to encrypt the write data before the TEE provides the write data corresponding to the access permission request to the shared memory generated by only one of the first requester and the second requester for storage in the shared memory, wherein any write data corresponding to the access permission request to the shared memory generated by the other of the first requester and the second requester is provided as unencrypted write data for storage in the shared memory.

2. The data processing system according to claim 1, characterized in that The first memory encryption circuit is further configured to decrypt the read data from the shared memory corresponding to the access permission request generated by the only one of the first requester and the second requester before the TEE returns the read data to the only one of the first requester and the second requester, wherein any read data corresponding to the access permission request for the shared memory generated by the other of the first requester and the second requester is returned to the other of the first requester and the second requester as plaintext read data without any encryption or decryption.

3. The data processing system according to claim 1, characterized in that: The first memory encryption circuit is configured to encrypt the write data before the TEE provides the write data corresponding to the access permission request for the shared memory generated by the first requestor for storage in the shared memory, wherein any write data corresponding to the access permission request for the shared memory generated by the second requestor is provided as unencrypted write data for storage in the shared memory.

4. The data processing system according to claim 1, characterized in that: The first memory encryption circuit is configured to encrypt the write data corresponding to the access permission request for the shared memory generated by the second requester before the TEE provides the write data for storage in the shared memory, wherein any write data corresponding to the access permission request for the shared memory generated by the first requester is provided as unencrypted write data for storage in the shared memory.

5. The data processing system according to claim 4, characterized in that: The TEE further includes a second memory encryption circuit, and the data processing system further includes: a second NEE configured to communicate with the TEE via a second set of address lines and a second set of data lines, wherein the second memory encryption circuit is configured to encrypt write data corresponding to a request for access permission to the shared memory generated by a requestor of the second NEE before the TEE provides the write data for storage in the shared memory.

6. A method in a data processing system, characterized in that The data processing system includes a trusted execution environment (TEE), a normal execution environment (NEE), and a shared memory outside the TEE, wherein the TEE includes a memory encryption circuit corresponding to only one of the TEE and the NEE, and the method includes: receiving, by an access controller within the TEE configured to control access to the shared memory, a write access request generated by a requester located within the TEE or the NEE; and In response to the access controller allowing the requested write access to the shared memory, providing corresponding write data to the shared memory, wherein: If the requester is located in the only one of the TEE and the NEE, the write data is encrypted by the memory encryption circuit before providing the write data to the shared memory, Otherwise, the write data is provided to the shared memory as unencrypted plaintext data.

7. The method according to claim 6, characterized in that Also includes: Receiving, by the access controller, a read access request generated by a second requestor located within the TEE or the NEE; In response to the access controller allowing the requested read access to the shared memory, the TEE receives read data from the shared memory; as well as If the second requestor is located in the only one of the TEE and the NEE, the memory encryption circuit decrypts the read data before transmitting the decrypted read data back to the second requestor, otherwise, the read data is returned to the second requestor as plaintext read data without decryption.

8. The method according to claim 6, characterized in that The only one of the TEE and the NEE corresponds to the NEE, the data processing system includes a plurality of NEEs including the NEE, and the TEE includes a plurality of memory encryption circuits including the memory encryption circuit, the method further comprising: Receiving, by the access controller, a write access request from a requestor, each requestor being located in one of the plurality of NEEs or in the TEE; When the access controller allows a first write access request generated by a first requester, selectively encrypting write data corresponding to the first write access request, wherein the selective encryption includes: encrypting, by a corresponding memory encryption circuit of the plurality of memory encryption circuits, the write data corresponding to the first write access request when the first requester is located in one of the plurality of NEEs, but not encrypting the write data corresponding to the first write access request when the first requester is located in the TEE; and The selectively encrypted write data corresponding to the first write access request is stored in the shared memory at a first access address corresponding to the first write access request.

9. A data processing system, characterized in that: include: Shared memory; a trusted execution environment (TEE), the TEE comprising a first requestor, a first local interconnect, an access controller, and a set of memory encryption circuits, the first requestor and the access controller being coupled to the first local interconnect, and the access controller being configured to allow or deny access requests to the shared memory, wherein the shared memory is external to the TEE; as well as a set of normal execution environments (NEEs), each NEE being configured to communicate with the TEE via a respective set of address lines and a respective set of data lines, Wherein a corresponding memory encryption circuit in the set of memory encryption circuits is configured to encrypt write data before the TEE provides write data corresponding to a request for access permission to the shared memory generated by any requestor in the set of NEEs for storage in the shared memory, wherein any write data corresponding to the request for access permission to the shared memory generated by the first requestor is provided as plaintext write data for storage in the shared memory without any encryption or decryption.

10. The data processing system according to claim 9, characterized in that: The corresponding memory encryption circuit in the set of memory encryption circuits is configured to decrypt the read data before the TEE returns the read data corresponding to the access permission request for the shared memory generated by any requestor in the set of NEEs to any NEE in the set of NEEs, wherein any read data corresponding to the access permission request for the shared memory generated by the first requestor is returned from the shared memory to the first requestor without any encryption or decryption.

Images