STORAGE ARRANGEMENT

Description

Domaine technique

[0001] This description relates generally to electronic circuits and devices and the software applications that they can implement. This description relates more particularly to a configuration interface for an application executed by a processor. Technique antérieure

[0002] A processor, called a "Central Processing Unit" (CPU) in English, is a complex electronic component that is used to implement series of software instructions, and which can therefore allow applications to be executed.

[0003] A software application may require, for its proper functioning, access to various functionalities of a device that implements it, such as memories, or other specific electronic components, etc. Before being implemented by an electronic device, an application generally uses a configuration interface, allowing it to configure access to the various functionalities of the device. Document US 2020 / 218673 A1 discloses techniques for controlling access to a memory. Document US 2020 / 218673 A1 discloses that a memory area can be assigned one of three security attribute values: secure, non-secure and non-secure callable to

[0004] It would be desirable to be able to improve, at least in part, certain aspects of application execution by a processor, and in particular, certain aspects of the configuration interfaces of an application executed by a processor. Summary of the invention

[0005] There is a need for a method of configuring an application executed by a processor allowing optimization of the management of the memories associated with the processor.

[0006] There is a need for a configuration interface for an application executed by a processor allowing optimization of the management of memories associated with the processor. The present invention is defined by the appended independent claims to which reference should be made.

[0007] One embodiment overcomes all or part of the drawbacks of known application configuration methods.

[0008] One embodiment overcomes all or part of the drawbacks of known application configuration interfaces.

[0009] One embodiment provides a method for configuring an application executed by a processor, further enabling optimization of the number of application-associated memory ranges used by an application based on values ​​representing security levels of said application-associated memory ranges.

[0010] One embodiment provides an interface for configuring an application executed by a processor, further enabling optimization of the number of application-associated memory ranges used by an application based on values ​​representing security levels of said application-associated memory ranges.

[0011] One embodiment provides a method for configuring an application executed by a processor, further enabling optimization of the number of memory ranges associated with an access controller and whose stored data are used by an application. Access by the application to the memory is made through the access controller. Optimization of the number of memory ranges is performed based on values ​​representing security levels of said memory ranges. The access controller may include one or more registers indicating memory ranges, with given security levels.

[0012] One embodiment provides a method of configuring a memory for executing an application adapted to be executed by a processor and using at least two first and second contiguous memory resources associated with an application and placed in at least one memory area of ​​at least one memory, wherein said method comprises a step of merging said at least two first and second memory resources into a third memory resource, if said at least two first and second portions have the same value of the security attribute, the method further comprising a step of generating memory range configuration data of a memory.

[0013] Another embodiment provides a configuration interface adapted to implement a method of configuring a memory for the execution of an application adapted to be executed by a processor and using at least two first and second contiguous memory resources associated with an application and placed in at least one memory area of ​​at least one memory, wherein said method comprises a step of merging said at least two first and second memory resources into a third memory resource, if said at least two first and second portions have the same value of the security attribute, the method further comprising a step of generating memory range configuration data of a memory.

[0014] According to one embodiment, said value of said security attribute designates the security level of a portion of a memory.

[0015] According to one embodiment, said value of said attribute of a memory resource of said application may be equal to: secure; unsecure; and unsecure callable.

[0016] According to one embodiment, if the value of the attribute of the first portion is equal to unsecure, and the value of the attribute of the second portion is equal to unsecure callable, and the second portion is placed in a memory area whose value of the attribute is equal to unsecure callable, then said at least two first and second portions are merged into the third portion, and the value of the attribute of the third portion is equal to unsecure, said first and second portions being strictly contiguous.

[0017] Another embodiment provides a device comprising an interface described above.

[0018] According to one embodiment, the device further comprises said processor adapted to implement the application.

[0019] According to one embodiment, the device further comprises said at least one memory.

[0020] Another embodiment provides a non-transitory computer-readable means adapted to implement the method described above. Brève description des dessins

