CN117349853A

CN117349853A - Method for managing access rights of a storage area and corresponding system on chip

Info

Publication number: CN117349853A
Application number: CN202310812401.6A
Authority: CN
Inventors: L·帕拉迪; L·德比夫
Original assignee: STMicroelectronics Grand Ouest SAS
Current assignee: STMicroelectronics Grand Ouest SAS
Priority date: 2022-07-04
Filing date: 2023-07-04
Publication date: 2024-01-05

Abstract

Embodiments of the present disclosure relate to a method for managing access rights of a storage area and a corresponding system-on-chip. The method for managing access rights of storage areas of a memory includes assigning an execution permission state for each storage area in a firewall device dedicated to the memory such that contents of the storage areas having an executable state can be executed by a processor and contents of the storage areas having a non-executable state cannot be executed by the memory.

Description

Method for managing access rights of a storage area and corresponding system on chip

Cross Reference to Related Applications

The present application claims the benefit of french patent application number 2206736 filed at 2022, 7, 4, which is incorporated herein by reference.

Technical Field

Embodiments and implementations relate to management of access rights for a storage area and corresponding system-on-chip.

Background

Typically, during the process for booting the system on chip, the single boot firmware is authenticated by way of a signature mechanism and possibly decrypted for the next step of the firmware. This results in a reliable start-up chain.

Each boot firmware has the following possibilities: a memory management and protection unit, typically a Memory Protection Unit (MPU) or a Memory Management Unit (MMU), is programmed to define which portions of memory are executable and which are not.

But typically the memory management and protection unit may be deactivated before jumping to the next firmware, which will reconfigure the memory management and protection unit as required. Deactivation of the memory management and protection unit may occur in the conventional case of restarting or resetting the processor in the startup phase, which also resets the parameters of the memory management and protection unit.

If a fault is injected at this point, it is possible to generate a glitch (glotch) on the program counter ("PC") pointing to the memory address of the instruction to be executed and jump to a memory address containing an instruction that is not authenticated or should not be executed.

To minimize this risk, conventional solutions provide for authentication of a complete image of the content loaded in the memory, the memory content being guaranteed by, for example, the following method: all unused areas are erased to avoid error codes, to keep memory management and protection units active during reset, or to provide specific executable non-volatile storage areas for booting.

These conventional solutions have difficulties in: they reduce the performance of the system on chip or create complex mechanisms that depend on the capacity of the processor and memory management and protection units and may not be compatible with each firmware.

Therefore, it is necessary to solve these drawbacks.

Disclosure of Invention

Implementations and embodiments provide a way to add new states (i.e., executable states or non-executable states) in a firewall of memory to define execution permissions for different storage regions in a similar manner as read permission states and write permission states of storage regions in a conventional firewall.

Accordingly, in an aspect, there is provided a method for managing access rights of storage areas of a memory such as a volatile RAM (random access memory), including assigning an execution permission status for each storage area in a firewall device dedicated to the memory such that contents of the storage area having an executable status can be executed by a processor and contents of the storage area having a non-executable status cannot be executed by the memory.

Therefore, in the case of fault injection attacks and glitches generated on the program counter, it will not be possible to execute data or code contained outside the authenticated memory area. Furthermore, since the program counter of the processor remains inside the authentication code, this method allows software countermeasures to be implemented.

According to one implementation, assigning the execution permission status includes assigning the non-executable status to a storage area containing data.

In practice, the data contained in the memory may be read or written, but is by no means intended to be executed as program code recorded in binary in the memory. Thus, this embodiment makes it possible to systematically prevent erroneous execution of data.

According to one embodiment, assigning the execution permission status includes: a phase of verifying the authenticity of the content of the storage area containing the program code; assigning the executable state to a storage area whose content is authenticated in a verification phase; and assigning the non-executable state to a storage area whose content is not authenticated in the authentication phase.

The authenticity verification stage may comprise decryption of the content of the possible storage area and implementation of a hash function.

According to one implementation, executing, by the processor, the content of the first storage area includes a second phase of verifying the authenticity of the content of the second storage area, the method including assigning an executable state to the second storage area if the content of the second storage area is authenticated in the second verification phase, and assigning an unexecutable state to the second storage area if the content of the second storage area is not authenticated in the second verification phase.

Thus, the second storage area may be authenticated a second time during execution of the content of the first storage area. Executing the content of the first area may in fact make it possible to obtain additional authentication information for verifying the authenticity of the second storage area. This is the case, for example, when the second storage area contains an extension owned by the user, authentication of that extension cannot be done by the system-on-chip in its initial configuration at startup.

