Configuring a memory

Abstract

Configuring a memory The present description relates to a method for configuring a memory (230) for the execution of an application (210) adapted to be executed by a processor (220) 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 (230), in which 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 data for configuring memory areas of a memory. Figure for abstract: Fig. 2

Description

Title of the invention: Configuration of a memory Technical field

[0001] The present description relates generally to electronic circuits and devices and the software applications that they can implement. The present description relates more particularly to a configuration interface for an application executed by a processor. Prior art

[0002] A processor, called in English "Central Processing Unit" (CPU), is a complex electronic component which 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 which 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.

[0004] It would be desirable to be able to improve, at least in part, certain aspects of the execution of an application 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 the memories associated with the processor.

[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 a configuration interface for an application executed by a processor, further enabling optimization of the number of memory ranges associated with the application used by an application based on values ​​representing security levels of said memory ranges associated with the application.

[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 via 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 comprise one or more registers indicating memory ranges, with given security levels.

[0012] An embodiment provides a method for 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, in which 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 data for configuring memory areas 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, in which 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 data for configuring memory areas 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; - unsecured; and - unsecured 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.

[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. Brief description of the drawings

[0021] These characteristics and advantages, as well as others, will be explained in detail in the following description of particular embodiments given without limitation in relation to the attached figures among which:

[0022] [Fig.l] represents, very schematically and in the form of blocks, an example of an electronic device adapted to the implementation of the embodiments of figures 2 to 12;

[0023] [Fig.2] represents, very schematically and in the form of blocks, an embodiment of an application configuration interface;

[0024] [Fig.3] represents a block diagram illustrating a mode of implementation of a method for configuring an application;

[0025] [Fig.4] represents, very schematically and in the form of blocks, an example of the implementation of a step of the configuration method of [Fig.3];

[0026] [Fig.5] represents, very schematically and in the form of blocks, an example of the implementation of another step of the configuration method of [Fig.3];

[0027] [Fig.6] represents, very schematically and in the form of blocks, an example of the implementation of another step of the configuration method of [Fig.3];

[0028] [Fig.7] represents, very schematically and in the form of blocks, an example of the implementation of another step of the configuration method of [Fig.3];

[0029] [Fig.8] represents, very schematically and in the form of blocks, an example of the implementation of another step of the configuration method of [Fig.3];

[0030] [Fig.9] represents, very schematically and in the form of blocks, an example of the implementation of another step of the configuration method of [Fig.3];

[0031] [Fig. 10] represents, very schematically and in the form of blocks, an example of the implementation of another step of the configuration method of [Fig.3];

[0032] [Fig. 1 1] represents, very schematically and in the form of blocks, an example of the implementation of another step of the configuration method of [Fig. 3]; and

[0033] [Fig. 12] represents, very schematically and in the form of blocks, an example of the implementation of another step of the configuration method of [Fig.3]. Description of the embodiments

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

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

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

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

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

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

[0040] According to one embodiment, the configuration interface comprises 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 feature is to allow generating 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.

[0041] To implement these functionalities, the configuration interface is based on values ​​of a security attribute associated with each portion, part or memory area, and with each memory resource required by the application. More particularly, 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 relation to [Fig. 10].

[0042] [Fig.l] 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.

[0043] 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 [Fig.2].

[0044] 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 [Fig.2].

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

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

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

[0048] [Fig.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).

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

[0050] According to one embodiment, the processor 220 is of the type of the processor 101 described in relation to [Fig.l]. 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.

[0051] According to one example, the memory 230 is a memory of the type of memories 102 described in relation to [Fig.l]. The memory 230 is made up 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.

[0052] 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).

[0053] 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 in English Implementation Defined Attribution Unit (IDAU), for 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. According to one embodiment, each physical memory area is defined by: - ​​a start address; - a size; - optionally, an end address; and - by a value of the security attribute.

[0054] Here we call the start address the address of the first memory cell in a memory area, i.e. the address of the memory cell of rank zero in the memory area. Similarly, here we call the end address the address of the last cell memory of a memory area, that is to say the address of the memory cell of rank Nl in the memory area, N being an integer designating the size of the memory area.

[0055] 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). 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 one example, for security reasons, all memory areas of a memory are secure by default, and some are defined as non-secure thereafter.

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

[0057] 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 allocation 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.

[0058] According to one embodiment, each memory range has three possible security levels. According to one embodiment, a memory range can be secure, non-secure, or callable non-secure. Thus, a memory range defined by unit 222 includes an additional security level 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 non-secure memory range has the same characteristics as an non-secure physical memory area. A callable non-secure memory range has the same characteristics as a callable non-secure physical memory area.

[0059] 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 are available. If the memory ranges made available 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.

[0060] 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, as a function of 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 FIGS. 3 to 12.

[0061] [Fig. 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 [Fig. 2].

[0062] 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, in addition, defined by a starting address, a size, a value of a security attribute, and, according to one example, an ending address.

[0063] 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 first division of the memory 230, and is hereinafter referred to as the primary division of the memory. Step 301 is described in more detail in relation to [Fig.4].

[0064] At a step 302 (App: AppReg in MRegion), following step 301, a designer of the application 210 establishes a list of memory resources which the application 210 has needed to function. Each memory resource is characterized by a security attribute value.

[0065] According to one embodiment, each memory resource has three possible security levels. According to one embodiment, a memory resource can be secure, non-secure, or callable non-secure. A secure memory resource has the same characteristics as a secure memory range or a secure physical memory area. An insecure memory resource has the same characteristics as an insecure memory range or an insecure physical memory area. A callable non-secure memory resource has the same characteristics as a callable non-secure memory range or a callable non-secure physical memory area.

[0066] 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 [Fig. 5].

[0067] At 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.

[0068] At a step 304 (MMT: Merge MRegion), following step 303, once all the modifications have been made at step 303, the configuration interface 200 merges the contiguous memory areas with the same security attribute value to obtain a new division of the memory. This division is referred to hereinafter as the secondary division of the memory. This step is described in more detail in relation to FIGS. 6 to 8. Here, "contiguous memory areas" are used to refer to at least two memory areas whose memory cell addresses are consecutive.

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

[0070] 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 areas occupied by a memory resource of the application 210. The interface 200 therefore generates in 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 figures 9 and 10.

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

[0072] At 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 with the same security attribute value to obtain a set of data representing a new virtual memory, hereinafter called secondary virtual memory. 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. According to one embodiment, the configuration interface merges together only the memory areas comprising contiguous resources having the security attribute value "non-secure" and / or "non-secure callable" value. This step is described in more detail in relation to FIGS. 11 and 12.

[0073] 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 adapted to be stored in registers. This data is, for example, memory addresses and data representing security attribute values.

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

[0075] [Fig.4] represents, in more detail, an example of implementation of step 301 described in relation to [Fig.3].

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

[0077] 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 allocation unit 221 combines into a single area the memory cells whose security attribute value is identical. As a reminder, the security attribute value of a memory area may be secure or non-secure, or according to the preferred embodiment, non-secure or non-secure callable.

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

[0079] 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. A callable unsecured memory area is perceived by an application designer as a secure area.

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

[0081] [Fig.5] represents, in more detail, an example of implementation of step 302 described in relation to [Fig.3].

[0082] At an initial stage (A) of step 302, corresponding to stage (B) of step 301 described in relation to [Fig. 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 [Fig. 4], the memory 400 has been divided into five memory areas 401 to 405.

[0083] At a final stage (B) of step 302, the designer declares the locations of the memory resources of the application in the memory areas 401 to 405. In [Fig.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 places each memory resource in a memory area of ​​the same security attribute value.

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

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

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

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

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

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

[0090] 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. In [Fig.7], it is considered that the memory area 404 is divided into three memory areas 701, 702 and 703, the areas 701 and 703 being unsecured memory areas, and the memory area 702 being a callable unsecured memory area. The memory resource 501 is placed in the memory area 702.

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

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

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

[0094] 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. In [Fig.8], it is considered that the memory area 404 is divided into two memory areas 801 and 802, the area 801 being a callable non-secure memory area, and the area memory 802 being an unsecured memory area. The memory resource 501 is placed or declared in the memory area 801.

[0095] At a final stage (C) of step 304, the memory configuration interface 200 defines the secondary division of the memory by merging the memory parts 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.

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

[0097] [Fig.9] represents, in more detail, an example of implementation of step 305 described in relation to [Fig.3].

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

[0099] Thus in [Fig.9], the memory resources of the application 210 are as follows: - a secure memory resource 901 (App Reg 1), arranged in the callable non-secure memory zone 401; - a callable unsecured memory resource 902 (App Reg 2), located in callable unsecured memory area 401; - an unsecured memory resource 903 (App Reg 3), located in the unsecured memory area 402; - an unsecured memory resource 904 (App Reg 4), located in the unsecured memory area 404; - an unsecured memory resource 905 (App Reg 5), located in the unsecured memory area 404; and - an unsecured memory resource 906 (App Reg 6), located in the unsecured memory area 404.

[0100] 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 [Fig. 10].

[0101] At a final stage (B) of step 305, the 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.

[0102] [Fig. 10] represents, very schematically and in the form of blocks, the rules for adapting the values ​​of the security attributes of memory resources of a application depending on the value of the security attribute of memory areas in which they are placed.

[0103] In [Fig. 10] is shown a physical memory 1000 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.

[0104] Further shown in [Fig.10] is 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 comprises 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.

[0105] In the example of [Fig. 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.

[0106] In [Fig. 10], there 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.

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

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

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

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

[0111] Consider a list of memory resources 1100 (App Reg). The list 1100 comprises 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), among which: - parts 1101, 1102, 1105 and 1106 are unsecured; - parts 1103, 1104 and 1108 are secure; and - part 1107 is unsecured callable.

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

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

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

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

[0116] Consider a list of memory resources 1200 (App Reg). The list 1200 comprises 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), among which: - parts 1201, 1202, 1205 and 1206 are unsecured; - parts 1203, 1204 and 1208 are secure; and - part 1207 is unsecured callable.

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

[0118] 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, since memory resources 1201 and 1202 are contiguous and both are unsecured portions of memory, they have been merged into an unsecured memory range 1211 (SAU Reg 1).

[0119] In addition, and according to a variation with respect to the embodiment described in relation to [Fig. 11], it is considered here that if a callable unsecured memory resource is contiguous with an unsecured memory portion, and if this callable unsecured memory resource is placed in a callable unsecured memory area, 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).

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

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

[0122] Finally, the practical implementation of the embodiments and variants described is within the reach of those skilled in the art from the functional indications given above.

Claims

Claims

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

2. Configuration interface (200) adapted to implement a method of configuring (300) a memory (230) for the execution of an application (210) adapted to be executed by a processor

3.

4.

5. (101; 220) and using at least two first and second contiguous memory resources (401 to 405; 901 to 906; 1101 to 1108; 1201 to 1208) associated with an application and placed in at least one memory area (401 to 405) of at least one memory (102; 230; 400; 900; 1100; 1200), wherein said method (300) comprises a step of merging (306) said at least two first and second memory resources (901 to 906; 1101 to 1108; 1201 to 1208) into a third memory resource (803; 1111, 1112; 1211, 1212), if said at least two first and second portions (901 to 906; 1101 to 1108; 1201 to 1208) have the same value of a security attribute, the method further comprising a step of generating (307) memory range configuration data of a memory (102; 230; 400; 900; 1100; 1200), said value of said security attribute designates the security level of a portion (401 to 405; 901 to 906; 1101 to 1108; 1201 to 1208) of a memory (102; 230; 400; 900; 1100; 1200), said value of said attribute of a memory resource (901 to 906; 1101 to 1108; 1201 to 1208) of said application (210) may be equal to: - secure; - unsecured; and - unsecured callable, if the value of the attribute of the first portion (1206) is equal to unsecure, and the value of the attribute of the second portion (1207) is equal to unsecure callable, and the second portion (1206) 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 (1206, 1207) are merged into the third portion (1212), and the value of the attribute of the third portion (1212) is equal to unsecure. Device (100) comprising an interface (200) according to claim 2. Device according to claim 3, further comprising said processor (101; 220) adapted to implement the application (210). Device according to claim 3 or 4, further comprising said at least one memory (102; 230; 400; 900; 1100; 1200).

6. A non-transitory computer-readable means adapted to carry out the method of claim 1.

Images