[0021] These and other features and advantages will be set forth in detail in the following description of particular embodiments given without limitation in relation to the attached figures, among which: there figure 1 represents, very schematically and in the form of blocks, an example of an electronic device suitable for implementing the embodiments of the figures 2 à 12 ; there figure 2 represents, very schematically and in the form of blocks, an embodiment of an application configuration interface; the figure 3 represents a block diagram illustrating a mode of implementation of a method of configuring an application; the figure 4 represents, very schematically and in the form of blocks, an example of the implementation of a step of the configuration process of the figure 3 ; there figure 5 represents, very schematically and in the form of blocks, an example of the implementation of another step of the configuration process of the figure 3 ; there figure 6 represents, very schematically and in the form of blocks, an example of the implementation of another step of the configuration process of the figure 3 ; there figure 7 represents, very schematically and in the form of blocks, an example of the implementation of another step of the configuration process of the figure 3 ; there figure 8 represents, very schematically and in the form of blocks, an example of the implementation of another step of the configuration process of the figure 3 ; there figure 9 represents, very schematically and in the form of blocks, an example of the implementation of another step of the configuration process of the figure 3 ; there figure 10 represents, very schematically and in the form of blocks, an example of the implementation of another step of the configuration process of the figure 3 ; there figure 11 represents, very schematically and in the form of blocks, an example of the implementation of another step of the configuration process of the figure 3 ; and the figure 12 represents, very schematically and in the form of blocks, an example of the implementation of another step of the configuration process of the figure 3 . Description des modes de réalisation

[0022] The same elements have been designated by the same references in the different figures. In particular, the structural and / or functional elements common to the different embodiments may have the same references and may have identical structural, dimensional and material properties.

[0023] For the sake of clarity, only the steps and elements useful for understanding the embodiments described have been represented and are detailed.

[0024] Unless otherwise specified, when referring to two elements connected together, this means directly connected without intermediate elements other than conductors, and when referring to two elements connected (in English "coupled") together, this means that these two elements can be connected or be connected by means of one or more other elements.

[0025] In the following description, when reference is made to absolute position qualifiers, such as the terms "front", "back", "top", "bottom", "left", "right", etc., or relative position qualifiers, such as the terms "above", "below", "upper", "lower", etc., or to orientation qualifiers, such as the terms "horizontal", "vertical", etc., reference is made unless otherwise specified to the orientation of the figures.

[0026] Unless otherwise specified, the expressions "about", "approximately", "substantially", and "of the order of" mean to within 10%, preferably to within 5%.

[0027] The embodiments described below relate to a method for configuring an application executed by a processor and using memory resources associated with said processor, and the associated configuration interface. The memory resources are here portions, parts and areas of one or more real or virtual memories managed by said processor.

[0028] According to one embodiment, the configuration interface includes several functionalities. A first functionality is to allow the modification of security attributes associated with physical memory areas of a memory, and then, if necessary, to redefine memory areas. A second functionality is to allow the generation of a list of memory ranges associated with an application based, in part, on a physical division of a memory, then to optimize this list of virtual memory ranges to limit the number of ranges.

[0029] To implement these features, the configuration interface relies on values ​​of a security attribute associated with each memory portion, part, or area, and each memory resource required by the application. More specifically, this security attribute defines whether a physical memory area is secure or unsecure, and whether a memory resource of an application is secure, unsecure, or unsecure callable. The security attribute is described in more detail in connection with the figure 10 .

[0030] There figure 1 is a block diagram representing, very schematically, an architecture of an example of an electronic device 100 adapted to the implementation of a software application.

[0031] The electronic device 100 comprises, according to one embodiment, a processor 101 (CPU) adapted to implement different processing of data stored in memories and / or provided by other circuits of the device 100. According to one embodiment, the processor 101 is particularly adapted to implement one or more applications as described in relation to the figure 2 .

[0032] The electronic device 100 further comprises, according to one embodiment, one or more memories 102 (MEM), for example memories of different types, including, for example, a non-volatile memory and / or a volatile memory. According to one embodiment, these memories are adapted to be used by the processor 101 and by the application(s) that it implements. The processing of the memories by the processor is described in more detail in relation to the figure 2 .

[0033] The electronic device 100 further comprises, according to one example, input / output circuits 103 (IN / OUT) adapted to implement data and / or energy communications with a user and / or with one or more other electronic devices.

[0034] The electronic device 100 may further comprise different circuits 104 (FCT1), 105 (FCT2) and 106 (FCT3) adapted to perform different functions. For example, the circuits 104, 105 and 106 may comprise measurement circuits, data conversion circuits, electronic or electromechanical equipment control circuits, etc.

[0035] The electronic device 100 further comprises one or more data buses 107 adapted to transfer data between its different components.

[0036] There figure 2 represents, schematically and in block form, a configuration interface 200 (MMT), or memory configuration tool 200, of an application 210 (APP) adapted to be executed by a processor 220 (CPU) and using a memory 230 (MEM).

[0037] According to one embodiment, the application 210 is computer software adapted to be implemented by the processor 210, and the operation of which uses one or more hardware resources managed by the processor 220. More particularly, and according to one embodiment, the application 210 is adapted to use, at least, memory resources managed by the processor 220, for example, to read and / or store data there. Here, a memory resource is a part of memory used by the application 210 to read and / or write data.