According to one implementation, in addition to the read permission status and the write permission status, an execution permission status is assigned to each storage area in the firewall device.

According to one implementation, a storage area having an unexecutable state may have a read permission state or a non-read permission state, and a write permission state or a non-write permission state.

In fact, unlike conventional techniques that prevent execution of the contents of a storage area by parameterizing the read permission status of the storage area as "unreadable", use of the execution permission status allows read access to the storage area that is not executable. This makes it possible in particular to verify the authenticity thereof or the nature of its content (e.g. binary code or data) in read mode without the occurrence of execution defects (e.g. in the case of fault injection as described above).

According to one implementation, assigning the execution permission status includes: for each storage area, a different respective execution permission status is assigned to a different processor in the firewall device.

According to one implementation, there is provided a system on chip comprising a processor, a memory having memory regions, a firewall device dedicated to the memory, wherein the access rights management system is configured to allocate an execution permission status in the firewall device for each memory region, the firewall device and the processor being configured such that content of the memory region having an executable status is allowed to be executed by the processor, and content of the memory region having a non-executable status is not executable by the processor.

According to one implementation, an access rights management system is configured to assign non-executable states to storage areas containing data.

According to one implementation, the access rights management system is configured to verify the authenticity of content of a storage area containing program code to assign an executable state to a storage area whose content is authenticated and to assign a non-executable state to a storage area whose content is not authenticated.

According to one implementation, when the content of the first storage area is executed by the processor, the access rights management system is configured to verify the authenticity of the content of the second storage area a second time and to assign an executable state to the second storage area if the content of the second storage area is authenticated a second time and to assign an unexecutable state to the second storage area if the content of the second storage area is not authenticated a second time.

According to one implementation, the access rights management system is configured to assign an execution permission status to each storage area in the firewall device in addition to the read permission status and the write permission status.

According to one implementation, the access rights management system is configured to allocate a read permission status or a non-read permission status, and a write permission status or a non-write permission status to a storage area having an execution permission status that is not executable.

According to one implementation, the system on a chip further comprises at least one other processor, and the access rights management system is configured to assign different respective execution permission states to the different processors for each storage area in the firewall device.

Drawings

Other advantages and features of the invention will become apparent upon examination of the detailed description of non-limiting implementations and embodiments, and the accompanying drawings, in which:

FIG. 1 illustrates an example embodiment of a system-on-chip with respect to a boot program;

FIG. 2 illustrates the system-on-chip of FIG. 1 during a second step of the startup procedure;

FIG. 3 illustrates the system-on-chip of FIGS. 1 and 2 during a third step of the startup procedure; and

fig. 4 illustrates an example of information contained in a firewall for distributing read, write, and execute access rights.

Detailed Description

Fig. 1 illustrates an example embodiment of a system on chip SOC, comprising in particular a processor CPU, a memory MEM of RAM type and a firewall device FWL dedicated to the memory MEM.

The different elements of the system-on-chip SOC are interconnected by an integrated system BUS of, for example, the "AXI" type ("advanced extensible interface").

The processor CPU is advantageously provided with a memory management and protection unit MMU/MPU. In general, the memory management and protection unit MMU/MPU may be a memory protection unit "MPU" or a memory management unit "MMU" depending on the type and performance of the processor CPU. The memory management and protection unit MMU/MPU generally enables access to the memory MEM made by the processor CPU to be controlled and in particular, for the memory areas R1, R2 of the memory MEM, the access to be controlled according to the access rights environment in which the processor CPU is located.

The firewall device FWL is dedicated to the memory MEM and allows control of access to the memory from the processor CPU or from possible other host devices connected to the BUS. The firewall FWL is configured to verify the access right level of the request for accessing the memory MEM against the access right level required for accessing the corresponding storage region R1, R2 and to authorize or not authorize the access.

In other words, the memory management and protection unit MMU/MPU provides protection regarding the state of the processor CPU, while the firewall FWL provides protection regarding the content of the storage areas R1, R2.

In addition, the system-on-chip SOC may include an internal non-volatile memory (typically "read only memory") containing the basic program code ROMcode for booting the system-on-chip SOC, and also benefit from an external mass storage memory ExtMEM (e.g., flash memory).

The access rights management system is configured to assign access rights to the different storage areas R1, R2 and may generally be embodied by the secure environment of the processor CPU.

