Methods of on-chip memory partitioning and secure access violation checking in a system-on-chip

Systems and methods for partitioning memory into multiple secure and open regions are provided. The systems enable the security level of a given region to be determined without an increase in the time needed to determine the security level. Also, systems and methods for identifying secure access violations are disclosed. A secure trap module is provided for master devices in a system-on-chip. The secure trap module generates an interrupt when an access request for a transaction generates a security error.

BACKGROUND

1. Field of the Invention

The present invention generally relates to data and computer security.

2. Background Art

Maintaining the security of peripherals and other components in a computing environment is vital. Ensuring that non-secure components cannot access secure peripherals may be difficult as the number of components and peripherals grows. Further, identifying the reason a given access is not permitted may assist an application developer or other user in debugging.

On-chip temporary storage is often used for storage of calculations for quick access and other purposes. Temporary storage may be divided into secure and open regions. Current techniques for partitioning memory into secure and open regions are inflexible. Increasing the number of partitions in these systems results in increased latency for memory accesses.

What is therefore needed are methods and systems to support multiple interspersed secure and open memory regions without the timing penalties of existing systems.

What is further needed are methods and systems to implement secure access violation checks in a system on chip.

DETAILED DESCRIPTION

While the present invention is described herein with reference to the illustrative embodiments for particular applications, it should be understood that the invention is not limited thereto. Those skilled in the art with access to the teachings provided herein will recognize additional modifications, applications, and embodiments within the scope thereof and additional fields in which the invention would be of significant utility.

Partitioning Internal Memory

Electronic systems such as computers, wireless phones, etc. all include memory. For devices designed to handle sensitive applications or data, one or more memory units in the device is partitioned to designate a portion of the memory as secure. For example, on-chip, internal scratch memory, or RAM is often partitioned into secure regions and open regions by a memory partitioning unit. Generally, secure regions of memory can be accessed only by peripherals and devices that are identified as secure, while open regions can be accessed by both secure and non-secure peripherals and devices.

Typically, the memory partitioning unit is a fencepost register.FIG. 1illustrates a fencepost register110that partitions memory101into a secure and an open region. The fencepost register defines the boundary between a secure memory region and an open or non-secure memory region.FIG. 2depicts an exemplary memory partitioning unit200utilizing a fencepost register210. As illustrated inFIG. 2, memory partitioning unit200includes an arithmetic logic unit (ALU)215that receives as input the value stored in the fencepost register and a portion of the memory address to be accessed (e.g., the n most significant bits of the address). The granularity of a fencepost register is typically 4 Kilobytes (KB) which is the page size of most operating systems. As illustrated inFIG. 2, the fencepost register has a granularity of 4 KB which requires a 5 bit comparison for a typical scratch memory of up to 128 KB. The five most significant bits of the memory address to be accessed are compared against the fencepost register value which represents the boundary address to determine whether the memory address is in the secure or open region. For example, a scratch memory of 128 KB may be divided into a secure region of 32 KB, and an open region of 96 KB. The fencepost register may compare a memory address to be accessed against the address of the boundary to determine whether the memory address falls within in the 32 KB secure region (e.g., is less than the boundary address), or in the 96 KB open region (e.g., is greater than the boundary address).

The resulting bit (e.g., “0” secure memory or “1” non-secure memory) is provided to a verification circuit230as input. As shown inFIG. 2, this bit is inverted prior to being input to the comparison circuit. Verification circuit230also receives an input indicating the type of memory access requested (e.g., secure or non-secure). In an embodiment, verification circuit230includes a NAND gate. The output of the verification circuit will indicate whether the requested access is authorized for the memory address.

One limitation of a memory partitioning unit based on fencepost registers is that only two regions of the scratch memory can be defined. If more than two regions are desired, additional fencepost registers would be necessary and more levels of logic would be required in the comparison circuit. These additional fencepost registers and logic levels increase the latency required to access memory. Partitioning the memory unit such that secure and open regions are in no particular order is not possible.

Embodiments of the present invention provide methods and systems for partitioning memory to support multiple interspersed secure and open memory regions with no extra timing penalty as experienced with prior techniques.