[0038] According to one embodiment, the processor 220 is of the type of the processor 101 described in relation to the figure 1 The processor 220 is adapted to use hardware resources, such as one or more memories or other electronic components and devices, to operate the application 210.

[0039] According to one example, the memory 230 is a memory of the type of memories 102 described in relation to the figure 1 . The memory 230 consists of a set of memory cells each associated with an address. A set of memory cells of a memory, hereinafter called a memory portion or memory area, can be defined by a list of memory addresses. The memory 230 is adapted to communicate with the processor 220.

[0040] According to one embodiment, to manage the memory 230, and, in particular, the security issues linked to the memory 230, the processor 220 comprises two memory allocation units 221 (IDAU) and 222 (SAU).

[0041] The memory allocation unit 221 is a hardware memory allocation unit, hereinafter referred to as the hardware allocation unit 221, adapted to divide a memory into several memory areas, and to associate a security attribute value with them. The unit 221 is called an Implementation Defined Attribution Unit (IDAU) in English, for an allocation unit defined by the hardware implementation. According to one example, the unit 221 is an electronic component forming part of the processor 220. The role of the unit 221 is to divide the memory 230 into several memory areas, that is to say into several sets of memory cells. This division of the memory is called a hardware division of the memory. According to one embodiment, each physical memory area is defined by: a starting address; a size; optionally, an ending address; and by a security attribute value.

[0042] Here, the starting address is the address of the first memory cell in a memory area, i.e., the address of the memory cell with rank zero in the memory area. Similarly, here, the ending address is the address of the last memory cell in a memory area, i.e., the address of the memory cell with rank N-1 in the memory area, where N is an integer designating the size of the memory area.

[0043] Regarding the security attribute, each memory area has two possible security attribute values. A memory area can be secure or non-secure. A secure memory area is a portion of memory whose data is considered secure. In other words, the data stored in a secure portion is only made accessible to the processor when it is in a secure state (S). According to another definition, the data stored in a secure portion is only accessible to a secure application adapted to implement secure transactions. A non-secure memory area is a portion of memory whose data is considered non-secure. In other words, the data stored in a non-secure portion is made accessible to the processor, when it is in a non-secure state (NS).According to another definition, data stored in an unsecured part is accessible to any application suitable for implementing unsecured transactions. For example, for security reasons, all memory areas of a memory are secured by default, and some are defined as unsecured thereafter.

[0044] According to a preferred embodiment, each memory area has two possible security attribute values. A memory area can be unsecured or callable unsecured. A callable unsecured area is an area that is secure but can be accessed by the processor when it is in an unsecured mode. When the processor is operating in an unsecured mode, it can only access a callable unsecured area by using a specific secure instruction. According to another definition, a callable unsecured part is a part that is secure, but in which functions can be called by unsecured applications using a secure communication channel adapted to transfer secure instructions, such as a secure gateway (SG).

[0045] The memory allocation unit 222 is a security allocation unit adapted to divide a memory into several memory ranges, and to associate with each of them a security level, or a security attribute value. The unit 222 is called in English Security Attribution Unit (SAU), for security attribution unit. According to an example, the unit 222 is an electronic component forming part of the processor 220. The data making it possible to configure a memory range are stored in registers of the memory allocation unit 222.

[0046] According to one embodiment, each memory range has three possible security levels. According to one embodiment, a memory range can be secure, unsecure, or callable unsecure. Thus, a memory range defined by unit 222 includes an additional level of security compared to a memory area defined by unit 221 which can only include two different security attribute values. A secure memory range has the same characteristics as a secure physical memory area. An unsecure memory range has the same characteristics as an unsecure physical memory area. A callable unsecure memory range has the same characteristics as a callable unsecure physical memory area.

[0047] According to one embodiment, the unit 222 is adapted to provide a finite number of memory ranges. According to one example, the unit 222 is adapted to provide eight memory ranges. If the memory ranges provided by the unit 222 do not all cover the memory 230, the memory ranges that are not covered have a security level equal to secure.

[0048] the configuration interface 200 is a software tool for configuring hardware resources, and in particular memory resources, managed by the processor 220 for their use by the application 210. For this, the configuration interface 200 is configured to receive information from the application 210, and from the processor 220, and in particular from the unit 221. The configuration interface 200 is, furthermore, adapted to provide configuration data to the unit 222. The configuration interface 200 is particularly adapted to be based on a division of the memory 230 into memory areas, carried out by the unit 221, then to provide configuration data to obtain the memory ranges defined by the unit 222, according to the memory resources necessary for the operation of the application 210.The configuration interface 200 makes it possible, among other things, to optimize the number of memory ranges and to modify their security attribute values. The configuration interface 200 is, moreover, particularly suitable for allowing the designer of the application to modify the memory resources used by the application 210, by modifying the values ​​of their security attributes. The operation of the configuration interface 200 is described in more detail in relation to the . figures 3 à 12 .