Alternatively, the access rights management system may be embodied by a secure co-processor COPROC dedicated to managing access rights and authenticating content loaded in the memory MEM. The secure coprocessor COPROC is particularly advantageous in case the system on chip SOC comprises several masters with access to memory, in particular in case of a multiprocessor system on chip comprising several processor CPUs.

For example, the access rights may generally include a read permission state "rd" (fig. 4) and a write permission state "wr" (fig. 4) for each storage region R1, R2, and for each master CPU capable of generating a request for accessing the memory MEM.

Further, the access rights management system CPU, COPROC is configured to allocate an execution permission status "exe" (fig. 4), which may be "executable" E or "unexecutable" NE, in the firewall device FWL for each storage region R1, R2 and for each master CPU that is capable of generating a request for accessing the memory MEM. The access rights management system CPU, COPROC may be implemented using processor circuitry such as a microprocessor, microcontroller, or other processing circuitry known in the art coupled to a non-transitory computer-readable medium (such as volatile or non-volatile memory) including instructions stored thereon. The processor circuit, when executed by the processor circuit, may be enabled to perform the methods and operations described herein.

The storage area having the execution permission status NE that is not executable may independently have a read permission status or a non-read permission status, and a write permission status or a non-write permission status.

In particular, in steps 100 and 300 described below, the implementation of the verification of the authenticity of the program code should advantageously have read rights for the corresponding storage area.

The non-executable state NE thus makes it possible to authorize the reading of the storage areas without the risk of opening the illegal execution of the contents of these storage areas.

The firewall device FWL and the processor CPU are configured such that the content of the storage area having the executable state E can be executed by the processor CPU, whereas the content of the storage area having the non-executable state NE cannot be executed by the processor CPU.

In practice, the request for accessing the memory communicating on the BUS may comprise information representative of the fact that: the contents of the accessed memory areas R1, R2 are intended to be executed by the processor CPU. This is especially the case for integrated system buses of the "AXI" type.

For example, the execution information may be transmitted in the form of a dedicated bit in the header data of the request, which request also includes other information, such as the address of the memory area to be accessed.

Thus, a request for performing access to the storage area R2 having the non-executable state NE in the firewall FWL will be blocked by the firewall FWL and will not cause transmission of the content of this storage area R2 to the host device CPU that issued the request.

Fig. 1 to 3 illustrate steps 100, 200, 300 of an example of application of the protection mechanism obtained by the execution permission state E, NE of the content of the storage areas R1, R2 in the firewall FWL in the context of an initial start-up of the system on chip SOC.

In this regard, fig. 1 illustrates a step 100 of a procedure for booting a system on chip SOC, at the beginning of which a basic boot code ROMcode is executed.

The basic boot code ROMcode controls, for example, loading of the binary firmware FSBL and the extension PLGIN of the binary firmware from the external mass storage memory ExtMEM to the first region R1 and the second region R2 of the random access memory MEM, respectively. In addition, the data DAT may be loaded in the third storage region R3 of the random access memory MEM (for example, also from the external mass storage memory ExtMEM).

In this example, the firmware FSBL may include a first stage boot loader instruction and, prior to its execution, the firmware FSBL is authenticated by the basic boot program ROMcode.

In this respect, the basic boot program ROMcode provides a phase of verifying the authenticity of the content of the storage areas R1, R2 containing the program codes FSBL, PLGIN. The authenticity verification stage is implemented by the access rights management system CPU, COPROC.

For example, this may be done using a hash mechanism of the binary code loaded in the storage areas R1, R2, and the identification of the signature using a known key and contained in the base code ROMcode.

The firmware FSBL can be authenticated (i.e. verified) by an authenticity verification phase and an "executable" state E is assigned to the first storage area R1 by the access rights management system CPU, COPROC in the firewall FWL and in the memory management and protection unit MMU/MPU.

However, the extended PLGIN may come from a third party and thus the extended PLGIN is signed by a specific key that is unknown to the basic boot code ROMcode.

Therefore, in the stage of verifying the basic code ROMcode, the extended PLGIN is not authenticated, and the "non-executable" execution permission status NE is allocated to the second storage area R2 by the access authority management system CPU, COPROC in the firewall FWL and in the memory management and protection unit MMU/MPU.

Finally, the non-executable state NE is advantageously automatically allocated to the storage area containing the data DAT, i.e. in this example to the third storage area R3.