FIG. 3is a diagram of a memory310having multiple interspersed secure and open regions, according to embodiments of the present invention. Memory310may be any memory unit including but not limited to internal scratch memory, on-chip memory, or RAM. As illustrated inFIG. 3, memory301is partitioned into multiple secure regions301a,301e, and301f, and multiple open regions301b,301c, and301d, and301h. In the example ofFIG. 3, memory310is divided into 32 distinct regions. For example, memory310may be a 128 KB scratch memory, partitioned into 32 four (4) KB regions. As would be appreciated by a person of skill in the art, memory310could be partitioned into any number of regions based on the needs of the application or system.

Each region (or partition) has an associated security level. The security level at a minimum defines whether the region (or partition) is secure or open. The security level may be used to further refine security privileges or attributes associated with the region. The number of bits used to define the security level determines the granularity that can be applied to the security level. For example, if the security level is represented by 1 bit, only two values can be defined for security such as “0” is secure and “1” is non-secure. If the security level is represented by 2 bits, four values can be defined.

Memory310has one or more associated configuration registers320. The width of the configuration register is at least the number of partition regions of memory310. For example, in the example ofFIG. 3, memory310has 32 regions and the width of configuration register320is 32 bits. Each bit location in configuration register320is associated with a memory region (partition). For example, bit location0corresponds to memory partition0, bit location9corresponds to memory partition9, etc.

The value stored in the bit location of the configuration register corresponds to the security level of the associated region (partition). In the example ofFIG. 3, for each secure region, configuration register320contains a value of 0 in the associated bit location, while for each open region, configuration register320contains a value of 1 in the associated bit location. The values in row321indicate the region which corresponds to a value in configuration register320.

FIG. 4is a block diagram of a memory partitioning unit400, according to embodiments of the present invention. Memory partitioning unit400includes multiplexer412and a verification circuit450. As seen inFIG. 2, all or a portion of the memory address421to be accessed by a transaction is used as control bits for multiplexer412. The values stored in configuration register420are used as inputs to multiplexer412. The size of the multiplexer is based on the width of the configuration register. In the example ofFIG. 4, the configuration register has 32 bits, therefore multiplexer412is set to be a 32-to-1 multiplexer. The portion of the memory address421to use as the control bits is based on the number of regions (partitions). In one embodiment, the n most significant bits of the address to be accessed by the transaction are used. For example, 5 bits would be required to represent 32 memory partitions (labeled0to31). In the example ofFIG. 4, the 5 most significant bits of the address are used as the control bits for the multiplexer.

Multiplexer412outputs the value of the configuration register associated with the address identified by the control bits. The output of multiplexer412identifies the security level for the address to be accessed (e.g., whether the address is in a secure or open region of memory). The security level for the region to be accessed may be output to a verification circuit450such as an access validator circuit. Verification circuit450further receives the security value assigned to the memory access transaction (e.g., secure or non-secure). Based on this information and the output of multiplexer412the verification circuit450determines whether the transaction is authorized. For example, a non-secure access transaction would not be permitted to access a memory location designated as secure. If the access is permitted, a response may be transmitted to the device that originated the access request. If the access represents a violation, an error response may be transmitted to the device that originated the access request and/or a security monitor for the system. In one embodiment, if the access represents a violation, an interrupt may be generated and transmitted to a component, such as a security monitor, in the system. In a further embodiment, if the access request that represents a violation is a read access request, a pre-determined value may be generated and returned to the device that originated the access request and/or a security monitor. The pre-determined value may be used for debugging or other purposes. If the access request that represents a violation is a write access request, the request may be dropped.

As discussed above, embodiments of the present invention include a multi-bit security level. The number of bits used to represent the security level determines the number of security levels (types of memory regions) that can be applied. For example, For example, when a 2-bit security level is used, memory may be partitioned into four types of regions, each with a different security level. The use of a 3-bit security level would allow 8 types of regions (security levels) to be applied to memory. As would be appreciated by a person of skill in the art, any number of security levels can be defined for a memory, based on the needs of the system.

FIG. 5is a diagram of such a memory510partitioned according to a multi-bit security level, according to embodiments of the present invention. In the exemplary embodiment ofFIG. 5, a 2-bit security level is applied, resulting in 4 types of memory (security levels ranging from zero to three). AlthoughFIG. 5depicts a 2-bit security level, a person of skill in the art would recognize that additional bits could be used resulting in a greater number of security levels available for the system.