[0049] There figure 3 is a block diagram illustrating a mode of implementation of a method 300 for configuring an application, and more particularly a method for configuring memory areas of a memory and memory resources used by an application, this method 300 being implemented by the configuration interface 200 (MMT), the application 210 (APP), and the processor 220 (CPU), all described in relation to the figure 2 .

[0050] In a step 301 (IDAU: MRegion), the processor 220 uses the hardware allocation unit 221 to divide, in hardware, a memory into several memory areas. As described previously, each memory area is, further, defined by a starting address, a size, a value of a security attribute, and, according to one example, an ending address.

[0051] The hardware allocation unit 221 provides, at the end of step 301, a list of data groups each representing a memory area. This list represents a hardware division of the memory 230. On the basis of this hardware division of the memory 230, the configuration interface 200 constructs a second list by replacing the callable non-secure memory areas with secure areas to facilitate the user experience. This second list is constructed by the configuration interface 200 and is hereinafter referred to as the primary memory division. Step 301 is described in more detail in relation to the figure 4 .

[0052] In a step 302 (App: AppReg in MRegion), following step 301, a designer of the application 210 establishes a list of memory resources that the application 210 needs to operate. Each memory resource is characterized by a value of a security attribute.

[0053] According to one embodiment, each memory resource has three possible security levels. According to one embodiment, a memory resource can be secure, unsecure, or callable unsecure. A secure memory resource has the same characteristics as a secure memory range or a secure physical memory area. An unsecure memory resource has the same characteristics as an unsecure memory range or an unsecure physical memory area. A callable unsecure memory resource has the same characteristics as a callable unsecure memory range or a callable unsecure physical memory area.The security level of a portion of memory is kept the same as that of the memory resource associated with it, for example by changing the security level of a portion of memory, and / or allocating another memory resource to a portion of memory to match the security levels.

[0054] The designer of the application 210 then declares the locations of these memory resources in the memory areas defined by the hardware allocation unit 221 in step 301, using the primary division defined previously. In other words, the designer of the application 210 chooses, for each memory resource, the physical memory area in which the memory resource is placed. According to one example, if the designer knows the value of the security attribute of a memory resource, he can choose a memory area having this security attribute value. The implementation of step 302 is described in relation to the figure 5 .

[0055] In a step 303 (MMT: Security Check), following step 302, once the declaration of all the locations of the memory resources of the application 210 is complete, the designer can decide, according to one embodiment, to modify the values ​​of the security attributes of the memory resources in the different memory zones. To carry out this step, the designer of the application uses the configuration interface 200.

[0056] In a step 304 (MMT: Merge MRegion), subsequent to step 303, once all the modifications have been made in step 303, the configuration interface 200 merges the contiguous memory areas of the same security attribute value to obtain a new division of the memory. More particularly, the configuration interface 200 merges two memory areas if they share the same security attribute and if they are contiguous. Similarly, the configuration interface 200 merges two memory areas / portions if they share the same security attribute and if they are contiguous. In addition, the configuration interface 200 merges two memory areas / portions if one is unsecured and the other is unsecured callable and is also located in an unsecured callable area in the hardware division of the memory. The secure callable memory resource is strictly contiguous to the unsecured memory area or separated by a hardware reserved memory area.

[0057] This division obtained in step 304 is hereinafter referred to as the secondary division of the memory. This step is described in more detail in relation to the figures 6 à 8 .

[0058] More particularly, two memory resources are considered by the configuration interface 200 as contiguous: if they are actually contiguous; if they are separated by a hardware-unusable reserved memory area to which any access generates a bus error; or if they are located in the same aliased memory area.

[0059] The definition of an aliased memory area is as follows. An aliased memory area is a memory area in which physical memories are linked to at least two different memory areas from the processor's point of view.

[0060] Similarly, two memory areas or memory parts are considered by the configuration interface 200 as contiguous: if their respective boundary memory resources are contiguous; or if one of them contains no memory resources.

[0061] In an aliased memory area, the configuration interface 200 enforces that the memory resource has the same security attribute as the memory area where it is located in the hardware division of memory. That is, if the application designer changes the security attribute of a memory resource in an aliased memory area, the configuration interface 200 moves the memory resources to the memory area of ​​the new security attribute, with this memory area pointing to the same physical alias. memory.

[0062] The secondary division of the memory is only used by the configuration interface 200 for the remainder of the configuration process, and is not transmitted to the unit 221.

