EP4459493A1 - Système sur puce comportant un contrôleur de mémoire et procédé de contrôle de mémoire correspondant - Google Patents

Système sur puce comportant un contrôleur de mémoire et procédé de contrôle de mémoire correspondant Download PDF

Info

Publication number
EP4459493A1
EP4459493A1 EP24172620.7A EP24172620A EP4459493A1 EP 4459493 A1 EP4459493 A1 EP 4459493A1 EP 24172620 A EP24172620 A EP 24172620A EP 4459493 A1 EP4459493 A1 EP 4459493A1
Authority
EP
European Patent Office
Prior art keywords
memory
access
chip
list
lst
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
EP24172620.7A
Other languages
German (de)
English (en)
Other versions
EP4459493B1 (fr
Inventor
Loic Pallardy
Vincent Berthelot
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
STMicroelectronics International NV Switzerland
STMicroelectronics International NV
Original Assignee
STMicroelectronics International NV Switzerland
STMicroelectronics International NV
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by STMicroelectronics International NV Switzerland, STMicroelectronics International NV filed Critical STMicroelectronics International NV Switzerland
Publication of EP4459493A1 publication Critical patent/EP4459493A1/fr
Application granted granted Critical
Publication of EP4459493B1 publication Critical patent/EP4459493B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/76Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information in application-specific integrated circuits [ASIC] or field-programmable devices, e.g. field-programmable gate arrays [FPGA] or programmable logic devices [PLD]
    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14Protection against unauthorised use of memory or access to memory
    • G06F12/1458Protection against unauthorised use of memory or access to memory by checking the subject access rights
    • G06F12/1491Protection against unauthorised use of memory or access to memory by checking the subject access rights in a hierarchical protection system, e.g. privilege levels, memory rings
    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00Accessing, addressing or allocating within memory systems or architectures
    • G06F12/14Protection against unauthorised use of memory or access to memory
    • G06F12/1458Protection against unauthorised use of memory or access to memory by checking the subject access rights
    • G06F12/1483Protection against unauthorised use of memory or access to memory by checking the subject access rights using an access-table, e.g. matrix or list
    • GPHYSICS
    • G06COMPUTING OR CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/78Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data

Definitions

  • Embodiments and implementations of the invention relate to integrated circuits such as systems on chips (System on Chip) including in particular a memory controller, for example an external memory, and more particularly relating to authorizations and restrictions of access to memory regions of the memory.
  • a memory controller for example an external memory
  • resource isolation techniques allow to authorize or restrict access to system resources, and for example particular memory regions. We speak of an "illegal" access when a transaction does not comply with the access restrictions established by respective access rights. Resource isolation techniques in this context are usually called “firewalls”.
  • 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 by a privilege level.
  • CID compartmentalization identifier
  • a first type of firewall can be adapted to the protection of RISUP slave device ( 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.
  • a second type of firewall can be adapted to protect RISAF slave addresses ( figures 1 And 2 ), to filter which regions memory can be accessed by which contexts at runtime.
  • 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.
  • the system-on-chip security level has less and less access permission, so as to "lock" the secrets, i.e. make them inaccessible, as they have been used.
  • a system on chip comprising a memory controller adapted to receive transactions containing transaction information defining an 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 control access to the memory from the content of said control register, in which the memory controller comprises verification means configured to condition access to the memory according to 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 authorized transactions.
  • the verification means are configured to receive a security level of the system on chip, and to perform said conditioning of access to the memory according to the security level of the system on chip.
  • the security level is understood to correspond 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.
  • the evolving security level that changes automatically during the boot process does not correspond to the "secure” or “non-secure” contexts, nor to the "privileged" or “non-privileged” contexts, which are conventionally filtered by RISUP, RISAF firewalls. Indeed, said contexts are typically assigned for each device (master, resource, peripheral, etc.), possibly in a manner controlled by an access rights management mechanism. In any event, the secure/privileged contexts are conventionally not adapted to be automatically modified during the boot process.
  • the list of special information defining special transactions is made respectively for each possible security level of the system on chip.
  • 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 list of special information; or if at least one of said transaction information stored in the order register does not belong to said list of special information.
  • the special information list is based on at least one of the following types of transaction information: a pre-established command of an action in the memory; a memory region address; a memory region size.
  • a method of controlling a memory comprising receiving transactions containing transaction information defining a respective access to the memory, storing the received transaction information in a control register, the access to the memory being controlled from the content of said control register, the method further comprising conditioning the 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 authorized transactions.
  • the method comprises receiving a security level of the system on chip, and wherein said conditioning of access is carried out according to the security level of the system on chip.
  • the list of special information defining special transactions is made respectively for each possible security level of the system on chip.
  • said conditioning is performed such that access is blocked if at least one of said transaction information stored in the control register belongs to said list of special information, or if at least one of said transaction information stored in the control register does not belong to said list of special information.
  • the special information list is based on at least one of the following types of transaction information: a pre-established command of an action in the memory; a memory region address; a memory region size.
  • FIG. 1 schematically illustrates an exemplary embodiment of a system on chip SOC, such as for example a microcontroller or a microprocessor, comprising a master device CPU, and a memory controller CNTMEM intended to control accesses to a memory MEM, for example a non-volatile external memory “Flash” or "EEPROM”.
  • SOC system on chip SOC
  • a microcontroller or a microprocessor comprising a master device CPU, and a memory controller CNTMEM intended to control accesses to a memory MEM, for example a non-volatile external memory “Flash” or "EEPROM”.
  • the MEM memory is for example connected to the CNTMEM memory controller of the SOC system on chip, via an IOS input-output interface.
  • the master device CPU may 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 direct memory access means type “DMA” (for “Direct Memory Access” in English).
  • the master device CPU is for example at the origin of accesses to the MEM memory, by transactions TR1, TR2 communicated on an interconnection bus BUS to the memory controller CNTMEM.
  • the interconnection bus BUS can for example be a bus of the type "AXI” for “Advanced eXtensible Interface” in English, or of the type “AHB” for “Advanced High-performance Bus” in English, which are types of microcontroller buses “AMBA” for “Advanced Microcontroller Bus Architecture”.
  • Each transaction TR1, TR2 contains transaction information TINF defining a respective access to the memory MEM.
  • the transaction information TINF can for example contain information on the type of access cmd in reading, writing or possibly erasing; an identification of the memory region MEM with a start address addr and a size dlen; data data in writing; and other transaction information "status", "ctrl”.
  • first type of transaction TR1 based on a command communicated to the CNTMEM controller
  • second type of transaction TR2 based on an address or a region of the memory, for example according to a partition (or “mapping”) of the MMAP memory (usually “memory map” in English).
  • a first RISUP firewall may be provided to authorize or restrict access to the CNTMEM controller by transactions of the first type TR1, i.e. according to the access rights to the memory of the master device CPU with respect to an execution context; and a second RISAF firewall may be provided to authorize or restrict access to the CNTMEM controller by transactions of the second type TR2, i.e. according to the access rights to each memory region MMAP by the master device CPU.
  • both types of transactions TR1, TR2 contain the so-called TINF transaction information which defines the access.
  • the memory controller CNTMEM is configured to store the transaction information TINF in a control register REG, and to control access to the memory MEM from the contents of said control register REG.
  • the CNTMEM memory controller internally includes 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 command register REG and a list of special information LST.
  • Each special information in the LST list defines, for example, a prohibited transaction, or a prohibited ACC access to the MEM memory.
  • the CMP verification means are configured in this regard to block DEN access if at least one of said transaction information stored in the command register REG belongs to said list of prohibited information LST.
  • each special information in the LST list defines, for example, an authorized transaction, or an authorized ACC access to the MEM memory.
  • the CMP verification means are configured in this regard to block DEN access if at least one of said transaction information stored in the command register REG does not belong to said list of authorized information LST.
  • 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.
  • the verification means CMP are configured to perform said conditioning of the access to the memory according to the security level of the system on chip SOC_LVL; and for example the list of special information LST can be made respectively for each possible security level SOC_LVL of the system on chip SOC.
  • each element of the LST list is for example linked to an identification of the security level r_lvl, d_lvl ( figure 2 ).
  • the security level of the system on chip SOC_LVL is for example communicated by a hardware-dedicated internal bus and centrally for system on chip SOC. It should be noted in particular that the security level SOC_LVL is not modifiable by software programming.
  • the security level SOC_LVL (or LVL0-LVL3 - figure 3 ) corresponds for example in practice to an evolving security level which is automatically modified during the boot process, so as to have increasingly restricted access.
  • the security level evolves temporally so as to block access to memory regions containing information from the boot process, as soon as this information has been used in the boot process.
  • the scalable security level SOC_LVL does not correspond to the "secure” or “non-secure” contexts, nor to the "privileged" or “non-privileged” contexts, which are conventionally filtered by RISUP, RISAF firewalls.
  • the secure/privileged contexts are typically assigned for each device (master, resource, peripheral, etc.), possibly in a manner controlled by a software mechanism for managing access rights.
  • the special information list LST is based on at least one of the following types of transaction information: a pre-established command for an action in memory cmd; a memory region address addr; a memory region size dlen.
  • each element of the special information list LST includes a memory region start address r_addr and a memory region size r_dlen.
  • the CMP verification means provide additional firewall-type protection, on a number N of regions (depending on the product) of the MEM memory.
  • Each region is thus defined by an address r_addr and a length r_dlen, depending on the external memory protocol used (for example it can be a raw address, a page address or a block address); as well as by the lowest authorized security level r_lvl, or the first unauthorized level r_lvl depending on the desired logic.
  • the configuration of regions in the LST list can be locked to never be reconfigured or overridden by another software component.
  • the transaction address addr loaded in the command register REG is compared to the addresses r_addr contained in the list LST. If the address addr belongs to a region of the list LST, the current security level of the system on chip SOC_LVL is compared to the security level r_lvl which corresponds to the identified address "r_addr ⁇ addr". If the current security level SOC_LVL is higher than that of the identified region r_lvl, the transaction is authorized ACC, otherwise it is blocked, or rejected, DEN and the memory controller CNTMEM can return an error.
  • the same verification process can be done for the last address of the transaction, equal to the start address added by the data length addr+dlen. If the last address of the transaction is outside all regions of the LST list, then the transaction is allowed ACC.
  • FIG. 2 illustrates a second example, in which each element of the special information list LST has a pre-established command for an action in the d_cmd memory.
  • 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 "black list” type (list of prohibited commands), or "white list” (list of authorized commands), on a number M of commands (depending on the product).
  • the pre-defined 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 can be different from the memory sector impacted by the command, since these commands can be sent with an addr address not corresponding 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.
  • Each command in the d_cmd list is bound to the lowest allowed security level r_lvl, or the first unauthorized level r_lvl depending on the desired logic.
  • the configuration of commands in the LST list can be locked to never be reconfigured after initialization to ensure that no one will change it during runtime.
  • TR2 (by command or by identification of a segmentation/mapping) the transaction information which defines a command cmd, that is to say an action in memory, located in the command register REG, is compared to the special commands d_cmd contained in the list LST.
  • the special command list LST contains forbidden commands d_cmd
  • 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 memory controller CNTMEM may return an error.
  • the cmd command is authorized and the transaction is executed normally, i.e. the memory controller CNTMEM controls the ACC access to the MEM memory.
  • the special command list LST contains authorized d_cmd commands
  • the security level current SOC_LVL is greater than or equal to (i.e. has the permission equivalent to or greater than) that of the identified command d_lvl
  • the command cmd is authorized and the transaction is executed normally, i.e. the memory controller CNTMEM drives the ACC access to the memory MEM.
  • the LST special command list can be a simple set of registers.
  • the number "M" of registers depends on the product needs.
  • FIG 3 illustrates an example of a system-on-chip (SOC) boot process as described above in connection with the figures 1 And 2 , during which a system-on-chip security level LVL0-LVL3 evolves as the boot process progresses.
  • SOC system-on-chip
  • the security level LVL0-LVL3 (or SOC_LVL - figures 1 And 2 ) evolves over time so as to have increasingly restricted accesses, in particular so as to block accesses to memory regions containing information from the boot process, as soon as this information has been used in the boot process.
  • the numerical values representing security levels LVL0-LVL3 are incremented as the security level decreases, that is, as the context has fewer and fewer access permissions.
  • the initial boot code is loaded from a fixed location in external memory MEM immediately available to the processor when execution begins, for example location DAT_LVL0.
  • security level LVL0 has the most access permissions possible, and all memory regions DAT_LVL0-DAT_LVL3 (and therefore all possible secrets they contain) are accessible.
  • first stage bootloader a FSBL step called first stage bootloader
  • the security level LVL1 corresponds to a secure boot level, in which the secrets of the Bootrom boot initialization step are no longer used, and are therefore hidden.
  • 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.
  • security level LVL2 corresponds to a secure level, in which secrets from the first boot phase FSBL, such as specific keys, are no longer used, and are therefore hidden.
  • access to the memory region DAT_LVL1 corresponding to the FSBL context is blocked DEN.
  • Access to the memory region DAT_LVL0 of the Bootrom context is always blocked DEN.
  • the other memory regions DAT_LVL2-DAT_LVL3 are accessible.
  • the security level LVL3 corresponds to a non-secure level, in which only the "secrets" usable by the non-secure operating system OS are accessible.
  • access to the memory region DA T _ L VL2 corresponding to the SecOS context is blocked DEN.
  • Access to the memory regions DAT_LVL0-DAT_LVL1 of the previous contexts FSBL, Bootrom are always blocked DEN.
  • the memory region DAT_LVL3 is accessible.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Software Systems (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Storage Device Security (AREA)

Abstract

Le système sur puce (SOC) comporte un contrôleur de mémoire (CNTMEM) adapté pour recevoir des transactions (TR1, TR2) contenant des informations de transaction (TINF) définissant un accès à une mémoire (MEM), le contrôleur de mémoire (CNTMEM) étant configuré pour stocker les informations de transaction dans un registre de commande (REG), et pour piloter l'accès à la mémoire (MEM) à partir du contenu dudit registre de commande (REG). Le contrôleur de mémoire (CNTMEM) comporte des moyens de vérification (CMP) configurés pour conditionner l'accès à la mémoire en fonction d'une comparaison entre les informations de transaction stockées dans le registre de commande (REG) et une liste d'informations spéciales (LST) définissant des transactions spéciales.

Description

  • Des modes de réalisation et de mise en oeuvre de l'invention concernent les circuits intégrés tels que les systèmes sur puce (« System on Chip » en anglais) comportant notamment un contrôleur de mémoire, par exemple une mémoire externe, et plus particulièrement concernant des autorisations et restrictions d'accès à des régions mémoires de la mémoire.
  • En effet, pour contribuer à garantir la sécurité des systèmes sur puce, des techniques d'isolation des ressources permettent de d'autoriser ou restreindre l'accès à des ressources du système, et par exemple des régions mémoires particulières. On parle d'un accès « illégal » lorsqu'une transaction n'est pas conforme aux restrictions d'accès établies par des droits d'accès respectifs. Les techniques d'isolation des ressources dans ce cadre sont usuellement appelées « pare-feu ».
  • Dans les techniques d'isolation des ressources conventionnelles, par exemple telle que décrite dans la publication FR 3103586 A1 (28/05/2021 ), des pares-feux peuvent être prévus sur le contrôleur de mémoire pour fournir une protection en cours d'exécution, en fonction du contexte d'exécution, par exemple définit par un identifiant de compartimentation « CID », un niveau de sécurité, et/ou par un niveau de privilège.
  • Par exemple, un premier type de pare-feu peut être adapté à la protection de dispositif esclave RISUP (figures 1 et 2), pour filtrer quel contexte peut accéder au contrôleur afin d'envoyer des commandes à la mémoire externe pour lire, écrire ou effacer des données. Ce premier type de pare-feu RISUP ne vérifie pas les commandes envoyées à la mémoire, mais seulement quel contexte accède au contrôleur au moment de l'exécution.
  • Un deuxième type de pare-feu peut être adapté à la protection d'adresses esclaves RISAF (figures 1 et 2), pour filtrer quelles régions de la mémoire peuvent être accédées par quels contextes au moment de l'exécution.
  • Cela étant, ces pares-feux ne sont classiquement pas capables de limiter les accès à la mémoire externe en fonction d'un niveau de sécurité du système sur puce spécifique au processus de démarrage, et qui évolue au fur et à mesure de l'avancée du processus de démarrage.
  • En effet, lors du processus de démarrage du système sur puce, le niveau de sécurité du système sur puce a de moins en moins de permission d'accès, de manière à « verrouiller » les secrets, c'est-à-dire les rendre inaccessibles, au fur et à mesure qu'ils ont été utilisés.
  • Or, comme les pares-feux conventionnels ne permettent pas de filtrer en fonction du niveau de sécurité du système sur puce, il est possible qu'une commande provenant d'un contexte autorisé, agisse sur une région mémoire qui devrait être protégée pendant le processus de démarrage.
  • Ainsi, il existe un besoin de renforcer les mécanismes de protection des mémoires externes de système sur puce, notamment dans le cadre du processus de démarrage et vis-à-vis du niveau de sécurité du système sur puce.
  • Selon un aspect, il est proposé à cet égard un système sur puce comportant un contrôleur de mémoire adapté pour recevoir des transactions contenant des informations de transaction définissant un accès à une mémoire, par exemple une mémoire externe, le contrôleur de mémoire étant configuré pour stocker les informations de transaction dans un registre de commande, et pour piloter l'accès à la mémoire à partir du contenu dudit registre de commande, dans lequel le contrôleur de mémoire comporte des moyens de vérification configurés pour conditionner l'accès à la mémoire en fonction d'une comparaison entre les informations de transaction stockées dans le registre de commande et une liste d'informations spéciales définissant des transactions spéciales, par exemple des transactions interdites ou des transactions autorisées.
  • Ainsi, c'est le contrôleur de mémoire lui-même qui met en oeuvre un mécanisme de protection supplémentaire vis-à-vis des transactions spéciales (i.e. la liste d'informations spéciales), en outre des éventuels pares-feux. Cette protection supplémentaire peut ainsi permettre de compléter un manque dans la protection établie par les pares-feux, notamment dans le cadre du processus de démarrage.
  • Selon un mode de réalisation, les moyens de vérification sont configurés pour recevoir un niveau de sécurité du système sur puce, et pour effectuer ledit conditionnement de l'accès à la mémoire en fonction du niveau de sécurité du système sur puce.
  • Cela permet d'assurer la sécurité du système sur puce en fonction du niveau de sécurité du système, en particulier de manière à tenir compte de son évolution lors du processus de démarrage du système.
  • On entend que le niveau de sécurité correspond à un niveau de sécurité évolutif qui est automatiquement modifié dans l'avancée du processus de démarrage, de façon à avoir des accès de plus en plus restreints. Par exemple, le niveau de sécurité évolue temporellement de façon à bloquer les accès aux régions mémoires contenant des informations du processus de démarrage, dès que ces informations ont été utilisées dans le processus de démarrage.
  • On notera par ailleurs que le niveau de sécurité évolutif se modifiant automatiquement dans le processus de démarrage, ne correspond pas aux contextes « sécurisé » ou « non-sécurisé », ni aux contextes « privilégiés » ou « non-privilégiés », qui sont conventionnellement filtrés par les pares-feux RISUP, RISAF. En effet lesdits contextes sont typiquement attribués pour chaque dispositif (maître, ressource, périphérique...), éventuellement de façon commandée par un mécanisme de gestion des droits d'accès. En tout état de cause, les contexte sécurisé/privilégié ne sont conventionnellement pas adaptés à être automatiquement modifiés dans l'avancée du processus de démarrage.
  • Selon un mode de réalisation, la liste d'informations spéciales définissant des transactions spéciales est faite respectivement pour chaque niveau de sécurité possible du système sur puce.
  • Selon un mode de réalisation, les moyens de vérification sont configurés pour effectuer ledit conditionnement de sorte que l'accès est bloqué si au moins l'une desdites informations de transaction stockées dans le registre de commande appartient à ladite liste d'informations spéciales ; ou bien si au moins l'une desdites informations de transaction stockées dans le registre de commande n'appartient pas à ladite liste d'informations spéciales.
  • Selon un mode de réalisation, la liste d'informations spéciales est établie sur au moins l'un des types d'informations de transaction suivants : une commande préétablie d'une action dans la mémoire ; une adresse de région mémoire ; une taille de région mémoire.
  • Selon un autre aspect, il est également proposé un procédé de contrôle d'une mémoire, mis en oeuvre par un contrôleur de mémoire d'un système sur puce, comprenant une réception de transactions contenant des informations de transaction définissant un accès respectif à la mémoire, un stockage des informations de transaction reçues dans un registre de commande, l'accès à la mémoire étant piloté à partir du contenu dudit registre de commande, le procédé comprenant en outre un conditionnement de l'accès à la mémoire en fonction d'une comparaison entre les informations de transaction stockées dans le registre de commande et une liste d'informations spéciales définissant des transactions spéciales, par exemple des transactions interdites ou des transactions autorisées.
  • Selon un mode de mise en oeuvre, le procédé comprend une réception d'un niveau de sécurité du système sur puce, et dans lequel ledit conditionnement de l'accès est effectué en fonction du niveau de sécurité du système sur puce.
  • Selon un mode de mise en oeuvre, la liste d'informations spéciales définissant des transactions spéciales est faite respectivement pour chaque niveau de sécurité possible du système sur puce.
  • Selon un mode de mise en oeuvre, ledit conditionnement est effectué de sorte que l'accès est bloqué si au moins l'une desdites informations de transaction stockées dans le registre de commande appartient à ladite liste d'informations spéciales, ou bien si au moins l'une desdites informations de transaction stockées dans le registre de commande n'appartient pas à ladite liste d'informations spéciales.
  • Selon un mode de mise en oeuvre, la liste d'informations spéciales est établie sur au moins l'un des types d'informations de transaction suivants : une commande préétablie d'une action dans la mémoire ; une adresse de région mémoire ; une taille de région mémoire.
  • D'autres avantages et caractéristiques de l'invention apparaîtront à l'examen de la description détaillée de modes de réalisation et de mise en oeuvre, nullement limitatifs, et des dessins annexés, sur lesquels :
    • [Fig.1] et ;
    • [Fig.2] et ;
    • [Fig.3] illustrent des modes de réalisation et de mise en oeuvre de l'invention.
  • La figure 1 illustre schématiquement un exemple de réalisation d'un système sur puce SOC, tel que par exemple un microcontrôleur ou un microprocesseur, comportant un dispositif maître CPU, et un contrôleur de mémoire CNTMEM destinée à piloter des accès à une mémoire MEM, par exemple une mémoire externe non-volatile « Flash » ou « EEPROM ».
  • La mémoire MEM est par exemple connectée au contrôleur de mémoire CNTMEM du système sur puce SOC, via une interface d'entrées-sorties IOS.
  • Le dispositif maître CPU peut par exemple être un processeur ou une unité centrale de calculs (pour « Central Processing Unit » en anglais), adapté pour mettre en oeuvre des fonctionnalités logicielles ; ou bien un dispositif maître du type moyen d'accès direct en mémoire « DMA » (pour « Direct Memory Access » en anglais).
  • Le dispositif maître CPU est par exemple à l'origine des accès à la mémoire MEM, par des transactions TR1, TR2 communiquées sur un bus d'interconnexion BUS au contrôleur de mémoire CNTMEM.
  • Le bus d'interconnexion BUS peut par exemple être un bus du type « AXI » pour « Advanced eXtensible Interface » en anglais, ou du type « AHB » pour « Advanced High-performance Bus » en anglais, qui sont des types de bus de microcontrôleur « AMBA » pour « Advanced Microcontroller Bus Architecture ».
  • Chaque transaction TR1, TR2 contient des informations de transaction TINF définissant un accès respectif à la mémoire MEM. Les informations de transaction TINF peuvent par exemple contenir une information du type d'accès cmd en lecture, en écriture ou éventuellement en effacement ; une identification de la région mémoire MEM avec une adresse de début addr et une taille dlen ; des données data en écriture ; et d'autres informations de transaction « status », « ctrl ».
  • Par ailleurs, on considère que pour accéder à la mémoire MEM, il existe un premier type de transaction TR1 basé sur une commande communiquée au contrôleur CNTMEM ; et un deuxième type de transaction TR2 basé sur une adresse ou une région de la mémoire, par exemple en fonction d'une partition (ou « mappage ») de la mémoire MMAP (usuellement « memory map » en anglais).
  • Par exemple, un premier pare-feu RISUP peut être prévu pour autoriser ou restreindre les accès au contrôleur CNTMEM par des transactions du premier type TR1, c'est-à-dire en fonction des droits d'accès à la mémoire du dispositif maître CPU vis-à-vis d'un contexte d'exécution ; et un deuxième pare-feu RISAF peut être prévu pour autoriser ou restreindre les accès au contrôleur CNTMEM par des transactions du deuxième type TR2, c'est-à-dire en fonction des droits d'accès à respectivement chaque régions mémoire MMAP par le dispositif maître CPU.
  • Cela étant, les deux types de transactions TR1, TR2 contiennent lesdites informations de transaction TINF qui définissent l'accès.
  • Dans les deux cas également, le contrôleur de mémoire CNTMEM est configuré pour stocker les informations de transaction TINF dans un registre de commande REG, et pour piloter l'accès à la mémoire MEM à partir du contenu dudit registre de commande REG.
  • En outre, le contrôleur de mémoire CNTMEM comporte, en interne, des moyens de vérification CMP configurés pour conditionner l'accès effectif ACC à la mémoire MEM, en fonction d'une comparaison entre les informations de transaction stockées dans le registre de commande REG et une liste d'informations spéciales LST.
  • Chaque information spéciale de la liste LST définit par exemple une transaction interdite, ou un accès ACC interdit à la mémoire MEM.
  • Par exemple, les moyens de vérification CMP sont configurés à cet égard pour bloquer l'accès DEN si au moins l'une desdites informations de transaction stockées dans le registre de commande REG appartient à ladite liste d'informations interdites LST.
  • En alternative, chaque information spéciale de la liste LST définit par exemple une transaction autorisée, ou un accès ACC autorisé à la mémoire MEM.
  • Par exemple, les moyens de vérification CMP sont configurés à cet égard pour bloquer l'accès DEN si au moins l'une desdites informations de transaction stockées dans le registre de commande REG n'appartient pas à ladite liste d'informations autorisées LST.
  • Selon le choix de conception (notamment l'exhaustivité) de la liste d'informations spéciales, les moyens de vérification CMP peuvent être configurés pour bloquer l'accès DEN si aucunes desdites informations de transaction stockées dans le registre de commande REG n'appartient à ladite liste d'informations autorisées LST.
  • Avantageusement, les moyens de vérification CMP sont configurés pour effectuer ledit conditionnement de l'accès à la mémoire en fonction du niveau de sécurité du système sur puce SOC_LVL ; et par exemple la liste d'informations spéciales LST peut être faite respectivement pour chaque niveau de sécurité possible SOC_LVL du système sur puce SOC.
  • A cet égard, chaque élément de la liste LST est par exemple lié à une identification du niveau de sécurité r_lvl, d_lvl (figure 2).
  • Le niveau de sécurité du système sur puce SOC_LVL est par exemple communiqué par un bus interne dédié matériellement et de façon centralisée pour système sur puce SOC. On notera en particulier que le niveau de sécurité SOC_LVL n'est pas modifiable par une programmation logicielle.
  • Le niveau de sécurité SOC_LVL (ou LVL0-LVL3 - figure 3) correspond par exemple en pratique à un niveau de sécurité évolutif qui est automatiquement modifié dans l'avancée du processus de démarrage, de façon à avoir des accès de plus en plus restreints. Par exemple, le niveau de sécurité évolue temporellement de façon à bloquer les accès aux régions mémoires contenant des informations du processus de démarrage, dès que ces informations ont été utilisées dans le processus de démarrage.
  • On notera par ailleurs que le niveau de sécurité évolutif SOC_LVL, ne correspond pas aux contextes « sécurisé » ou « non-sécurisé », ni aux contextes « privilégiés » ou « non-privilégiés », qui sont conventionnellement filtrés par les pares-feux RISUP, RISAF. En effet, les contextes sécurisé/privilégiés sont typiquement attribués pour chaque dispositif (maître, ressource, périphérique...), éventuellement de façon commandée par un mécanisme logiciel de gestion des droits d'accès.
  • La liste d'informations spéciales LST est établie sur au moins l'un des types d'informations de transaction suivants : une commande préétablie d'une action dans la mémoire cmd ; une adresse de région mémoire addr ; une taille de région mémoire dlen.
  • Dans un premier exemple, illustré par la figure 1, chaque élément de la liste d'informations spéciales LST inclut une adresse de début de région mémoire r_addr et une taille de région mémoire r_dlen.
  • Ainsi, dans ce premier exemple, on a intégré les moyens de vérification CMP supplémentaires, directement en interne dans le contrôleur de mémoire CNTMEM. Les moyens de vérification CMP offrent une protection supplémentaire du type pare-feu, sur un nombre N de régions (en fonction du produit) de la mémoire MEM.
  • Chaque région est ainsi définie par une adresse r_addr et une longueur r_dlen, selon la mémoire externe le protocole utilisé (par exemple il peut s'agir d'une adresse brute, d'une adresse de page ou d'une adresse de bloc) ; ainsi que par le niveau de sécurité r_lvl autorisé le plus bas, ou bien le premier niveau non-autorisé r_lvl en fonction de la logique souhaitée.
  • La configuration des régions dans la liste LST peut être verrouillée pour ne jamais être reconfigurée ou surchargée par un autre composant logiciel.
  • Quel que soit le type transaction TR1, TR2 (par transmission d'une commande ou par un accès via une segmentation/mappage) l'adresse de la transaction addr, chargée dans le registre de commande REG est comparée aux adresses r_addr contenues dans la liste LST. Si l'adresse addr appartient à une région de la liste LST, le niveau de sécurité courant du système sur puce SOC_LVL est comparé au niveau de sécurité r_lvl qui correspond à l'adresse identifiée « r_addr⊂addr ». Si le niveau de sécurité courant SOC_LVL est supérieur à celui de la région identifiée r_lvl, la transaction est autorisée ACC, sinon elle est bloquée, ou rejetée, DEN et le contrôleur de mémoire CNTMEM peut renvoyer une erreur.
  • Le même processus de vérification peut être fait pour la dernière adresse de la transaction, égale à l'adresse de début ajouté de la longueur des données addr+dlen. Si la dernière adresse de la transaction est en dehors de toutes les régions de la liste LST, alors la transaction est autorisée ACC.
  • La figure 2 illustre un deuxième exemple, dans lequel chaque élément de la liste d'informations spéciales LST comporte une commande préétablie d'une action dans la mémoire d_cmd.
  • Dans le deuxième exemple, on a là-aussi intégré les moyens de vérification CMP supplémentaires directement en interne dans le contrôleur de mémoire CNTMEM, afin d'offrir une protection supplémentaire du type pare-feu ou « liste noire » (liste de commandes interdites), ou « liste blanche » (liste de commandes autorisées), sur un nombre M de commandes (en fonction du produit).
  • Les commandes préétablies d_cmd peuvent par exemple être codées sur 8 bits, selon la mémoire externe ou le protocole utilisé. Par exemple, il peut s'agir de commandes d'effacement de secteurs de la mémoire, voire de la mémoire en entier. La région à protéger peut être différente du secteur de la mémoire impacté par la commande, étant donné que ces commandes peuvent être envoyées avec une adresse addr ne correspondant pas à la région à protéger DAT_LVL0-DAT_LVL3 (dans le cas de la figure 1), tout en ayant un impact sur la région à protéger, par exemple DAT_LVL0, typiquement lorsque la région à protéger est située à l'intérieur du secteur.
  • Chaque commande de la liste d_cmd est liée au niveau de sécurité r_lvl autorisé le plus bas, ou bien le premier niveau non-autorisé r_lvl en fonction de la logique souhaitée.
  • La configuration des commandes dans la liste LST peut être verrouillée pour ne jamais être reconfigurée après l'initialisation pour s'assurer que personne ne la modifiera pendant l'exécution.
  • Quel que soit le type transaction TR1, TR2 (par commande ou par identification d'une segmentation/mappage) l'information de transaction qui définit une commande cmd, c'est-à-dire une action en mémoire, située dans le registre de commande REG, est comparée aux commandes spéciales d_cmd contenues dans la liste LST.
  • Si l'information de transaction qui définit la commande cmd appartient à la liste LST, le niveau de sécurité courant du système sur puce SOC_LVL est comparé au niveau de sécurité d_lvl qui correspond à la commande identifiée « cmd=d_cmd ».
  • Dans une alternative où la liste de commandes spéciales LST contient des commandes interdites d_cmd, si le niveau de sécurité courant SOC_LVL est inférieur (c'est-à-dire ayant des accès plus restreints) à celui de la commande identifiée d_lvl, alors la transaction est bloquée ou rejetée DEN, et le contrôleur de mémoire CNTMEM peut renvoyer une erreur.
  • Dans le cas contraire, si le niveau de sécurité courant SOC_LVL est supérieur (c'est-à-dire a plus de permission) à celui de la commande identifiée d_lvl, ou si l'information de transaction qui définit la commande cmd n'appartient pas à la liste de commandes interdites LST, alors la commande cmd est autorisée et la transaction est exécutée normalement, c'est-à-dire que le contrôleur de mémoire CNTMEM pilote l'accès ACC à la mémoire MEM.
  • Dans une autre alternative où la liste de commandes spéciales LST contient des commandes autorisées d_cmd, si le niveau de sécurité courant SOC_LVL est supérieur ou égal (c'est-à-dire a la permission équivalente ou plus) à celui de la commande identifiée d_lvl, alors la commande cmd est autorisée et la transaction est exécutée normalement, c'est-à-dire que le contrôleur de mémoire CNTMEM pilote l'accès ACC à la mémoire MEM.
  • Dans le cas contraire, si le niveau de sécurité courant SOC_LVL est inférieur (c'est-à-dire ayant des accès plus restreints) à celui de la commande identifiée d_lvl, ou si l'information de transaction qui définit la commande cmd n'appartient pas à la liste de commandes autorisées LST, est bloquée ou rejetée DEN, et le contrôleur de mémoire CNTMEM peut renvoyer une erreur.
  • La liste des commandes spéciales LST peut être un simple ensemble de registres. Le nombre « M » de registres dépend des besoins du produit.
  • La figure 3 illustre un exemple de processus de démarrage du système sur puce SOC, tel que décrit ci-avant en relation avec les figures 1 et 2, au cours duquel un niveau de sécurité du système sur puce LVL0-LVL3, évolue au fur et à mesure de l'avancée du processus de démarrage.
  • En particulier, on rappelle que le niveau de sécurité LVL0-LVL3 (ou SOC_LVL - figures 1 et 2) évolue temporellement de façon à avoir des accès de plus en plus restreints, notamment de façon à bloquer les accès aux régions mémoires contenant des informations du processus de démarrage, dès que ces informations ont été utilisées dans le processus de démarrage.
  • On notera que dans cet exemple, les valeurs numériques représentatives des niveaux de sécurité LVL0-LVL3 sont incrémentées au fur et à mesure que le niveau de sécurité baisse, c'est-à-dire au fur et à mesure que le contexte a de moins en moins de permissions d'accès.
  • Ainsi par exemple, lors d'une étape d'initialisation de démarrage Bootrom le code de démarrage initial est chargé depuis un emplacement fixe de la mémoire externe MEM immédiatement disponible pour le processeur lorsque l'exécution commence, par exemple l'emplacement DAT_LVL0.
  • Dans le contexte de cette toute première étape Bootrom, le niveau de sécurité LVL0 a le plus de permissions d'accès possible, et toutes les régions mémoires DAT_LVL0-DAT_LVL3 (et donc tous les éventuels secrets qu'elles contiennent) sont accessibles.
  • Ensuite, par exemple une étape FSBL dite première phase de démarrage (usuellement « first stage bootloader » en anglais) est mise en oeuvre.
  • Dans le contexte de cette première phase de démarrage FSBL, le niveau de sécurité LVL1 correspond à un niveau sécurisé de démarrage, dans lequel les secrets de l'étape d'initialisation de démarrage Bootrom ne sont plus utilisé, et sont donc cachées. A cet effet, l'accès à la région mémoire DAT_LVL0 correspondant au contexte Bootrom est bloqué DEN. Les autres régions mémoires DAT_LVL1-DAT_LVL3 sont accessibles.
  • Ensuite, par exemple une étape SecOS d'exécution d'un système d'exploitation sécurisé est mise en oeuvre.
  • Dans le contexte du système d'exploitation sécurisé SecOS, le niveau de sécurité LVL2 correspond à un niveau sécurisé, dans lequel les secrets de la première phase de démarrage FSBL, tels que des clés spécifiques, ne sont plus utilisé, et sont donc cachées. A cet effet, l'accès à la région mémoire DAT_LVL1 correspondant au contexte FSBL est bloqué DEN. L'accès à la région mémoire DAT_LVL0 du contexte Bootrom est toujours bloqué DEN. Les autres régions mémoires DAT_LVL2-DAT_LVL3 sont accessibles.
  • Ensuite, par exemple des étapes SSBL, OS correspondant à un contexte non-sécurisé NSEC sont mises en oeuvre.
  • Dans le contexte non-sécurisé NSEC, le niveau de sécurité LVL3 correspond à un niveau non-sécurisé, dans lequel seuls les « secrets » utilisable par le système d'exploitation non-sécurisé OS sont accessibles. A cet effet, l'accès à la région mémoire DA T _L VL2 correspondant au contexte SecOS est bloqué DEN. L'accès aux régions mémoire DAT_LVL0-DAT_LVL1 des contextes précédents FSBL, Bootrom sont toujours bloqués DEN. La région mémoire DAT_LVL3 est accessible.
  • Bien entendu, le processus de démarrage décrit ci-dessus correspond à un exemple simplifié, à vocation illustrative.
  • En résumé, il a été décrit des modes de réalisation et de mise en oeuvre d'un mécanisme interne au contrôleur de mémoire CNTMEM, pour mettre en oeuvre des protections supplémentaires de régions mémoires sensibles DAT_LVL0-DAT_LVL3, au moyen de la liste de transactions interdites ou autorisées LST, additionnellement à des éventuels pares-feux RISUP-RISAF conventionnels du système sur puce SOC. Cette protection supplémentaire CMP peut ainsi permettre de compléter un manque dans la protection, notamment dans le cadre du processus de démarrage, et en outre de manière adaptable à tous type de produit.

Claims (10)

  1. Système sur puce (SOC) comportant un contrôleur de mémoire (CNTMEM) adapté pour recevoir des transactions (TR1, TR2) contenant des informations de transaction (TINF) définissant un accès à une mémoire (MEM), le contrôleur de mémoire (CNTMEM) étant configuré pour stocker les informations de transaction dans un registre de commande (REG), et pour piloter l'accès à la mémoire (MEM) à partir du contenu dudit registre de commande (REG), dans lequel le contrôleur de mémoire (CNTMEM) comporte des moyens de vérification (CMP) configurés pour conditionner l'accès à la mémoire en fonction d'une comparaison entre les informations de transaction stockées dans le registre de commande (REG) et une liste d'informations spéciales (LST) définissant des transactions spéciales.
  2. Système sur puce selon la revendication 1, dans lequel les moyens de vérification (CMP) sont configurés pour recevoir un niveau de sécurité du système sur puce (SOC_LVL), et pour effectuer ledit conditionnement de l'accès à la mémoire en fonction du niveau de sécurité du système sur puce.
  3. Système sur puce selon la revendication 2, dans lequel la liste d'informations spéciales (LST) définissant des transactions spéciales est faite respectivement pour chaque niveau de sécurité possible (SOC_LVL) du système sur puce.
  4. Système sur puce selon l'une des revendications 1 à 3, dans lequel les moyens de vérification (CMP) sont configurés pour effectuer ledit conditionnement de sorte que l'accès est bloqué (DEN) si au moins l'une desdites informations de transaction stockées dans le registre de commande (REG) appartient à ladite liste d'informations spéciales (LST), ou bien si au moins l'une desdites informations de transaction stockées dans le registre de commande (REG) n'appartient pas à ladite liste d'informations spéciales (LST).
  5. Système sur puce selon l'une des revendications 1 à 4, dans lequel la liste d'informations spéciales (LST) est établie sur au moins l'un des types d'informations de transaction suivants : une commande préétablie d'une action dans la mémoire (cmd) ; une adresse de région mémoire (addr) ; une taille de région mémoire (dlen).
  6. Procédé de contrôle d'une mémoire, mis en oeuvre par un contrôleur de mémoire (CNTMEM) d'un système sur puce, comprenant une réception de transactions (AC1, AC2) contenant des informations de transaction (TINF) définissant un accès respectif à la mémoire (MEM), un stockage des informations de transaction reçues dans un registre de commande (REG), l'accès à la mémoire étant piloté à partir du contenu dudit registre de commande, le procédé comprenant en outre un conditionnement de l'accès à la mémoire en fonction d'une comparaison (CMP) entre les informations de transaction (TINF) stockées dans le registre de commande (REG) et une liste d'informations spéciales (LST) définissant des transactions spéciales.
  7. Procédé selon la revendication 6, comprenant une réception d'un niveau de sécurité du système sur puce (SOC_LVL), et dans lequel ledit conditionnement de l'accès est effectué en fonction du niveau de sécurité du système sur puce.
  8. Procédé selon la revendication 7, dans lequel la liste d'informations spéciales (LST) définissant des transactions spéciales est faite respectivement pour chaque niveau de sécurité possible (SOC_LVL) du système sur puce.
  9. Procédé selon l'une des revendications 6 à 8, dans lequel ledit conditionnement est effectué de sorte que l'accès est bloqué (DEN) si au moins l'une desdites informations de transaction stockées dans le registre de commande (REG) appartient à ladite liste d'informations spéciales (LST), ou bien si au moins l'une desdites informations de transaction stockées dans le registre de commande (REG) n'appartient pas à ladite liste d'informations spéciales (LST).
  10. Procédé selon l'une des revendications 6 à 9, dans lequel la liste d'informations spéciales (LST) est établie sur au moins l'un des types d'informations de transaction suivants : une commande préétablie d'une action dans la mémoire (cmd) ; une adresse de région mémoire (addr) ; une taille de région mémoire (dlen).
EP24172620.7A 2023-05-02 2024-04-26 Système sur puce comportant un contrôleur de mémoire et procédé de contrôle de mémoire correspondant Active EP4459493B1 (fr)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR2304400A FR3148482B1 (fr) 2023-05-02 2023-05-02 Système sur puce comportant un contrôleur de mémoire et procédé de contrôle de mémoire correspondant.

Publications (2)

Publication Number Publication Date
EP4459493A1 true EP4459493A1 (fr) 2024-11-06
EP4459493B1 EP4459493B1 (fr) 2025-12-24

Family

ID=87554222

Family Applications (1)

Application Number Title Priority Date Filing Date
EP24172620.7A Active EP4459493B1 (fr) 2023-05-02 2024-04-26 Système sur puce comportant un contrôleur de mémoire et procédé de contrôle de mémoire correspondant

Country Status (3)

Country Link
US (1) US20240370382A1 (fr)
EP (1) EP4459493B1 (fr)
FR (1) FR3148482B1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2945396A1 (fr) * 2009-05-07 2010-11-12 St Microelectronics Grenoble 2 Procede et dispositif d'analyse de la propagation de transactions dans un reseau multi-protocoles d'un systeme sur puce
FR3103586A1 (fr) 2019-11-22 2021-05-28 STMicroelectronics (Alps) SAS Procédé de gestion du fonctionnement d’un système sur puce formant par exemple un microcontrôleur, et système sur puce correspondant
EP3901776A1 (fr) * 2020-04-23 2021-10-27 NXP USA, Inc. Contrôleur d'espace d'adresse de remappage
US11281810B1 (en) * 2018-12-11 2022-03-22 Xilinx, Inc. Memory access protection in programmable logic device

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7134006B2 (en) * 2003-06-03 2006-11-07 Gateway Inc. Method and system for changing software access level within or outside a host protected area
US11281595B2 (en) * 2018-05-28 2022-03-22 Intel Corporation Integration of disparate system architectures using configurable isolated memory regions and trust domain conversion bridge

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2945396A1 (fr) * 2009-05-07 2010-11-12 St Microelectronics Grenoble 2 Procede et dispositif d'analyse de la propagation de transactions dans un reseau multi-protocoles d'un systeme sur puce
US11281810B1 (en) * 2018-12-11 2022-03-22 Xilinx, Inc. Memory access protection in programmable logic device
FR3103586A1 (fr) 2019-11-22 2021-05-28 STMicroelectronics (Alps) SAS Procédé de gestion du fonctionnement d’un système sur puce formant par exemple un microcontrôleur, et système sur puce correspondant
EP3901776A1 (fr) * 2020-04-23 2021-10-27 NXP USA, Inc. Contrôleur d'espace d'adresse de remappage

Also Published As

Publication number Publication date
FR3148482B1 (fr) 2025-11-07
EP4459493B1 (fr) 2025-12-24
FR3148482A1 (fr) 2024-11-08
US20240370382A1 (en) 2024-11-07

Similar Documents

Publication Publication Date Title
EP0733245B1 (fr) Carte a memoire et procede de fonctionnement
US6633984B2 (en) Techniques for permitting access across a context barrier on a small footprint device using an entry point object
JP2755828B2 (ja) 複数のマイクロプロセッサ間でアプリケーション・データおよび手続きを共用するための安全なアプリケーション・カード
FR3103586A1 (fr) Procédé de gestion du fonctionnement d’un système sur puce formant par exemple un microcontrôleur, et système sur puce correspondant
US9582675B2 (en) Protection of memory areas
JP4945053B2 (ja) 半導体装置、バスインターフェース装置、およびコンピュータシステム
KR20050113659A (ko) 메모리 장치
US8539602B2 (en) Microcontroller with secure feature for multiple party code development
US20250053318A1 (en) Dynamic management of a memory firewall
US20180129828A1 (en) Exclusive execution environment within a system-on-a-chip computing system
FR3103584A1 (fr) Procédé de gestion du débogage d’un système sur puce formant par exemple un microcontrôleur, et système sur puce correspondant
FR2833374A1 (fr) Procede et dispositif de controle d'acces dans un systeme embarque
US7555617B2 (en) Electronic data processing device with secured memory access
EP4459493B1 (fr) Système sur puce comportant un contrôleur de mémoire et procédé de contrôle de mémoire correspondant
EP1942417B1 (fr) Circuit de protection de zones mémoire
US7389427B1 (en) Mechanism to secure computer output from software attack using isolated execution
WO2002073552A1 (fr) Verification de la conformite d'acces de sujet a des objets dans un systeme de traitement de donnees avec une politique de securite
US20230161486A1 (en) Method for managing a memory in a system-on-a-chip
US7386774B1 (en) Memory unit with controller managing memory access through JTAG and CPU interfaces
EP1155389B1 (fr) Dispositif d'acces securise a des applications d'une carte a puce
EP1977551B1 (fr) Liaison d'un programme d'application protégée à un code d'enveloppe
CN118897820A (zh) 具有存储器控制器的片上系统以及对应的存储器控制方法
EP4453740B1 (fr) Système sur puce comprenant au moins une iommu sécurisée
FR3137471A1 (fr) Procédé de gestion de droits d’accès de régions mémoires et système sur puce correspondant
EP4187391A1 (fr) Gestion d'un pare-feu de mémoire dans un système sur puce

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20240426

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC ME MK MT NL NO PL PT RO RS SE SI SK SM TR

GRAP Despatch of communication of intention to grant a patent

Free format text: ORIGINAL CODE: EPIDOSNIGR1

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: GRANT OF PATENT IS INTENDED

INTG Intention to grant announced

Effective date: 20250729

GRAS Grant fee paid

Free format text: ORIGINAL CODE: EPIDOSNIGR3

GRAA (expected) grant

Free format text: ORIGINAL CODE: 0009210

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE PATENT HAS BEEN GRANTED

AK Designated contracting states

Kind code of ref document: B1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC ME MK MT NL NO PL PT RO RS SE SI SK SM TR

REG Reference to a national code

Ref country code: CH

Ref legal event code: F10

Free format text: ST27 STATUS EVENT CODE: U-0-0-F10-F00 (AS PROVIDED BY THE NATIONAL OFFICE)

Effective date: 20251224

Ref country code: GB

Ref legal event code: FG4D

Free format text: NOT ENGLISH

REG Reference to a national code

Ref country code: DE

Ref legal event code: R096

Ref document number: 602024001789

Country of ref document: DE

REG Reference to a national code

Ref country code: LT

Ref legal event code: MG9D

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: NO

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20260324

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: HR

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20251224

Ref country code: FI

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20251224

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: RS

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20260324

PG25 Lapsed in a contracting state [announced via postgrant information from national office to epo]

Ref country code: LV

Free format text: LAPSE BECAUSE OF FAILURE TO SUBMIT A TRANSLATION OF THE DESCRIPTION OR TO PAY THE FEE WITHIN THE PRESCRIBED TIME-LIMIT

Effective date: 20251224