Memory510is partitioned into n regions. For ease of discussion, memory510ofFIG. 5is depicted as being partitioned into 32 regions. Each region of memory510is assigned a different type (security level). Region501ahas a security level of 3, region501bhas a security level of 2, region501chas a security level of zero, while region14has a security level of 1.

The assigned security levels for each region are stored in one or more configuration registers.FIGS. 6Aand B depict two alternatives for storing security level information, according to embodiments of the present invention. In the embodiment depicted inFIG. 6A, each bit of the security level is stored in a separate configuration register. In this embodiment, the number of configuration registers would equal the number of bits used to represent the security level. In the example ofFIG. 6A, a 2-bit security level is used and therefore, two configuration registers are required. As illustrated inFIG. 6A, configuration register622stores bit “0” of the security level for each of the n (e.g., 32) memory regions. Configuration register624stores bit “1” of the security level for each of the n (e.g., 32) memory regions. In the embodiment depicted inFIG. 6B, the security level bits are not split between registers but instead stored in the same register. Depending on the size of the register, the size of the security level field, and the number of partitions, additional configuration registers may be required in this embodiment. As shown in the example ofFIG. 6B, for a 2-bit security level, the security levels for regions0through15are stored in configuration register626and the security levels for regions16through31are stored in configuration register628.

FIG. 7depicts a block diagram of a memory partitioning unit700supporting a multi-bit security level, according to embodiments of the present invention. In the embodiment ofFIG. 7, the security level705is represented by x bits (where x is greater than 1). Memory partitioning unit700includes x multiplexers712A through712X. The number of multiplexers required is based on the number of bits in the security level to be processed by unit700. For example, if the security level has 2 bits (x=2), memory partitioning unit700would include 2 multiplexers,712A and712B. If the security level has 3 bits (x=3), memory partitioning unit700would include 3 multiplexers.

Multiplexers712A through712X are n-to-1 multiplexers. The size of the multiplexer, n, is based upon the number of memory regions (partitions). For example, if the memory is partitioned into 32 regions, multiplexers712A through712X are 32-to-1 multiplexers. Each multiplexer receives as input a bit from the security level of each memory region. For example, multiplexer712A receives n inputs corresponding to bit “0” of the security level for each of the n regions. Multiplexer712X receives n inputs corresponding to bit “x” of the security level for each of the n regions.

As illustrated inFIG. 7, if each security level bit is stored in a separate register622and624(as depicted inFIG. 6B), the value in the 0 position of bit “0” register622is provided as the 0 input to multiplexer712A and the value in the 0 position of the bit “x” register624is provided as the 0 input to multiplexer712X. Similarly, the value in the 1 position of bit “0” register622is provided as the 1 input to multiplexer712A and the value in the 1 position of the bit “x” register is provided as the 1 input to multiplexer712X, and so on. If the security level is stored in the same register for a region (as illustratedFIG. 6B), the “0” bit for that region is provided to multiplexer712A and the “1” bit for that region is provided to multiplexer712X.

Each of the multiplexers712A through712X receives a portion of the memory address to be accessed by a transaction as the control bits for the multiplexer. In an embodiment, as described above, the control bits are the m most significant bits for the address where m is based on the number of bits required to represent the number of memory regions (e.g., 32 memory regions requires 5-bits, 64 requires 6-bits, etc.). The multiplexers then select the value of the security level bit associated with the memory address to be accessed. For example, if memory address 00010xxx is being accessed, multiplexer712A will output the input labeled2as the security level for bit “0” of memory address 00010xxx.

The outputs of multiplexers712A through712X are provided as input to a verification circuit750. Verification circuit750also receives as input an indication of the security associated with the attempted memory access transaction. Verification circuit750then determines based on the security level of the memory address to be accessed (received from multiplexers) whether the transaction is authorized.

FIG. 8is a flow diagram of a method800for determining whether access to a memory address is valid, according to embodiments of the present invention. Method800is described with reference to the embodiments ofFIGS. 3-7. However, method800is not limited to those embodiments.

Method800begins at step810, where a memory unit, such as an internal scratch memory, is partitioned into multiple regions. In this step, each region is assigned a security level. The security level value is then stored in one or more configuration registers. For example, memory may be partitioned into 32 regions with each region having an associated 1-bit security level to indicate whether the region is secure or open.

At step820, an access request for a memory address is received.