[0063] At a step 305 (MMT: Def SAU Region), following step 304, the secondary division of the memory into memory zones is ready, it is then possible to constitute a set of data representing a virtual memory associated with the application 210 based on the secondary division of the memory and the location of the memory resources used by the application 210. Here, the virtual memory associated with the application 210 is called the set of memory zones occupied by a memory resource of the application 210. The interface 200 therefore generates at step 305 a set of data representing the primary virtual memory from the secondary division of the memory, and from the locations of the declared memory resources of the application 210. This step is described in more detail in relation to the figures 9 And 10 .

[0064] According to one example, the designer may decide to modify the values ​​of the security attributes of the memory resources in the different memory areas at step 305. To carry out this step, the designer of the application uses the configuration interface 200.

[0065] In a step 306 (MMT: Merge SAU Reg), following step 305, once the data representing the primary virtual memory is ready, the configuration interface 200 merges the memory areas comprising contiguous memory resources of the same security attribute value to obtain a set of data representing a new virtual memory, hereinafter called secondary virtual memory, comprising virtual memory resources. Here, two memory resources are said to be contiguous if they are actually contiguous, or if they are only separated by memory resources that are not used by the application 210. More particularly, two memory resources are said to be contiguous: if they are actually contiguous; or they are located in an aliased memory area and they are only separated by memory resources that are not used by the application 210.Memory areas pointed to the same physical memory device are called aliased memory areas. For aliased memory areas, the configuration interface 200 imposes a rule that the aliased unsecured memory area can only host unsecured memory resources. And the processor's hardware security mechanism does not allow unsecured callable memory areas and secure memory areas to host any unsecured memory resources, i.e., they can only host an unsecured callable memory resource or a secure memory resource. According to one embodiment, the configuration interface merges together only memory areas comprising contiguous resources having the security attribute value "unsecured" and / or "unsecured callable". This step is described in more detail in relation to the . figures 11 et 12 .

[0066] At a step 307 (SAU: Use SAU Reg), following step 306, the data representing the secondary virtual memory are ready, the configuration interface 200 sends this data to the software allocation unit 222 so that it generates this secondary virtual memory, and more particularly the memory ranges which constitute the secondary virtual memory. More particularly, this data representing the secondary virtual memory is data suitable for being stored in registers. This data is, for example, memory addresses and data representing security attribute values.

[0067] According to one embodiment, the configuration method 300 is adapted to be implemented by a non-transitory computer-readable means.

[0068] There figure 4 represents, in more detail, an example of implementation of step 301 described in relation to the figure 3 .

[0069] At an initial stage (A) of step 301, a memory 400 (MEM) is considered which has not been divided by the hardware allocation unit. This memory is seen by the processor 220 as a single large memory area.

[0070] To arrive at a final stage (B) of step 301, the allocation unit 221 has carried out a division of the memory 400 into memory areas 401 (MR1), 402 (MR2), 403 (MR3), 404 (MR4), and 405 (MR5). The memory areas 401 to 405 may be of identical or different sizes. For this, the memory cells whose security attribute value is identical are combined into the same area. As a reminder, the value of the security attribute of a memory area may be secure or non-secure, or according to the preferred embodiment, non-secure or non-secure callable.

[0071] The allocation unit 221 establishes a list comprising data groups defining the memory areas, and provides it to the processor 220. The processor 220 uses this list during its memory accesses. As previously stated, this list represents the primary division of the memory into memory areas.

[0072] According to the preferred embodiment described above, the allocation unit 221 cannot define the value of the security attribute of a memory area as unsecured or callable unsecured. In the final state of step 301, a callable unsecured memory area is perceived by an application designer as a secure area thanks to the configuration interface 200. The configuration interface 200 considers the callable unsecured areas of the primary division as secure areas in the final step of step 301.

[0073] Thus, in phase (B) of step 301, zones 401, 403 and 405 are callable unsecured zones, and zones 402 and 404 are unsecured zones.

[0074] There figure 5 represents, in more detail, an example of implementation of step 302 described in relation to the figure 3 .

[0075] At an initial stage (A) of step 302, corresponding to stage (B) of step 301 described in relation to the figure 5 , the designer of the application 210 uses the configuration interface 200 to configure the memory resources of the application 210. The allocation unit 221 provides, to the configuration interface 200, the list representing the primary division of the memory 400. Thus, as in figure 4 , memory 400 has been divided into five memory areas 401 to 405.