Thus, the execution permission states NE, E have been set for the FSBL, PLGIN, DAT content loaded in the storage areas R1, R2, R3 of the memory MEM.

Reference is now made to fig. 2.

Fig. 2 illustrates the system on chip SOC described in connection with fig. 1 in a second step 200 of the program for starting the system on chip SOC in which the firmware FSBL loaded in the memory MEM is to be executed by the processor CPU.

The second step 200 generally includes a CPU "hot restart" RBT that is used to place the processor CPU in an original state to execute the firmware FSBL.

Thus, by resetting the RBT to the processor CPU, the protection parameterized in the memory management and protection unit MMU/MPU is again set to the original state.

In the normal case, i.e. in the case where there is no execution permission status in the firewall FWL, before the memory management and protection unit MMU/MPU is parameterized again, there is a loophole window during which the memory areas R2, R3 that have not been authenticated or contain data may be illegally executed.

However, the firewall FWL dedicated to memory is not affected by the reset RBT of the processor CPU and the memory management and protection unit MMU/CPU and its protection remains valid in this vulnerability window. Therefore, neither the unauthenticated program code PLGIN in the second R2 region nor the data DAT in the third R3 region can be executed.

Thus, the firmware FSBL can be executed without risk.

Reference is now made to fig. 3.

Fig. 3 illustrates the system on chip SOC described in connection with fig. 1 and 2 in a third step 300 of the program for starting the system on chip SOC in which the firmware FSBL loaded in the memory MEM is executed by the processor CPU.

In one aspect, the execution of the firmware FSBL advantageously includes setting again the parameterization of the memory management and protection unit MMU/MPU as in step 100.

On the other hand, execution of the firmware FSBL may be able to authenticate the program code of the extended PLGIN using a second authenticity verification phase similar to the first verification phase described in connection with fig. 1, but using knowledge of the specific key from the third party owner of the extended PLGIN.

Thus, the extended PLGIN can be authenticated (i.e., verified) by the second authenticity verification stage, and the execution permission status of the second storage area R2 is updated to the executable status e— "ne→e" by the access rights management system CPU, COPROC in the firewall FWL and the memory management and protection unit MMU/MPU.

The authenticity verification stage implemented in steps 100 and 300 may result in the invalidation of the content loaded in the memory MEM, for example because of accidental or spurious corruption of the loaded data (spurious corruption). If the content of the storage area containing the program code R1, R2 is not authenticated, the non-executable state NE is assigned to this storage area R1, R2.

Steps 100, 200 and 300 have been described in the application of a program for starting a system on chip SOC, however, the solution described in steps 100, 200 and 300 may be applied to any other program loading including, for example and in particular, a "hot reset" RBT of a processor CPU.

Fig. 4 illustrates an example of information contained in the firewall FWL for allocating read rd, write wr, and executing exe access rights.

Thirty-two (32) bit registers are provided for each memory region R1, R2, R3 of the memory MEM, for example. For example, a memory region may be a page of memory, i.e., a unit of physical or functional partitioning of memory; the storage area may be an area having a start address and a size dynamically defined according to the storage contents.

In this example, the registers of each storage area can contain the specific access rights of eight (8) different masters, i.e., read rd, write wr, and execute exe grant status for each of the eight (8) masters.

For example, the eight (8) bits b0 through b7 of the register are dedicated to the read rd grant states of the corresponding eight (8) masters; eight (8) bits b16 through b23 of the register are dedicated to the write wr permission status of the corresponding eight (8) masters; and the eight (8) bits b8 through b15 of the register are dedicated to the execution exe grant status of the corresponding eight (8) masters. The eight (8) bits b24 through b31 of the register may be reserved for another application.

Thus, the embodiments and implementations described in connection with fig. 1 to 4, wherein the new state is added to the firewall FWL of the random access memory MEM to define execution permissions for the contents of the different memory regions, provide additional protection in relation to executing the contents of the memory regions, and the additional protection is related to the contents of the memory and not to the processor state.

This additional protection (especially in the case of fault injection attacks and glitches generated on the program counter) makes it possible to prevent illegal execution of the memory contents.

In the above-described embodiments and implementations, it is practically impossible to execute data or code contained outside the authentication area, and software countermeasures may be executed as part of the authentication code.

Furthermore, the above-described embodiments and implementations have the following advantages: independent of the processor CPU architecture; compatible with the current software component configuration, in particular with the open source firmware; compatibility in multiprocessor systems (particularly when authentication is delegated to a secure coprocessor COPROC); is compatible with a hot reset RBT of a processor CPU and a memory management and protection unit MMU/MPU; and is based on a memory firewall hardware device FWL and can therefore be integrated into the security infrastructure.