At step830, the security level associated with the memory address to be accessed is determined. As discussed above, the memory address to be accessed is included in one of the regions (partitions) of the memory unit. In this step, the security level for the region containing the memory address is determined. First, the security level for each region (partition) is provided to one or more multiplexers. A portion of the memory address to be accessed is used as control bits for the multiplexer. The output of the one or more multiplexers is the security level associated with the region containing the memory address to be accessed.

At step840, a determination is made as to whether the access request for the memory address is authorized. The determination may be made based on the identified security level for the region of the memory unit that includes the memory address and the security value for the transaction. For example, a non-secure transaction (e.g., originating from a non-secure component) may not be authorized to access an address in a secure region of memory.

In accordance with one embodiment, other types of memory can be partitioned using the techniques described herein. For example, external volatile memory, such as SDRAM, can be configured to include multiple regions with different security levels as described herein.

Secure Access Violation Checks

System-on-chip (SoC) devices integrate components of a computing device on a single chip. Such SoC devices are often used in computing devices such as mobile phones, tablet computers, and other devices. A challenge in SoC devices is to ensure that only secure master components can access secure slave components. In prior systems, management of secure access requests, for example, identifying secure access violations, is performed by a separate secure master device, such as a security aware processing device. However, as the number of master devices increases, the security aware processing device may not be suitable to manage all secure access requests.

FIG. 9is a diagram of a system900for performing security access violation checks, according to embodiments of the present invention. System900may be implemented as part of a SoC device.

System900includes one or more master components901A through901N. A master may have an associated security level designation. In embodiments, the system has “n” levels of security, where n is greater than 1. For example, if n is equal to two, a master may be designated as a secure master or an open master. In this example, secure masters can access both secure and open slaves. Open masters can only access open slaves. In an embodiment, one or more masters may be capable of generating both secure and non-secure transactions based on the level of virtualization in their software. Masters may be, in one embodiment, Advanced eXtensible Interface (AXI) transaction masters in an ARM architecture. Other architectures are possible as well, as will be known to those of skill in the art.

System900may further include one or more slaves907and911A through911N. In embodiments, slaves are peripherals such as network interfaces or interfaces to other devices. A slave may be designated as one of two types. Slaves may be designated as security-aware or non-security-aware. A security-aware slave implements its own security. Non-security-aware slaves may rely on another component, such as a decoder, to implement security checks for the slave.

Like masters, each slave has an associated security level. As described above with reference to masters, “n” security levels for slaves are possible, where n is greater than 1. For example, if the system supports two levels of security, the slaves may have a security level of secure or open. In this example, a secure slave is accessible only by secure masters in the system. The whole address range of the secure slave is configured as secure. An open slave is accessible by both secure and open masters. The whole address range of the peripheral is configured as open.

Slaves911A through911N are coupled to decoder909which performs security checks for the one or more of the slaves that are not security aware. In embodiments, slaves911A through911N may be advanced peripheral bus (APB) slaves or advanced high-performance bus (AHB) slaves. One or more slaves907or911N are security aware. In security aware slaves, security checks are performed by the slaves.

Masters901generate requests to access slaves. Each master device901is associated with a secure trap module902. For example, each of master901A through901N is associated with a secure trap module902A through902N. Secure trap modules are configured to capture responses returned as a result of an access request. A secure trap module902includes a transaction FIFO buffer, one or more registers and a bus to access the registers. In an embodiment, registers include a configuration register and one or more status registers. A status register is configured to capture the ID, address and access type of a request.

The transaction FIFO buffer may store information for all outstanding transactions, and may log characteristics for transactions. A secure trap module902may use the FIFO transaction buffer to determine which access request from a master device901generated a particular security response. For example, secure trap module902may be configured to add to the transaction FIFO for each address request and match the incoming response direction and ID to a FIFO entry to remove the entry. When a violation response is detected, the secure trap module902is configured to copy the entry information into a status register. The secure trap module902may also be configured to generate an interrupt or send an error response back to the master after detecting a violation, as described in more detail below.

Each master device901and secure trap module902are coupled to a switch905, such as an AXI switch. Switch905is configured to route access requests and responses to appropriate destinations. For example, switch905may route access requests for ARM peripheral bus (APB) slaves to decoder909. Decoder909may be, in one embodiment, an AXI2APB decoder. Such a decoder909may allow AXI components to communicate with APB component. In one embodiment, system900may also include ARM High-performance bus (AHB) slaves and a corresponding AXI2AHB decoder. Switch905may also route access requests for security aware slaves (such as slave907) to the slave. System900may include more than one switch905.