[0076] At a final stage (B) of step 302, the designer declares the locations of the application's memory resources in memory areas 401 to 405. In figure 5 , it is considered that a memory resource 501 (App Reg) of the application 210 must be placed in the memory area 404. Generally, the designer uses the configuration interface to place each memory resource in a memory area of ​​the same security attribute value.

[0077] There figure 6 represents, in more detail, a first case of application of the implementation of step 304 described in relation to the figure 3 .

[0078] During step 303, using the interface 200, the designer of the application 210 had the possibility of modifying the security attribute values ​​associated with each memory resource of the application 210.

[0079] At an initial stage (A) of step 304, the memory resource 501 is an unsecured memory resource, but is still placed in an unsecured memory area.

[0080] At a final stage (B) of step 304, the memory configuration interface 200 tries to optimize the number of memory areas, by merging the contiguous memory areas of the same security attribute value to obtain the secondary division of the memory 230. Here all the contiguous memory areas of the same security attribute value are already merged, the secondary division of the memory remains identical to the primary division defined by the hardware allocation unit 221.

[0081] There figure 7 represents, in more detail, a second case of application of the implementation of step 304 described in relation to the figure 3 .

[0082] At an initial stage (A) of step 304, the memory resource 501 has become a callable unsecured resource, and has been placed in an unsecured memory area.

[0083] At a final stage (B) of step 304, the memory configuration interface 200 defines the secondary division of the memory based on the values ​​of the memory attributes defined in stage (A). Thus, depending on the placement of the memory resource 501 in the memory area 404, the area 404 is divided into two or three memory areas. figure 7 , memory area 404 is considered to be divided into three memory areas 701, 702 and 703, areas 701 and 703 being unsecured memory areas, and memory area 702 being a callable unsecured memory area. Memory resource 501 is placed in memory area 702.

[0084] The secondary division of the memory 400 is, in this case, different from the primary division established by the hardware allocation unit 221.

[0085] There figure 8 represents, in more detail, a third case of application of the implementation of step 304 described in relation to the figure 3 .

[0086] At an initial stage (A) of step 304, as in figure 7 , memory resource 501 has become a callable unsecured resource, and has been placed in an unsecured memory area.

[0087] At a stage (B) of step 304, the memory configuration interface 200 defines the secondary division of the memory based on the values ​​of the memory attributes defined at stage (A). Thus, depending on the placement of the memory resource 501 in the memory area 404, the area 404 is divided into two or three memory areas. figure 8 , memory area 404 is considered to be divided into two memory areas 801 and 802, with area 801 being a callable unsecured memory area, and memory area 802 being an unsecured memory area. Memory resource 501 is placed or declared in memory area 801.

[0088] At a final stage (C) of step 304, the memory configuration interface 200 defines the secondary division of the memory by merging the contiguous memory portions having the same value of the security attribute. This is the case here for the memory areas 403 and 801 which are both callable non-secure memory areas, they are then merged into a memory area 803. The memory resource 501 is therefore placed in the memory area 803.

[0089] The secondary division of the memory 400 is, in this case, different from the primary division established by the hardware allocation unit 221.

[0090] There figure 9 represents, in more detail, an example of implementation of step 305 described in relation to the figure 3 .

[0091] At an initial stage (A) of step 305, the interface 200 has at its disposal the data representing the secondary division of the memory, as well as those representing the distribution of the declared memory resources of the application 210 in the memory areas of the memory 230.

[0092] So in figure 9 , the memory resources of application 210 are as follows: a secure memory resource 901 (App Reg 1), disposed in the callable unsecure memory area 401; a callable unsecure memory resource 902 (App Reg 2), disposed in the callable unsecure memory area 401; a non-secure memory resource 903 (App Reg 3), disposed in the unsecure memory area 402; a non-secure memory resource 904 (App Reg 4), disposed in the unsecure memory area 404; a non-secure memory resource 905 (App Reg 5), disposed in the unsecure memory area 404; and a non-secure memory resource 906 (App Reg 6), disposed in the unsecure memory area 404.

[0093] According to one embodiment, the value of the security attribute of the memory resources can be modified according to the value of the memory attribute of the memory area in which the memory resource is placed. The rules for adapting these values ​​are described in relation to the figure 10 .

[0094] At a final stage (B) of step 305, data representing a primary virtual memory 900 (App Region) associated with the application 210 are generated. This primary virtual memory 900 comprises the memory resources 901 to 906. For the memory, a virtual memory associated with the application is a set of data values ​​based on the secondary division of the memory and on the position of the memory resources used for the application. This virtual memory is generated by the interface 200.

[0095] There figure 10 represents, very schematically and in the form of blocks, the rules for adapting the values ​​of the security attributes of memory resources of an application according to the value of the security attribute of memory areas in which they are placed.

[0096] In figure 10 A physical memory 1000 is shown divided into six memory areas 1001 (NS), 1002 (NS), 1003 (NS), 1004 (NSC-S), 1005 (NSC-S), and 1006 (NSC-S). Memory areas 1001 to 1003 are unsecured memory areas and memory areas 1004 to 1006 are, according to the preferred embodiment, callable unsecured memory areas.

[0097] Is represented, in addition in figure 10 , a list 1010 of six memory resources 1011 (S), 1012 (NSC), 1013 (NS), 1014 (S), 1015 (NSC), and 1016 (NS) of an application, each adapted to be arranged in one of the memory areas 1001 to 1006. Each memory resource 1011 to 1016 includes an attribute value corresponding to the attribute value desired by the designer of the application. More particularly, memory resources 1011 and 1014 are secure memory resources, memory resources 1012 and 1015 are callable non-secure memory resources, and memory resources 1013 and 1016 are non-secure memory resources.

[0098] In the example of the figure 10 : memory resource 1011 is placed in memory area 1001; memory resource 1012 is placed in memory area 1002; memory resource 1013 is placed in memory area 1003; memory resource 1014 is placed in memory area 1004; memory resource 1015 is placed in memory area 1005; and memory resource 1016 is placed in memory area 1006.

[0099] In figure 10 , is further represented a list 1020 corresponding to the final list provided by the interface 200 to the unit 222 once the values ​​of the security attributes of the memory areas and the values ​​of the security attributes of the memory resources have been combined.

[0100] If an unsecured memory resource is placed in a callable unsecured memory area, then the memory resource becomes callable unsecured. If an unsecured callable memory resource is placed in an unsecured memory area, then the memory resource remains callable unsecured.

[0101] According to a preferred embodiment, the interface 200 may prohibit the placement of an unsecured memory resource in a callable unsecured memory area.

[0102] Thus, the modified memory resource list 1020 can be generated by the interface 200, and includes: the secure memory resource 1011; the callable unsecure memory resource 1012; the unsecure memory resource 1013; the secure memory resource 1014; the callable unsecure memory resource 1015; and a callable unsecure memory resource 1026.

[0103] There figure 11 represents, very schematically and in the form of blocks, a first mode of implementation of steps 302 to 306 described in relation to the figure 3 .

[0104] Consider a memory resource list 1100 (App Reg). List 1100 includes eight memory parts 1101 (NS - App Reg 1), 1102 (NS - App Reg 2), 1103 (S - App Reg 3), 1104 (S - App Reg 4), 1105 (NS - App Reg 5), 1106 (NS - App Reg 6), 1107 (NSC - App Reg 7) and 1108 (S - App Reg 8), including: parts 1101, 1102, 1105 and 1106 are unsecured; parts 1103, 1104 and 1108 are secure; and part 1107 is unsecured callable.

[0105] Phase (A) represents the list 1100 representing the data making it possible to obtain a primary virtual memory associated with the application 210.

[0106] Phase (B) represents a list 1110 representing data for obtaining a secondary virtual memory associated with the application 210. In other words, in phase (B), certain memory resources have been merged. In particular, since the memory portions 1101 and 1102 are contiguous and both are unsecured memory portions, they have been merged into an unsecured memory portion 1111. Similarly, since the memory portions 1105 and 1106 are contiguous and both are unsecured memory portions, they have been merged into an unsecured memory portion 1112.

[0107] Thus, at the end of step 306, the secondary virtual memory associated with the application has a lower number of memory resources compared to the non-optimized primary virtual memory.

[0108] There figure 12 represents, very schematically and in the form of blocks, a second mode of implementation of steps 302 to 306 described in relation to the figure 3 .

[0109] Consider a memory resource list 1200 (App Reg). List 1200 includes eight memory parts 1201 (NS - App Reg 1), 1202 (NS - App Reg 2), 1203 (S - App Reg 3), 1204 (S - App Reg 4), 1205 (NS - App Reg 5), 1206 (NS - App Reg 6), 1207 (NSC - App Reg 7) and 1208 (S - App Reg 8), including: parts 1201, 1202, 1205 and 1206 are unsecured; parts 1203, 1204 and 1208 are secure; and part 1207 is unsecured callable.

[0110] Phase (A) represents the list 1200 representing the data making it possible to obtain a primary virtual memory associated with the application 210.

[0111] Phase (B) represents a list 1210 representing data making it possible to obtain a secondary virtual memory associated with the application 210. In other words, in phase (B), certain memory resources have been merged. In particular, memory resources 1201 and 1202 being contiguous and both being unsecured parts of memory, they have been merged into an unsecured memory range 1211 (SAU Reg 1). The definition of the word contiguous is that given previously.