Claims

1. A method for managing access rights to a storage area of a memory, the method comprising:

assigning an execution permission status for each storage area in a firewall device dedicated to the memory, wherein:

content of a memory area having an executable state is allowed to be executed by a processor, and

the contents of the memory area having the non-executable state are not allowed to be executed by the processor.

2. The method of claim 1, wherein assigning the execution permission status comprises: and allocating the non-executable state to a storage area containing data.

3. The method of claim 1, wherein assigning the execution permission status further comprises:

performing a first phase of verifying the authenticity of said content of the storage area containing the program code;

assigning the executable state to a storage area whose content is authenticated in the first phase of verifying authenticity; and

the non-executable state is assigned to a storage area whose content was not authenticated in the first phase of verifying authenticity.

4. A method according to claim 3, wherein: assigning the execution permission status further includes, when executing the contents of the first storage area of the memory:

performing a second phase of verifying the authenticity of the content of the second storage area;

assigning the executable state to the second storage area when the content of the second storage area is authenticated in the second phase of verification; and

the non-executable state is assigned to the second storage area when the content of the second storage area is not authenticated in the second phase of verification.

5. The method of claim 1, wherein assigning the execution permission status comprises: in addition to the read permission status and the write permission status, the execution permission status is assigned to each storage area in the firewall device.

6. The method of claim 5, wherein the storage area having the non-executable state is configured to have the read permission state or a non-read permission state and a write permission state or a non-write permission state.

7. The method of claim 1, wherein assigning the execution permission status further comprises: for each storage area, corresponding different execution permission states are assigned to different processors in the firewall device.

8. A system on a chip, comprising:

a processor;

a memory having a memory area;

firewall equipment dedicated to said memory; and

an access rights management system configured to allocate an execution permission status in the firewall device for each storage area, wherein the firewall device and the processor are configured to:

allowing the content of the memory area having executable state to be executed by the processor, and

content of a memory region having a non-executable state is prohibited from being executed by the processor.

9. The system-on-chip of claim 8, wherein the access rights management system is further configured to: and allocating the non-executable state to a storage area containing data.

10. The system-on-chip of claim 8, wherein the access rights management system is further configured to:

verifying authenticity of said content of said storage area containing program code;

assigning the executable state to a storage area whose content is authenticated; and

and allocating the non-executable state to a storage area of which the content is not authenticated.

11. The system on a chip of claim 10, wherein when the content of the first storage area is executed by the processor, the access rights management system is configured to:

verifying the authenticity of the content of the second storage area;

assigning the executable state to the second storage area whose content is authenticated; and

and assigning the non-executable state to the second storage area whose content is not authenticated.

12. The system-on-chip of claim 8, wherein the access rights management system is further configured to: in addition to the read permission status and the write permission status, the execution permission status is assigned to each storage area in the firewall device.

13. The system-on-chip of claim 12, wherein the access rights management system is further configured to: and allocating the read permission state or the non-read permission state and the write permission state or the non-write permission state to the storage area with the non-executable state.

14. The system on a chip of claim 8, further comprising at least one other processor, wherein the access rights management system is configured to: in the firewall device, a different respective execution permission status is assigned to the processor and the at least one other processor for each storage area.

15. The system on a chip of claim 8, wherein the access rights management system comprises a co-processor coupled to the firewall device via a bus or implemented using the processor.

16. A system, comprising:

a processor configured to be coupled to a firewall device via a bus, wherein the firewall device is dedicated to a system memory comprising a storage area; and

a program memory coupled to the processor, having instructions stored thereon, wherein the instructions, when executed by the processor, enable the processor to:

an execution permission status is assigned in the firewall device for each storage area in the system memory,

17. The system of claim 16, wherein the instructions, when executed by the processor, further enable the processor to:

verifying the authenticity of said content of the storage area containing the program code;

18. The system of claim 17, wherein the instructions, when executed by the processor, further enable the processor, when executed by the processor, to:

verifying the authenticity of the content of the second storage area;

19. The system of claim 16, wherein the instructions, when executed by a processor, further enable the processor to: in addition to the read permission status and the write permission status, the execution permission status is assigned to each storage area in the firewall device.

20. The system of claim 16, further comprising:

the system memory; and

the firewall device.