Decoder909may be coupled to any number of slaves911A through911N. In one embodiment, a register, such as a secure configuration register913, may assist decoder909in determining whether a particular slave911is secure or open. For example, a value of 0 in configuration register913may indicate that a slave is secure. Correspondingly, a value of 1 in configuration register913may indicate that a slave is open, and a value of X may indicate that the slave is security aware. In one embodiment, the bits set in secure configuration register913are one-way lockable bits, and cannot be changed until system900is reset.

Decoder909receives access requests for slaves911A through N from masters901. Using information from secure configuration register913, decoder909determines whether a particular access request is intended for a non-security-aware slave (e.g. a secure slave or an open slave), or a security-aware slave.

Decoder909is configured to perform a security check on received access requests for slaves that are not security aware. The access request for a transaction includes information indicating whether the master device901sending the access request is a secure or open master. For example, if the access request is from a secure master, and the intended slave is a secure or open slave, the access is permitted and decoder909may return an OK security response. If the access request is from an open master, and the intended slave is an open slave, the access may also be permitted, and decoder909may return an OK security response. If the transaction access request is from an open master and the intended slave is a secure slave, the access is denied and decoder909returns a violation security response. In one embodiment, read access requests that indicate security access violations may be returned with a pre-determined value as a violation signature. Write access requests that indicate security access violations may be dropped so that the master is not affected.

Secure trap module902is configured to monitor responses watching for security violation responses. In one embodiment, the security response received at a secure trap module902indicates whether the intended access for the transaction was a read access or a write access. In a further embodiment, response codes may indicate whether an access violation is a security access violation or another type of access error.

If the security response is an OK security response, secure trap module902passes the response to the master. If the security response indicates a violation, the secure trap module902for the master takes appropriate action. For example, if a read access request generates a security access violation, an error code may be transmitted to the master associated with the access request. Such an error code may signify that the response does not include valid data. In an embodiment, secure trap module902generates an interrupt using the configuration register. For example, if a write access request indicates a security access violation, the secure trap module may simply drop the response after transmitting the interrupt.

In one embodiment, the interrupt may be communicated to a secure master917, such as an application processor in an ARM architecture. The application processor may have full control over security-related functions for the system. Secure master917may include processing logic to take further action if a secure interrupt is generated.

System900may include a second register, such as a security aware configuration register915, that is configured to assist decoder909in determining whether a particular slave device is security aware. If a slave device is security aware, such as security aware slave device911N, the slave device itself may determine whether a given access request for the slave device for a transaction is permitted. The security-aware slave device may then generate a response for the access (i.e. OK or violation), and pass this response to the decoder909which in turn communicates the response to switch905, as detailed above. In one embodiment, AXI slave devices, such as AXE slave907, are always security aware, and generate security responses for access requests.

FIG. 10is a flow diagram of a method1000for identifying a security violation in a system-on-chip, according to embodiments of the present invention. Method1000is described with reference to the embodiment ofFIG. 9. However, method1000is not limited to that embodiment.

Method1000begins at step1002, where a master generates an access request. The access request indicates a slave to be accessed, and also indicates whether the master is secure or open.

At step1004, the access request is transmitted to a target such as decoder909or a security aware slave. For example, if the request is for a slave that is not security aware, the request is provided to decoder909. If the request is for a security aware slave, the request will be sent to the slave either directly (e.g., slave907) or via decoder909.

At step1006, the target determines whether the access request is authorized, based on whether the master is secure or open, and whether the slave to be accessed is secure or open. In embodiments, additional factors and information may be used to make this determination. The target may generate and communicate an appropriate security response.

At step1008, a secure trap module receives the response associated with the request.

At decision block1010, the secure trap module determines whether the response indicates a security violation, or whether the security response indicates a permitted access. If the security response indicates a permitted access, method1000proceeds to step1012, where the response is transmitted to the master device. If the response indicates a security violation, method1000proceeds to step1014, where a secure interrupt is generated. For example, secure trap module may generate a secure interrupt, and transmit the secure interrupt to a secure master device.

The breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments.