SYSTEM ON A CHIP WITH STORAGE CONTROL AND STORAGE CONTROL METHOD FOR THAT.

Description

[0001] Embodiments and implementations of the invention relate to integrated circuits such as systems on chips ("System on Chip" in English) including in particular a memory controller, for example external memory, and more particularly concerning permissions 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] EP 3 901 776 A1, US 11 281 810 B1 and FR 2 945 396 are relevant prior art documents.

[0004] In conventional resource isolation techniques, for example as described in publication FR 3103586 A1 (28 / 05 / 2021), firewalls can 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.

[0005] For example, a first type of firewall can be adapted to protect 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 delete data. This first type of RISUP firewall does not check the commands sent to memory, but only which context accesses the controller at runtime.

[0006] A second type of firewall can be adapted to protect RISAF slave addresses ( figures 1 And 2 ), to filter which memory regions can be accessed by which contexts at runtime.

[0007] That being said, these firewalls are not typically able to limit access to external memory based on a system-on-chip security level specific to the boot process, which evolves as the boot process progresses.

[0008] Indeed, during the system-on-chip boot 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 have been used.

[0009] However, since conventional firewalls do not allow filtering based on the system-on-chip security level, it is possible that a command from an authorized context could act on a memory region that should be protected during the boot process.

[0010] 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.

[0011] 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.

[0012] 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 extra protection can compensate for gaps in the protection provided by firewalls, particularly during the boot process.

[0013] 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.

[0014] This ensures the security of the system-on-chip according to the system security level, in particular to take into account its evolution during the system boot process.

[0015] The security level is understood to be an evolving security level that is automatically modified as the boot process progresses, resulting in increasingly restricted access. For example, the security level evolves over time to block access to memory regions containing boot process information as soon as that information has been used in the boot process.

[0016] It should also be noted that the evolving security level, which changes automatically during the startup process, 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, these contexts are typically assigned to each device (master, resource, peripheral, etc.), possibly in a manner controlled by an access rights management mechanism. In any case, the secure / privileged contexts are not conventionally designed to be automatically modified during the startup process.

[0017] 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.

[0018] 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.

[0019] 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.

[0020] According to another aspect, a method for controlling a memory is also proposed, implemented by a memory controller of a system-on-a-chip, 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.

[0021] According to one implementation method, the process includes receiving a system-on-chip security level, and wherein said access conditioning is performed according to the system-on-chip security level.

[0022] According to one implementation method, the list of special information defining special transactions is made respectively for each possible security level of the system-on-chip.

[0023] According to one implementation method, said conditioning is carried out 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.

[0024] According to one implementation method, 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.

[0025] 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: [ Fig.1 ] And ; [ Fig.2 ] And ; [ Fig.3 ] illustrate methods of embodiment and implementation of the invention.

[0026] The scope of the invention is defined by the independent claims.

[0027] There figure 1 schematically illustrates an example of the realization of a system on a 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.

[0028] For example, the MEM memory is connected to the CNTMEM memory controller of the system-on-chip (SOC) via an IOS input / output interface.

[0029] 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 "DMA" (for "Direct Memory Access" in English).

[0030] The master CPU device, for example, is the origin of accesses to the MEM memory, via TR1, TR2 transactions communicated on an interconnection bus BUS to the CNTMEM memory controller.

[0031] 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".

[0032] Each transaction TR1, TR2 contains TINF transaction information defining a respective access to the MEM memory. The TINF transaction information may, for example, contain information about 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 for writing (data); and other transaction information such as "status" and "ctrl".

[0033] Furthermore, it is considered that to access the MEM memory, there is a first type of transaction TR1 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).

[0034] For example, a first RISUP firewall can be designed to allow or restrict access to the CNTMEM controller by transactions of the first type TR1, that is, according to the access rights to the memory of the CPU master device with respect to an execution context; and a second RISAF firewall can be designed 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 CPU master device.

[0035] That being said, both types of transactions TR1, TR2 contain the aforementioned TINF transaction information which defines access.

[0036] In both cases, the CNTMEM memory controller is configured to store TINF transaction information in a REG command register, and to drive access to MEM memory from the contents of said REG command register.