[0112] Furthermore, and according to a variant with respect to the embodiment described in relation to the figure 11, it is considered here that if a callable unsecured memory resource is strictly contiguous with an unsecured memory area or portion, and if this callable unsecured memory resource is placed in a memory area considered callable unsecured according to the primary division of memory, then the two memory portions can be merged into one unsecured memory portion. Thus, memory portions 1205, 1206 and 1207 are merged into one unsecured memory portion 1212 (SAU Reg 2).

[0113] Thus, at the end of step 306, the secondary virtual memory associated with the application has a lower number of memory resources compared to the non-optimized primary virtual memory.

[0114] Various embodiments and variations have been described. Those skilled in the art will understand that certain features of these various embodiments and variations could be combined, and other variations will occur to those skilled in the art.

[0115] According to one embodiment, if the value of the attribute of the first part (1206) is equal to unsecure, and if the value of the attribute of the second part (1207) is equal to unsecure callable, and if the second part (1207) is located in a memory area considered unsecure callable by the first memory division, and the second part (1207) is strictly contiguous to the first part (1206), then said at least two first and second parts (1206, 1207) are merged into the third part (1212) and the value of the attribute of the third part (1212) is equal to unsecure.

[0116] Finally, the practical implementation of the described embodiments is within the reach of the person skilled in the art from the functional indications given above.

Claims

1. Method for configuring (300) a memory (230) to perform an application (210) adapted to be run by a processor (101; 220) and using at least two first and second contiguous memory resources (401-405; 901-906; 1101-1108; 1201-1208) associated to an application and disposed in at least one memory area (401-405) of the memory (102; 230; 400; 900; 1100; 1200), wherein said method (300) comprises a step for merging (306) said at least two first and second memory resources (901-906; 1101-1108; 1201-1208) into a third memory resource (803; 1111; 1112; 1211, 1212), if said at least two first and second memory resources (901-906; 1101-1108; 1201-1208) have the same value of a security attribute, the method further comprising a step for generating (307) data for configuring memory ranges of the memory (102; 230; 400; 900; 1100; 1200), wherein said value of said security attribute indicates the security level of a portion (401-405; 901-906; 1101-1108; 1201-1208) of the memory (102; 230; 400; 900; 1100; 1200), wherein said value of said attribute of a memory resource (901-906; 1101-1108; 1201-1208) of said application (210) can be equal to: - secure; - non-secure; and - non-secure callable, wherein, if the value of the attribute of the first portion (1206) is equal to non-secure, and the value of the attribute of the second portion (1207) is equal to non-secure callable, and the second portion (1206) is located in a memory area the attribute value of which is equal to non-secure callable, then said at least two first and second portions (1206, 1207) are merged into the third portion (1212) and the value of the attribute of the third portion (1212) is equal to non-secure.

2. Device (100) comprising a configuration interface (200) adapted to implement a method for configuring (300) a memory (230) to perform an application (210) adapted to be run by a processor (101; 220) and using at least two first and second contiguous memory resources (401-405; 901-906; 1101-1108; 1201-1208) associated to an application and disposed in at least one memory area (401-405) of at least one memory (102; 230; 400; 900; 1100; 1200), wherein said method (300) comprises a step for merging (306) said at least two first and second memory resources (901-906; 1101-1108; 1201-1208) into a third memory resource (803; 1111; 1112; 1211, 1212), if said at least two first and second portions (901-906; 1101-1108; 1201-1208) have the same value of a security attribute, the method further comprising a step for generating (307) data for configuring memory ranges of the memory (102; 230; 400; 900; 1100; 1200), characterized in that said value of said security attribute indicates the security level of a portion (401-405; 901-906; 1101-1108; 1201-1208) of the memory (102; 230; 400; 900; 1100; 1200), wherein said value of said attribute of a memory resource (901-906; 1101-1108; 1201-1208) of said application (210) can be equal to: - secure; - non-secure; and - non-secure callable, wherein, if the value of the attribute of the first portion (1206) is equal to non-secure, and the value of the attribute of the second portion (1207) is equal to non-secure callable, and the second portion (1206) is located in a memory area the attribute value of which is equal to non-secure callable, then said at least two first and second portions (1206, 1207) are merged into the third portion (1212) and the value of the attribute of the third portion (1212) is equal to non-secure, said device further comprising said processor (101, 220) adapted to implementing the application (210), and said at least one memory (102; 230; 400; 900; 1100; 1200).

3. Non-transitory means readable by a computer comprising program instructions adapted, when these instructions are executed by the computer, to implement the method according to claim 1.