System on a chip comprising a memory controller and corresponding memory control method.
The memory controller with integrated verification means addresses the issue of inadequate boot process protection by dynamically adapting to system security levels, ensuring secure memory access through an additional protection mechanism.
Patent Information
- Application Number
- FR2023004400
- Authority / Receiving Office
- FR · FR
- Patent Type
- Patents
- Current Assignee / Owner
- Filing Date
- 2023-05-02
- Publication Date
- 2025-11-07
- Estimated Expiration
- 2043-05-02
AI Technical Summary
Conventional firewalls in systems-on-a-chip fail to adequately protect external memory during the boot process by not filtering access based on evolving system-on-chip security levels, allowing unauthorized access to memory regions that should be secured.
A memory controller with integrated verification means that stores transaction information in a control register and conditions access based on a list of special transactions and evolving system-on-chip security levels, providing additional protection beyond conventional firewalls.
Ensures secure memory access by dynamically adapting to the system's evolving security level during boot, preventing unauthorized transactions and enhancing protection mechanisms, especially during the boot process.
Smart Images
Figure 00000013_0000 
Figure 00000014_0000 
Figure 00000015_0000
Abstract
Description
Title of the invention: System on chip comprising a memory controller and corresponding memory control method.
[0001] Embodiments and implementations of the invention relate to integrated circuits such as systems on chip (“System on Chip” in English) including in particular a memory controller, for example an external memory, and more particularly concerning authorizations and restrictions of access to memory regions of the memory.
[0002] Indeed, to help ensure the security of systems-on-a-chip, resource isolation techniques allow access to system resources, such as specific memory regions, to be authorized or restricted. Access is considered "illegal" when a transaction does not comply with the access restrictions established by the respective access rights. Resource isolation techniques in this context are commonly referred to as "firewalls."
[0003] In conventional resource isolation techniques, for example as described in publication FR 3103586 Al (28 / 05 / 2021), firewalls may be provided on the memory controller to provide runtime protection, depending on the execution context, for example defined by a compartmentalization identifier “CID”, a security level, and / or a privilege level.
[0004] For example, a first type of firewall can be adapted for the protection of RISUP slave devices (Figures 1 and 2) to filter which context can access the controller in order to send commands to external memory to read, write, or erase data. This first type of RISUP firewall does not check the commands sent to memory, but only which context accesses the controller at runtime.
[0005] A second type of firewall can be adapted to protect AF RIS slave addresses (Figures 1 and 2), to filter which memory regions can be accessed by which contexts at runtime.
[0006] That being said, these firewalls are not typically capable of limiting access to external memory based on a system-on-chip security level specific to the boot process, and which evolves as the boot process progresses.
[0007] Indeed, during the system-on-chip startup process, the system-on-chip security level has fewer and fewer access permissions, so as to "lock" the secrets, that is, make them inaccessible, as they were used.
[0008] However, since conventional firewalls do not allow filtering based on the security level of the system-on-chip, it is possible that a command from an authorized context may act on a memory region that should be protected during the boot process.
[0009] Thus, there is a need to strengthen the protection mechanisms of external system-on-chip memories, particularly in the context of the boot process and with regard to the security level of the system-on-chip.
[0010] According to one aspect, a system-on-chip is proposed in this regard comprising a memory controller adapted to receive transactions containing transaction information defining access to a memory, for example, an external memory, the memory controller being configured to store the transaction information in a control register, and to drive access to the memory from the contents of said control register, wherein the memory controller includes verification means configured to condition access to the memory based on a comparison between the transaction information stored in the control register and a list of special information defining special transactions, for example, prohibited transactions or allowed transactions.
[0011] Thus, the memory controller itself implements an additional protection mechanism against special transactions (i.e., the list of special information), in addition to any firewalls. This additional protection can therefore compensate for a gap in the protection established by firewalls, particularly during the boot process.
[0012] According to one embodiment, the verification means are configured to receive a system-on-chip security level, and to perform said conditioning of memory access according to the system-on-chip security level.
[0013] This makes it possible to ensure the security of the system on chip according to the level of security of the system, in particular in such a way as to take into account its evolution during the system boot process.
[0014] It is understood that the security level corresponds to an evolving security level that is automatically modified as the boot process progresses, so as to have increasingly restricted access. For example, the security level evolves over time so as to block access to memory regions containing boot process information as soon as this information has been used in the boot process.
[0015] It should also be noted that the evolving security level automatically changes The contexts used in the startup process do not correspond to "secure" or "insecure" contexts, nor to "privileged" or "non-privileged" contexts, which are conventionally filtered by RISUP and RISAF firewalls. These contexts are typically assigned to each device (master, resource, peripheral, etc.), possibly controlled by an access rights management mechanism. In any case, secure / privileged contexts are not conventionally designed to be automatically modified during the startup process.
[0016] According to one embodiment, the list of special information defining special transactions is made respectively for each possible security level of the system-on-chip.
[0017] According to one embodiment, the verification means are configured to perform said conditioning so that access is blocked if at least one of said transaction information stored in the order register belongs to said special information list; or if at least one of said transaction information stored in the order register does not belong to said special information list.
[0018] According to one embodiment, the special information list is established on at least one of the following types of transaction information: a pre-established command of an action in memory; a memory region address; a memory region size.
[0019] According to another aspect, a method for controlling a memory, implemented by a memory controller of a system-on-a-chip, is also proposed, comprising receiving transactions containing transaction information defining a respective access to the memory, storing the received transaction information in a control register, access to the memory being driven from the contents of said control register, the method further comprising conditioning access to the memory based on a comparison between the transaction information stored in the control register and a list of special information defining special transactions, for example prohibited transactions or allowed transactions.
[0020] According to one embodiment, the method includes receiving a security level of the system-on-chip, and wherein said access conditioning is performed according to the security level of the system-on-chip.
[0021] According to one embodiment, the list of special information defining special transactions is made respectively for each possible security level of the system-on-chip.
[0022] According to one embodiment, said conditioning is carried out such that Access is blocked if at least one of the said transaction information stored in the order register belongs to said special information list, or if at least one of said transaction information stored in the order register does not belong to said special information list.
[0023] According to one embodiment, the special information list is established on at least one of the following types of transaction information: a pre-established command of an action in memory; a memory region address; a memory region size.
[0024] Other advantages and features of the invention will become apparent upon examination of the detailed description of embodiments and implementations, which are by no means limiting, and the accompanying drawings, in which:
[0025] [Fig. 1] and;
[0026] [Fig.2] and;
[0027] [Fig.3] illustrate embodiments and implementations of the invention.
[0028] Fig. 1 schematically illustrates an example of an implementation of a system-on-chip (SoC), such as a microcontroller or microprocessor, comprising a CPU master device and a CNTMEM memory controller intended to control access to a MEM memory, for example, an external non-volatile "Flash" or "EEPROM" memory.
[0029] The MEM memory is for example connected to the CNTMEM memory controller of the system on chip SOC, via an IOS input / output interface.
[0030] The CPU master device can, for example, be a processor or a central processing unit (for "Central Processing Unit" in English), adapted to implement software functionalities; or a master device of the type of direct memory access means "DMA" (for "Direct Memory Access" in English).
[0031] The master CPU device is for example the origin of accesses to the MEM memory, by TRI, TR2 transactions communicated on an interconnection bus BUS to the CNTMEM memory controller.
[0032] The interconnection bus can, for example, be a bus of the "AXI" type for "Advanced extensible Interface" in English, or of the "AHB" type for "Advanced High-performance Bus" in English, which are types of "AMBA" microcontroller bus for "Advanced Microcontroller Bus Architecture".
[0033] Each transaction TRI, TR2 contains TINF transaction information defining a respective access to the MEM memory. The TINF transaction information may, for example, contain information on the access type (cmd) for reading, writing, or possibly erasing; an identification of the MEM memory region with a starting address (addr) and a size (dlen); data (data) for writing; and other transaction information such as "status" and "Ctrl".
[0034] Furthermore, it is considered that to access the MEM memory, there is a first type of transaction TRI based on a command communicated to the CNTMEM controller; and a second type of transaction TR2 based on an address or a region of memory, for example according to a partition (or "mapping") of the MMAP memory (usually "memory map" in English).
[0035] For example, a first RISUP firewall may be provided to allow or restrict access to the CNTMEM controller by transactions of the first type TRI, that is, according to the access rights to the memory of the master CPU device with respect to an execution context; and a second RISAF firewall may be provided to allow or restrict access to the CNTMEM controller by transactions of the second type TR2, that is, according to the access rights to each MMAP memory region respectively by the master CPU device.
[0036] That being said, the two types of transactions TRI, TR2 contain the said transaction information TINF which defines access.
[0037] In both cases also, the CNTMEM memory controller is configured to store TINF transaction information in a REG control register, and to drive access to MEM memory from the contents of said REG control register.
[0038] In addition, the CNTMEM memory controller includes internally CMP verification means configured to condition the effective access ACC to the MEM memory, based on a comparison between the transaction information stored in the REG control register and a list of special information LST.
[0039] Each special piece of information in the LST list defines, for example, a prohibited transaction, or an ACC prohibited access to MEM memory.
[0040] For example, the CMP verification means are configured in this respect to block DEN access if at least one of said transaction information stored in the REG command register belongs to said prohibited information list LST.
[0041] Alternatively, each special piece of information in the LST list defines, for example, an authorized transaction, or an authorized ACC access to MEM memory.
[0042] For example, the CMP verification means are configured in this respect to block DEN access if at least one of said transaction information stored in the REG command register does not belong to said list of authorized information LST.
[0043] Depending on the design choice (in particular the exhaustiveness) of the special information list, the CMP verification means can be configured to block DEN access if none of said transaction information stored in the command register REG belongs to said authorized information list LST.
[0044] Advantageously, the CMP verification means are configured to perform said conditioning of memory access according to the security level of the system-on-chip SOC_LVL; and for example the special information list LST can be made respectively for each possible SOC_LVL security level of the system-on-chip SOC.
[0045] In this regard, each element of the LST list is for example linked to an identification of the security level r_lvl, d_lvl ([Fig.2]).
[0046] The security level of the system-on-chip (SOC_LVL) is, for example, communicated via a dedicated hardware-based internal bus in a centralized manner for the system-on-chip (SOC). It should be noted in particular that the SOC_LVL security level cannot be modified by software programming.
[0047] The SOC_LVL security level (or LVL0-LVL3 - [Fig. 3]) corresponds, for example, in practice to an evolving security level that is automatically modified as the boot process progresses, so as to have increasingly restricted access. For example, the security level evolves over time so as to block access to memory regions containing boot process information as soon as this information has been used in the boot process.
[0048] It should also be noted that the evolving security level SOC_LVL does not correspond to the "secure" or "insecure" contexts, nor to the "privileged" or "non-privileged" contexts, which are conventionally filtered by RISUP and RISAF firewalls. Indeed, secure / privileged contexts are typically assigned to each device (master, resource, peripheral, etc.), possibly in a manner controlled by a software access rights management mechanism.
[0049] The special information list LST is established on at least one of the following types of transaction information: a pre-established command of an action in memory cmd; a memory region address addr; a memory region size dlen.
[0050] In a first example, illustrated by [Fig. 1], each element of the LST special information list includes a memory region start address r_addr and a memory region size r_dlen.
[0051] Thus, in this first example, the additional CMP verification means have been integrated directly internally into the CNTMEM memory controller. The CMP verification means provide additional firewall-type protection on a number N of regions (depending on the product) of the MEM memory.
[0052] Each region is thus defined by an address r_addr and a length r_dlen, depending on the external memory and the protocol used (for example, it may be a raw address, a page address, or a block address); as well as by the lowest allowed security level r_lvl, or the first unauthorized level r_lvl, depending on the desired logic.
[0053] The configuration of regions in the LST list can be locked so that they are never reconfigured or overridden by another software component.
[0054] Regardless of the transaction type (TRI, TR2, whether transmitted via a command or accessed through segmentation / mapping), the transaction address addr, loaded into the command register REG, is compared to the addresses r_addr contained in the LST list. If the addr address belongs to a region of the LST list, the current system-on-chip security level SOC_LVL is compared to the security level r_lvl corresponding to the address identified as "r_addrcaddr". If the current security level SOC_LVL is higher than that of the region identified as r_lvl, the transaction is authorized (ACC); otherwise, it is blocked or rejected (DEN), and the CNTMEM memory controller may return an error.
[0055] The same verification process can be performed for the last address of the transaction, which is equal to the starting address plus the length of the data addr+dlen. If the last address of the transaction is outside all regions of the LST list, then the transaction is ACC authorized.
[0056] Fig. 2 illustrates a second example, in which each element of the LST special information list includes a pre-established command for an action in the d_cmd memory.
[0057] In the second example, the additional CMP verification means have also been integrated directly internally into the CNTMEM memory controller, in order to offer additional protection of the firewall or "blacklist" type (list of prohibited commands), or "whitelist" type (list of allowed commands), on a number M of commands (depending on the product).
[0058] The predefined commands d_cmd can, for example, be encoded on 8 bits, depending on the external memory or the protocol used. For example, they can be commands to erase memory sectors, or even the entire memory. The region to be protected can be different from the memory sector impacted by the command, since these commands can be sent with an addr address that does not correspond to the region to be protected DAT_LVL0-DAT_LVL3 (in the case of [Fig. 1]), while still impacting the region to be protected, for example DAT_LVL0, typically when the region to be protected is located within the sector.
[0059] Each command in the d_cmd list is linked to the lowest allowed security level r_lvl, or the first unauthorized level r_lvl depending on the desired logic.
[0060] The configuration of commands in the LST list can be locked so that they are never reconfigured after initialization to ensure that nobody will modify it during execution.
[0061] Regardless of the transaction type TRI, TR2 (by command or by identification of a segmentation / mapping) the transaction information that defines a cmd command, i.e. an action in memory, located in the command register REG, is compared to the special d_cmd commands contained in the LST list.
[0062] If the transaction information that defines the cmd command belongs to the LST list, the current security level of the system-on-chip SOC_LVL is compared to the d_lvl security level that corresponds to the command identified as "cmd=d_cmd".
[0063] In an alternative where the special command list LST contains prohibited commands d_cmd, if the current security level SOC_LVL is lower (i.e., having more restricted access) than that of the identified command d_lvl, then the transaction is blocked or rejected DEN, and the CNTMEM memory controller may return an error.
[0064] Otherwise, if the current security level SOC_LVL is higher (i.e., has more permission) than that of the identified command d_lvl, or if the transaction information that defines the command cmd does not belong to the list of prohibited commands LST, then the command cmd is allowed and the transaction is executed normally, i.e. the CNTMEM memory controller drives the ACC access to the MEM memory.
[0065] In another alternative where the special command list LST contains authorized commands d_cmd, if the current security level SOC_LVL is greater than or equal to (i.e. has equivalent or greater permission) than that of the identified command d_lvl, then the command cmd is authorized and the transaction is executed normally, i.e. the CNTMEM memory controller drives the ACC access to the MEM memory.
[0066] Otherwise, if the current security level SOC_LVL is lower (i.e., having more restricted access) than that of the identified command d_lvl, or if the transaction information that defines the command cmd does not belong to the list of allowed commands LST, is blocked or rejected DEN, and the CNTMEM memory controller may return an error.
[0067] The list of special LST commands can be a simple set of registers. The number "M" of registers depends on the product requirements.
[0068] Figure 3 illustrates an example of the system-on-chip (SOC) boot process, as described above in relation to Figures 1 and 2, during which a system-on-chip security level LVL0-LVL3 evolves as the boot process progresses.
[0069] In particular, it should be noted that the LVL0-LVL3 security level (or SOC_LVL - Figures 1 and 2) evolves over time so as to have increasingly restricted access, in particular to block access to memory regions containing information from the startup process, as soon as this information has been used in the startup process.
[0070] It should be noted that in this example, the numerical values representing the LVL0-LVL3 security levels are incremented as the security level decreases, i.e. as the context has fewer and fewer access permissions.
[0071] Thus for example, during a Bootrom startup initialization step the initial startup code is loaded from a fixed location in the external MEM memory immediately available to the processor when execution starts, for example the DAT_LVL0 location.
[0072] In the context of this very first Bootrom stage, the LVL0 security level has the most access permissions possible, and all DAT_LVL0-DAT_LVL3 memory regions (and therefore all possible secrets they contain) are accessible.
[0073] Then, for example, a first-stage bootloader FSBL step is implemented.
[0074] In the context of this first FSBL boot phase, the LVL1 security level corresponds to a secure boot level, in which the secrets of the Bootrom boot initialization step are no longer used and are therefore hidden. For this purpose, access to the DAT_LVL0 memory region corresponding to the Bootrom context is blocked (DEN). The other memory regions, DAT_LVL1-DAT_LVL3, are accessible.
[0075] Next, for example, a SecOS step of executing a secure operating system is implemented.
[0076] In the context of the SecOS secure operating system, security level LVL2 corresponds to a secure level in which secrets from the first FSBL boot phase, such as specific keys, are no longer used and are therefore hidden. For this purpose, access to the DAT_LVL1 memory region corresponding to the FSBL context is blocked (DEN). Access to the DAT_LVL0 memory region of the Bootrom context is also blocked (DEN). The other memory regions, DAT_LVL2-DAT_LVL3, are accessible.
[0077] Then, for example SSBL steps, OS corresponding to an NSEC non-secure context are implemented.
[0078] In the unsecure NSEC context, the LVL3 security level corresponds to an unsecure level, in which only "secrets" usable by the unsecure operating system (OS) are accessible. For this purpose, access to the DAT_LVL2 memory region corresponding to the SecOS context is blocked (DEN). Access to the DAT_LVL1 and DAT_LVL1 memory regions of the preceding FSBL and Bootrom contexts is still blocked (DEN). The DAT_LVL3 memory region is accessible.
[0079] Of course, the startup process described above corresponds to a simplified example, for illustrative purposes.
[0080] In summary, embodiments and implementations of an internal mechanism within the CNTMEM memory controller have been described for implementing additional protections of sensitive memory regions DAT_LVL0-DAT_LVL3, using the LST (List of Forbidden or Allowed Transactions), in addition to any conventional RISUP-RISAF firewalls of the system-on-a-chip (SOC). This additional CMP (Computer-Mixed Protection) can thus fill a gap in protection, particularly during the boot process, and is adaptable to all types of products.
Claims
Demands
1. System on chip (SOC) comprising a memory controller (CNTMEM) adapted to receive transactions (TRI, TR2) containing transaction information (TINF) defining access to a memory (MEM), the memory controller (CNTMEM) being configured to store the transaction information in a control register (REG), and to drive access to the memory (MEM) from the contents of said control register (REG), wherein the memory controller (CNTMEM) includes verification means (CMP) configured to condition access to the memory based on a comparison between the transaction information stored in the control register (REG) and a special information list (LST) defining special transactions;in which the verification means (CMP) are configured to receive a system-on-chip security level (SOC_LVL), and to perform said conditioning of memory access according to the system-on-chip security level; and in which the special information list (LST) defining special transactions is made respectively for each possible system-on-chip security level (SOC_LVL).
2. System on chip according to claim 1, wherein the verification means (CMP) are configured to perform said conditioning so that access is blocked (DEN) if at least one of said transaction information stored in the command register (REG) belongs to said special information list (LST), or if at least one of said transaction information stored in the command register (REG) does not belong to said special information list (LST).
3. System on chip according to any one of claims 1 or 2, wherein the special information list (LST) is established on at least one of the following types of transaction information: a pre-established command of an action in memory (cmd); a memory region address (addr); a memory region size (dlen).
4. A method for controlling a memory, implemented by a memory controller (CNTMEM) of a system-on-a-chip, comprising a transaction receiver (AC1, AC2) containing transaction information (TINF) defining a respective access to the memory (MEM), a storage transaction information received in a control register (REG), memory access being driven from the contents of said control register, the method further comprising conditioning memory access based on a comparison (CMP) between transaction information (TINF) stored in the control register (REG) and a special information list (LST) defining special transactions; the process comprising a system-on-chip security level (SOC_LVL) reception, and wherein said access conditioning is performed according to the system-on-chip security level; in which the special information list (LST) defining special transactions is made respectively for each possible security level (SOC_LVL) of the system-on-chip.
5. Method according to claim 4, wherein said conditioning is carried out so that access is blocked (DEN) if at least one of said transaction information stored in the order register (REG) belongs to said special information list (LST), or if at least one of said transaction information stored in the order register (REG) does not belong to said special information list (LST).
6. A method according to any one of claims 4 or 5, wherein the special information list (LST) is established on at least one of the following types of transaction information: a pre-established command of an action in memory (cmd); a memory region address (addr); a memory region size (dlen).