[0037] In addition, the CNTMEM memory controller includes internal CMP verification means configured to condition the effective ACC access to MEM memory, based on a comparison between transaction information stored in the REG command register and a list of special information LST.

[0038] Each special entry in the LST list defines, for example, a forbidden transaction, or an ACC forbidden access to MEM memory.

[0039] For example, 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 LST prohibited information list.

[0040] Alternatively, each special piece of information in the LST list defines, for example, an authorized transaction, or an authorized ACC access to MEM memory.

[0041] For example, 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 LST list of allowed information.

[0042] Depending on the design choice (including 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 REG command register belongs to said LST authorized information list.

[0043] Advantageously, the CMP verification means are configured to perform said memory access conditioning according to the system-on-chip security level 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.

[0044] In this respect, each element of the LST list is, for example, linked to a security level identification r_lvl, d_lvl ( figure 2 ).

[0045] The security level of the system-on-chip (SOC_LVL) is communicated, for example, via a dedicated hardware-based internal bus and centrally for the SOC. It should be noted that the SOC_LVL security level cannot be modified through software programming.

[0046] The SOC_LVL security level (or LVL0-LVL3 - figure 3 This 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 to block access to memory regions containing boot process information as soon as that information has been used in the boot process.

[0047] 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.

[0048] The LST 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 cmd; a memory region address addr; a memory region size dlen.

[0049] In a first example, illustrated by the figure 1 , each item in the LST special information list includes a memory region start address r_addr and a memory region size r_dlen.

[0050] Thus, in this first example, the additional CMP verification methods have been integrated directly into the CNTMEM memory controller. The CMP verification methods provide additional firewall-type protection on a number N of regions (depending on the product) of the MEM memory.

[0051] Each region is thus defined by an address r_addr and a length r_dlen, according to 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.

[0052] The configuration of regions in the LST list can be locked so that they are never reconfigured or overridden by another software component.

[0053] Regardless of the transaction type (TR1, TR2, or command transmission or access via 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 in 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_addr⊂addr`. If the current SOC_LVL security level is higher than that of the identified region `r_lvl`, the transaction is authorized (ACC); otherwise, it is blocked or rejected (DEN), and the CNTMEM memory controller may return an error.

[0054] 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.

[0055] There figure 2 illustrates a second example, in which each element of the LST special information list has a pre-established command for an action in the d_cmd memory.

[0056] In the second example, we have also integrated the additional CMP verification means directly internally into the CNTMEM memory controller, in order to offer additional protection of the type of firewall or "blacklist" (list of prohibited commands), or "whitelist" (list of allowed commands), on a number M of commands (depending on the product).

[0057] The predefined d_cmd commands 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 may differ from the memory sector affected 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 the...). figure 1 ), while having an impact on the region to be protected, for example DAT_LVL0, typically when the region to be protected is located inside the sector.

[0058] 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.

[0059] The configuration of commands in the LST list can be locked so that they are never reconfigured after initialization to ensure that no one will modify them during execution.

[0060] Regardless of the transaction type TR1, 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.

[0061] If the transaction information that defines the cmd command belongs to the LST list, the current system-on-chip security level SOC_LVL is compared to the d_lvl security level that corresponds to the command identified as "cmd=d_cmd".

[0062] In an alternative scenario where the LST special command list contains prohibited d_cmd commands, if the current security level SOC_LVL is lower (i.e., having more restricted access) than that of the identified d_lvl command, then the transaction is blocked or rejected DEN, and the CNTMEM memory controller may return an error.

[0063] 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 LST list of prohibited commands, 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.

[0064] In another alternative where the LST special command list contains allowed d_cmd commands, 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 d_lvl command, then the cmd command is allowed and the transaction is executed normally, i.e., the CNTMEM memory controller drives ACC access to MEM memory.

[0065] 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.

[0066] The list of special LST commands can be a simple set of registers. The number "M" of registers depends on the product requirements.

[0067] There figure 3 illustrates an example of the system-on-chip (SOC) boot process, as described above in relation to the figures 1 And 2 , during which a system-on-chip security level LVL0-LVL3, evolves as the boot process progresses.

[0068] In particular, it is recalled that the security level LVL0-LVL3 (or SOC_LVL - figures 1 And 2 ) evolves over time so as to have increasingly restricted access, in particular so as to block access to memory regions containing boot process information, as soon as this information has been used in the boot process.

[0069] Note 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.

[0070] 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 begins, for example, location DAT_LVL0.

[0071] 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.

[0072] Next, for example, an FSBL step called the first stage bootloader (usually "first stage bootloader" in English) is implemented.

[0073] In the context of this initial FSBL boot phase, the LVL1 security level corresponds to a secure boot level in which the secrets of the Bootrom initialization step are no longer used and are therefore hidden. To this end, access to the DAT_LVL0 memory region corresponding to the Bootrom context is blocked (DEN). The other memory regions, DAT_LVL1-DAT_LVL3, remain accessible.

[0074] Next, for example, a SecOS step of executing a secure operating system is implemented.

[0075] In the context of the SecOS secure operating system, security level LVL2 corresponds to a secure level in which the secrets of 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, remain accessible.

[0076] Then, for example, SSBL steps, OS corresponding to an insecure NSEC context are implemented.

[0077] In the unsecured NSEC context, security level LVL3 corresponds to an unsecured level, in which only "secrets" usable by the unsecured operating system (OS) are accessible. Therefore, access to the DAT_LVL2 memory region corresponding to the SecOS context is blocked (DEN). Access to the DAT_LVL0-DAT_LVL1 memory regions of the preceding FSBL and Bootrom contexts is also blocked (DEN). The DAT_LVL3 memory region is accessible.

[0078] Of course, the startup process described above is a simplified example, intended for illustrative purposes.

[0079] In summary, embodiments and implementation methods have been described for an internal mechanism within the CNTMEM memory controller to implement additional protections for 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 (Controller-Memory Protection) can thus fill a gap in protection, particularly during the boot process, and is adaptable to all types of products.

Claims

1. System on Chip (SoC) comprising a memory controller (CNTMEM) adapted to receive transactions (TR1, TR2) containing transaction information (TINF) defining access to a memory (MEM), the memory controller (CNTMEM) being configured to store the transaction information in a command register (REG), and to control access to the memory (MEM) from the content of said command register (REG), wherein the memory controller (CNTMEM) comprises verification means (CMP) configured to condition access to the memory as a function of a comparison between the transaction information stored in the command register (REG) and a list of special information (LST) defining special transactions; wherein the verification means (CMP) are configured to receive a security level of the System on Chip (SOC_LVL) and to perform said conditioning of the access to the memory according to the security level of the System on Chip; and wherein the list of special information (LST) defining special transactions is made respectively for each possible security level (SOC_LVL) of the System on Chip.

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 pieces of transaction information stored in the command register (REG) belongs to the list of special information (LST), or if at least one piece of transaction information stored in the command register (REG) does not belong to said list of special information (LST).

3. System on Chip according to any one of claims 1 or 2, wherein the list of special information (LST) is established on at least one of the following types of transaction information: a pre-established command for an action in the memory (cmd); a memory region address (addr); a memory region size (dlen).

4. Method for controlling a memory, implemented by a memory controller (CNTMEM) of a System on Chip, comprising receiving transactions (AC1, AC2) containing transaction information (TINF) defining a respective access to the memory (MEM), storing the transaction received information in a command register (REG), the access to the memory being driven on the basis of the content of said command register, the method further comprising conditioning the access to the memory as a function of a comparison (CMP) between the transaction information (TINF) stored in the command register (REG) and a list of special information (LST) defining special transactions; the method comprising the reception of a security level of the System on Chip (SOC_LVL), and wherein said conditioning of the access is performed according to the security level of the System on Chip; wherein the list of special information (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 pieces of transaction information stored in the command register (REG) belongs to the list of special information (LST), or if at least one piece of transaction information stored in the command register (REG) does not belong to said list of special information (LST).

6. Method according to any one of claims 4 or 5, wherein the list of special information (LST) is established on at least one of the following types of transaction information: a pre-established command for an action in the memory (cmd); a memory region address (addr); a memory region size (dlen).