WO2022063720A1 - Gestion de mémoire pour des applications d'un élément sécurisé intégré à des systèmes d'exploitation multiples - Google Patents

Gestion de mémoire pour des applications d'un élément sécurisé intégré à des systèmes d'exploitation multiples Download PDF

Info

Publication number
WO2022063720A1
WO2022063720A1 PCT/EP2021/075778 EP2021075778W WO2022063720A1 WO 2022063720 A1 WO2022063720 A1 WO 2022063720A1 EP 2021075778 W EP2021075778 W EP 2021075778W WO 2022063720 A1 WO2022063720 A1 WO 2022063720A1
Authority
WO
WIPO (PCT)
Prior art keywords
application
volatile memory
execution
applications
level operating
Prior art date
Application number
PCT/EP2021/075778
Other languages
English (en)
Inventor
Olivier Van Nieuwenhuyze
Amedeo Veneroso
Original Assignee
Stmicroelectronics S.R.L.
Proton World International N.V.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from FR2009751A external-priority patent/FR3114670A1/fr
Priority claimed from FR2009752A external-priority patent/FR3114671A1/fr
Application filed by Stmicroelectronics S.R.L., Proton World International N.V. filed Critical Stmicroelectronics S.R.L.
Priority to CN202180066011.8A priority Critical patent/CN116209982A/zh
Priority to EP21770040.0A priority patent/EP4217861A1/fr
Publication of WO2022063720A1 publication Critical patent/WO2022063720A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/4401—Bootstrapping
    • G06F9/4406—Loading of operating system
    • G06F9/441—Multiboot arrangements, i.e. selecting an operating system to be loaded
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F12/00—Accessing, addressing or allocating within memory systems or architectures
    • G06F12/02—Addressing or allocation; Relocation
    • G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
    • G06F12/0284—Multiple user address space allocation, e.g. using different base addresses
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/78—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
    • G06F2212/20—Employing a main memory using a specific memory technology
    • G06F2212/205—Hybrid memory, e.g. using both volatile and non-volatile memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2149—Restricted operating environment

Definitions

  • the present disclosure generally concerns electronic systems and, more particularly, embedded electronic systems.
  • the present disclosure more particularly concerns the use of memories in an embedded electronic system.
  • An embedded electronic system is a self-contained electronic and software system capable of being embedded in an electronic device and/or electronic equipment.
  • the design issues of an embedded system are frequently due to management constraints of memories internal or external to the embedded system.
  • the system may comprise non-volatile memories, rewritable or not, and volatile memories, each capable of storing data of different types with the constraints and assets specific to each type of memory.
  • the management of these memories generates constraints in terms of data security, particularly when the system is used for different applications.
  • US 2018/0113817 discloses a virtualization-based platform protection technology in which two memories are used for different applications.
  • US 2018/0165008 discloses a memory transaction prioritization technology.
  • US 2015/ 0113257 discloses a system and method for dual OS memory switching, in which an application replaces the other in volatile memory .
  • device firmware saves content of overlapped memory location being used for the first OS in volatile memory to nonvolatile memory and loads contents of second OS to overlapped memory locations in volatile memory .
  • EP 1 524 597 discloses a method for managing threads in a memory-constrained system .
  • An embodiment of a first aspect provides an embedded electronic system comprising :
  • said volatile memory comprises : at least a first portion reserved to execution data of a first application; and at least a second portion intended to store execution data of at least a second application, the execution data of the first application remaining in the volatile memory in case of a deactivation or of a setting to standby of this first application .
  • An embodiment of the first aspect provides a method implemented by an embedded electronic system comprising :
  • At least one low-level operating system managing the al location of areas of the volati le memory to a plural ity of high-levels operating systems , each comprising one or a plurality of applications
  • said volatile memory comprises : at least a first portion reserved to execution data of a first application; and at least a second portion intended to store execution data of at least a second application, the execution data of the first application remaining in the volatile memory in case of a deactivation or of a setting to standby of this first application .
  • data of execution of one of a plurality of tasks of an application are partly trans ferred, by the low-level operating system, from said volatile memory to a nonvolatile memory when the execution of said task is interrupted by the execution of at least one task of another application .
  • a volatile memory area is allocated to the second application while the second application is not executed, the execution data of this second application being trans ferred into the non-volatile memory i f the available volatile memory si ze is not suf ficient for the execution of a third application .
  • An embodiment of a second aspect provides an embedded electronic system comprising :
  • At least one low-level operating system managing the allocation of volatile memory areas to a plurality of high- level operating systems , each comprising one or a plurality of applications , wherein execution data of one or a plurality of tasks of said first application are partly trans ferred, by the low-level operating system, from said volatile memory to a non-volatile memory when the execution of said task of the first application is interrupted by the execution of at least one task of a second application .
  • An embodiment of the second aspect provides a method implemented in an embedded electronic system comprising :
  • At least one low-level operating system managing the allocation of volatile memory areas to a plurality of high- level operating systems , each comprising one or a plurality of applications , wherein execution data of one or a plurality of tasks of said first application are partly trans ferred, by the low-level operating system, from said volatile memory to an area of a non-volatile memory when the execution of said task of the first application is interrupted by the execution of at least one task of a second application .
  • the applications of a high-level operating system do not have access to the volatile memory areas allocated to the applications of another high-level operating system.
  • a memory management function or unit executed by the low-level operating system forbids the access of the execution data of an application to other applications.
  • the memory management function or unit adapts the size of the first and second portions of the volatile memory according to the needs of the different applications.
  • the execution data of a plurality of applications are simultaneously present in the volatile memory.
  • the non-volatile memory is external to the embedded electronic system.
  • an execution code of an application is transferred to the volatile memory for its execution.
  • the non-volatile memory is internal to the embedded electronic system.
  • an execution code of an applications remains in the non-volatile memory during the execution of a task.
  • a non-volatile memory area allocated to a high- level operating system is seen by the latter as a volatile working memory.
  • the high-level operating systems manage a virtual image of the memories where the volatile and non-volatile memories are one and the same.
  • a main task of an application is allocated a volatile memory area.
  • part of its execution data if transferred into the volatile memory when the application need specifically of the one that are not yet loaded into the volatile memory.
  • An embodiment provides an embedded secure element, configured for the implementation of the described system or method.
  • Figure 1 schematically shows in the form of blocks an embodiment of hardware components of an embedded secure element or embedded electronic system
  • Figure 2 very schematically shows in the form of blocks a software architecture of an embedded electronic system
  • Figure 3 shows views (a) , (b) , and (c) schematically illustrating in the form of blocks the implementation of a method of execution of applications of the embedded electronic system of Figures 1 and 2;
  • Figure 4 shows views (a) , (b) , and (c) schematically illustrating in the form of blocks an implementation mode of a method of execution of applications of the embedded electronic system of Figures 1 and 2;
  • Figure 5 shows views (a) , (b) , and (c) schematically illustrating in the form of blocks the implementation of a method of execution of applications of the embedded electronic system of Figures 1 and 2;
  • Figure 6 shows views (a) , (b) , and (c) schematically illustrating in the form of blocks another implementation mode of a method of execution of applications of the embedded electronic system of Figures 1 and 2.
  • FIG 1 very schematically shows in the form of blocks an embodiment of hardware components HW (Hardware) of an embedded secure element E or embedded electronic system.
  • HW Hardware
  • Element E is made in the form of an electronic circuit comprising, in hardware form:
  • PU digital processing units
  • CPU central processing unit
  • programmable logic circuit etc .
  • PU digital processing units
  • RAM volatile
  • NVM nonvolatile
  • circuit 1 - one or a plurality of data, address, and/or control buses 14 between the different elements internal to circuit 1;
  • circuit 1 - one or a plurality of input/output interfaces 15, (I/O) of wired or wireless communication with the outside of circuit 1;
  • NFC near-field communication circuit 16
  • FCT short distance communication device
  • Bluetooth standard for example using the Bluetooth standard, biometric sensors, etc.
  • Figure 2 schematically shows in the form of blocks a software architecture 100 of an embedded secure element E, or secure embedded electronic system.
  • Software architecture 100 is implemented by the hardware components HW of the secure element E described in Figure 1.
  • Architecture 100 comprises a primary platform 110, generally called virtual primary platform (VPP) comprising the access to the electronic components 111 (HW) of secure element E and comprising one or a plurality of low-level operating systems 113 (LLOS) .
  • VPP virtual primary platform
  • HW electronic components 111
  • LLOS low-level operating systems 113
  • Low-level operating systems 113 are operating systems enabling to ease the communication between one or a plurality of high-level operating systems (HLOS1, HLOS2, HLOS) 124A, 124B (two high-level operating systems in the case illustrated in Figure 1) of secure element E and the components 111 of element E.
  • the low-level operating systems comprise software driving components 111.
  • a low-level operating system 113 is formed of an execution code (or executable code) and of execution data.
  • the execution code contains instructions enabling to execute functions of the program. By definition, the instructions are invariable for a given program, except for an update of the program, which then modifies the instructions.
  • the execution data are used by the execution code to contextualize the execution and perform the desired function.
  • the execution data may be distributed in two categories. So-called “temporary” execution data and so- called “permanent" or "fixed” execution data.
  • the execution code contains instructions of verification of the PIN code while the permanent execution data contain the reference PIN code and the number of remaining tests and the temporary execution data contain the PIN code submitted to the verification.
  • the low-level system manages the memory components of the element, that is, the physical memories, volatile 12 ( Figure 1) and non-volatile (13 (rewritable or not) .
  • High-level operating systems 124A and 124B use virtual images of the memories available for the management of the execution codes and of the execution data. Due to this technique, high-level operating systems do not have a direct access to the management of physical memories, be they volatile or non-volatile. In other words, in the described embodiments, high-level operating systems manage a virtual image of the memories where the volatile and nonvolatile memories are confounded. The management of the physical distribution in the volatile and non-volatile memories is ensured by the low-level operating system (s) .
  • Platform 110 has, according to the described embodiments, particularly the roles of;
  • HW hardware components
  • Low-level operating system 113 uses a memory management function (MMF) 115 to control or manage the access of the high-level operating systems to the physical memories by linking the virtual memories and the physical memories according to the needs and requests of high-level operating systems 124A and 124B . More particularly, low- level operating systems 113 , by using memory management function 115 (MMF) , implement the isolation of high-level operating systems 124A and 124B from one another and manage the access of high-level operating systems 124A, 124B to the di f ferent memories .
  • MMF memory management function
  • low-level operating systems 113 may manage data stored in the memories and more particularly manage the access to these data, especially in the case where a plurality of high-level operating systems are present in secure element E .
  • Low-level operating systems 113 may for example forbid the access to certain data to a high-level operating system .
  • Architecture 100 further comprises applications capable of being implemented by primary platform 110 .
  • Such applications are for example capable of processing control signals originating from communication interfaces , such as for example a bank transaction using a near- field communication device .
  • Each of these applications i s implemented by means of fixed data forming the application, for example , instructions , code lines , or permanent data such as user data such as an identi bomb, and o f temporary data, execution data, or variable data such as data stacks , temporary cipher keys .
  • the execution data of an application are data used by the application only during its execution and which are not kept once the execution of the application has ended .
  • an application implements one or a plurality of tasks, each task for example being a succession of instructions. The implementation of a task generates execution data. Certain execution data may be used by different tasks of the application while other may only be used by a single task. It is considered that an application may only implement a single task at a time.
  • main task the task which is being executed by the application
  • secondary tasks the other tasks of the application which are not being executed.
  • the execution tasks are for example tasks which have not been implemented yet and which have not enabled to generate execution data, or tasks which have already been implemented but which have been, for example, interrupted (and paused) , and which thus have already enabled to generate execution data.
  • execution data relative to the main task can be distinguished from execution data relative to the secondary tasks.
  • the applications may be of different types, for example, a SIM (Subscriber Identity Module) application, a payment application, an application enabling to validate a public transport ticket, etc.
  • SIM Subscriber Identity Module
  • payment application an application enabling to validate a public transport ticket, etc.
  • an application 121 is capable of being directly implemented by primary platform 110.
  • Application 121 is for example an application enabling to perform payments by communicating with a near-field communication (NFC) device.
  • NFC near-field communication
  • an application 122 is capable of sending control signals to primary platform 110 via one of the high-level operating systems, for example, operating system 124B.
  • This high-level operating system may for example be one of the operating systems of secure element E exchanging control signals with primary platform 110 .
  • the high-level operating system as well as all the applications attached thereto are an application adapted to being implemented by primary platform 110 .
  • an application 123 is adapted to sending commands to primary platform 110 via an execution environment 125 (ENV) and one of the high-level operating systems , for example operating system 124A.
  • the operating environment is for example of Java or JavaCard type .
  • the operating system, as well as all the applications which are attached thereto are an application capable of being implemented by primary platform 110 .
  • the components 111 of secure element E more particularly comprise at least one non-volatile memory and at least one volatile memory .
  • the non-volatile memory is generally used to store fixed data and the execution code of one or a plurality of applications .
  • the volatile memory is generally used to store the execution data of one or a plurality of applications .
  • Thi s function is , as previously indicated, implemented by a memory management function 115 MME or memory management unit (MMU) .
  • Function 115 enables to link the "virtual" memory known by the application and the physical memories (volatiles and non-volatile ) .
  • the high-level operating systems ( 124A and 124B ) do not "directly" have access to the physical memory management .
  • the management of this virtual image or virtual memory is divided to enable the high-level operating systems ( 124A and 124B ) to manage the execution codes , as well as the fixed data or the execution data according to their nature .
  • the high-level operating systems are indeed those which manage their data and not the low- level operating systems .
  • the low-level operating systems and the memory management function achieve the correspondence between the virtual execution data ( the virtual memory) and their storage in the physical memory .
  • At least one area or portion of the non-volatile memory is used as a working memory .
  • this area of the non-volatile memory operates , as seen from the high-level applications , as a volatile memory, to store temporary data used by the applications during their operation .
  • the non-volatile memory may be internal or external to secure element E ( internal or external to circuit HW) . According to whether the non-volatile memory ( its area used as a working memory by the high-level operating systems ) is internal or external to the secure element , the management of this memory di f fers during the execution of a high-level operating system .
  • the high-level operating system may be directly executed from the memory where the operating system is located ( is loaded) . It is spoken of an " in place” execution (XIP ) .
  • XIP " in place" execution
  • the low-level operating systems then enable to manage the execution of a plurality of high- level operating systems.
  • the instruction portion (the execution code) of the application remains in the nonvolatile memory; the execution data (permanent and temporary) may then be displaced into the working memory (non-volatile memory) .
  • the management of the non-volatile memory implies a displacement of all or part of the high-level operating system into a volatile memory internal to the secure element.
  • the low-level operating system may authorize or not the management of the execution of a plurality of high-level operating systems in its internal memory .
  • an application may be in at least three different states:
  • an active or state of execution (running) by primary platform 110 an active or state of execution (running) by primary platform 110; a standby state, that is, its execution is interrupted but it can be resumed at any time; and an inactive or deactivated state, that is, its execution cannot be restarted without one or a plurality of previous operations.
  • all or part of the data relative to its main task are stored in the volatile memory of the circuit and are used for the implementation of the application .
  • the data relative to secondary tasks of the application may be stored in the volatile memory or in the working memory (non-volatile ) .
  • certain execution data (permanent or temporary) relative to the main tas k may be located in the working memory (non-volatile ) and be loaded into the volatile memory when the main task requires it .
  • each application only has access to its own data and does not have access to the data of the other application ( s ) .
  • the applications are not aware of the presence of data of other applications in the volatile memory .
  • Figures 3 to 6 illustrate di f ferent implementations of applications of secure element E , and more particularly the use of the volatile and non-volatile physical (working) memories .
  • Figure 3 comprises three views ( a ) , (b ) , and ( c ) , each illustrating a phase of an implementation of a method of execution of applications App20 and App21 of the secure element E described in relation with Figures 1 and 2 . These three views more particularly illustrate the use of working memory WM using the non-volatile memory ( Physical NVM) , considered by the applications as a volatile memory, and of the real volatile memory RAM ( Phys ical RAM) , of secure element E during the execution of applications App20 and App21 .
  • Applications App20 and App21 may be located in a same high-level operating system or in two different high-level operating systems .
  • Application App20 is also deactivated but has never been started. It thus has not generated execution data yet.
  • application App20 is started by secure element E. More particularly, application App20 is started by low-level operating system 113. Application App20 is then running. Execution data, relative to the main task of application App20, are downloaded or loaded into volatile memory RAM.
  • application App20 stores its execution data in volatile memory RAM.
  • application App21 keeps on running, and modifies in volatile memory RAM its execution data relative to its main task and, possibly, to secondary tasks. Data are for this purpose transferred from non-volatile working memory WM to volatile memory RAM.
  • Figure 4 comprises three views (a) , (b) , and (c) , each illustrating applications App30 and App31 of the secure element E described in relation with Figures 1 and 2. These three views more particularly illustrate the use of nonvolatile working memory WM and of a volatile memory RAM of secure element E during the activation of applications App30 and App31.
  • Applications App30 and App31 may be located in a same high-level operating system or in two different high-level operating systems .
  • application App30 is a frequent-use application, or resident application, or implements a frequent-use task, or resident task.
  • the fact of considering an application as being "frequent" is decided, requested, and/or indicated by the high-level operating system which hosts the application.
  • the execution data relative to resident application App30 are stored in a reserved area PRAM30 of volatile memory RAM.
  • the area (or physical address range) PRAM30 of memory RAM is always available to store the execution data of application App30, and the execution data of one or of other applications cannot be stored therein.
  • application App30 is set to standby. Execution data relative to the main task of application App30 are stored in area PRAM30.
  • the main task of application App30 is for example a resident task.
  • Application App31 is then started by secure element E. Execution data, relative to the main task and, possibly, to secondary tasks, of application App31 are downloaded or loaded into an area PRAM31 of volatile memory RAM. Area PRAM31 is distinct from area PRAM30. Application App31 is then running.
  • application App31 stores its execution data in area PRAM31 of volatile memory RAM.
  • An advantage of this embodiment is that a frequent- use application, or resident application, is guaranteed to have space in physical volatile memory PRAM to store its execution data therein.
  • a frequent- use application, or resident application is guaranteed to have space in physical volatile memory PRAM to store its execution data therein.
  • the size of the resident volatile memory requested by a new resident application which should be activated would be greater than the size of physical volatile memory PRAM, its activation would be denied until memory PRAM is freed, or the available size of memory PRAM is sufficient, or the size of the so- called resident memory requested by the application to be activated is compatible with the available size of memory PRAM. This case may occur if a plurality of resident applications is activated.
  • both applications are running in a secure environment (both are executed by the secure element -
  • data may be copied into an external non-volatile memory for the application that are not executed, but the execution is always inside the secure element) .
  • application App30 which is considered as frequently used or resident benefits from an allocated or reserved area in volatile memory.
  • an application here App30
  • an application which is considered as a priority application, can claim the fact not to be unloaded from the physical volatile memory and that its execution data ( or part of them) stay in this physical volatile memory, even in standby and when another application (here App 31 ) needs to be executed .
  • the management by the low-level operating system, of the allocation of a dedicated portion of the volatile memory to a given application is configured based on a request sent by this given application at first loading ( or in its mapping definition or its memory image ) .
  • This information related to this App30 may be unloaded from this physical volatile memory only i f the application is deactivated ( or deleted) .
  • An advantage is to avoid downloading the execution data of the priority application from the volatile memory to the non-volatile memory, which allows a fast activation of the priority application, while allowing another application to use the rest of the volatile memory .
  • Figure 5 comprises three views ( a ) , (b ) , and ( c ) , each illustrating a phase of an implementation of a method of execution of applications App40 and App41 of the secure element E described in relation with Figures 1 and 2 . These three views more particularly illustrate the use of the non-volatile working memory WM and of the volatile memory RAM of secure element E during the activation o f applications App40 and App41 .
  • App40 and App41 might be located in a same high-level operating system or in two di f ferent high-level operating systems .
  • a first phase application App40 requests being run by secure element E, and then becomes "running". Starting and operation execution data relative to application App40 are transferred, downloaded, or loaded into an area PRAM40 of volatile memory RAM, from area WM40 of non-volatile working memory WM, when the main task of application App40 needs it.
  • application App41 requests in turn being run by secure element E.
  • the execution data relative to the main task of application App41 are transferred, downloaded, or loaded into an area PRAM41 of volatile memory RAM, from area WM41 of nonvolatile working memory WM.
  • the data are stored after the execution data relative to application App40 in volatile memory RAM.
  • Application App41 then is running, and application App40 is then at standby.
  • Figure 6 comprises three views (a) , (b) , and (c) , each illustrating a phase of an implementation mode of a method of execution of applications App50 and App51 of the secure element E described in relation with Figure 1.
  • the three views more particularly illustrate the use of the nonvolatile working memory WM and of the volatile memory RAM of secure element E during the activation of applications App50 and App51.
  • App50 and App51 might be located in a same high-level operating system or in two different high-level operating systems .
  • application App50 is a frequent-use application, called resident application hereafter, also described in relation with Figure 4.
  • resident application App50 requests being run by secure element E .
  • Execution, starting, and operating data relative to application App50 are trans ferred, downloaded, or loaded into a reserved area PRAM50 of volatile memory RAM, from area WM50 of nonvolatile working memory WM .
  • Area PRAM50 is an area of volatile memory RAM always available to store the execution data of application App50 , and which cannot be used to store execution data of other applications .
  • Application App50 is then running .
  • application App51 requests being executed by secure element E .
  • Execution, starting, and operating data relative application App51 are trans ferred, downloaded, or loaded into an area PRAM51 of volatile memory RAM, from area WM51 of non-volatile working memory WM . These data are stored after the execution data relative to application App50 in volatile memory RAM .
  • Application App51 is then running, and application App50 is then at standby .
  • the embodiment of figure 6 provide a dedicated area of the physical volatile memory where to keep the execution data of a priority ( resident or frequently used) application .
  • the low-level operating system forbids the unloading of the priority application from its allocated area in the physical volatile memory .
  • both applications are running in a secure environment ( are executed by the secure element ) .
  • a resident application has a portion of the execution data in a dedicated volatile memory ( resident ) and another portion in the volatile memory shared with other applications . This shared portion may then be trans ferred into the working memory (non-volatile ) when the execution of the task of the concerned application is interrupted or needs more space in the volatile memory .
  • An advantage of the described embodiments is that all the applications are loaded into a memory seen, by the high-level operating systems of these applications , as a volatile memory . This allows a fast restarting of each application . Furthermore , when an application claims not to be unloaded from its dedicated area of the physical volatile memory, this further speeds up its restarting .
  • Another advantage of the described embodiments is that a frequent-use application is guaranteed to have space in the voltage memory RAM of the circuit to store its operation execution data therein .
  • the low-level operating systems 113 described in relation with Figure 2 manage the allocation of the memory areas and their filling with the execution data of the applications ( resident or not ) . More particularly, the low-level operating systems are capable of detecting whether an application is a resident application or not .
  • a secure element E may comprise a plurality of resident applications .
  • Low-level operating systems 113 are further capable of denying the installation of an application as a resident application, for example , i f secure element E comprises too many resident applications , particularly when too large a portion, for example , more than half , of volatile memory RAM is reserved to execution data of resident applications .
  • low-level operating systems 113 are capable of configuring the si zes of the portions of volatile memory RAM reserved for execution data of resident applications .
  • low level operating systems 113 are capable of configuring the si ze of a portion of the volatile memory RAM reserved for execution data of a resident application, to make it equal to zero .
  • the secure element comprises a plurality of resident applications , then the execution data of these resident applications are all stored in a same " resident" portion of volatile memory RAM . When this " resident" portion is full , the execution data relative to secondary tasks of the resident applications are displaced towards non-volatile working memory WM .
  • the " resident" portion of volatile memory RAM which is reserved to the execution data of the resident applications , may be used to store execution data of other applications of the secure element .
  • the si ze of the " resident" portion of volatile memory RAM may be adj usted according to the needs of the resident applications .
  • i f a resident application which requires being executed, does not have enough space to load its data into the " resident" portion of volatile memory RAM, its execution is suspended and it remains in the deactivated state .
  • the concerned application may only be executed when there is enough space in the " resident" portion of volatile memory RAM .
  • space may be freed by deactivating other resident applications .
  • the si ze of the " resident" portion of volatile memory PRAM may be increased .
  • the execution data of an application which is inactive or at standby which are stored in working memory WM are only trans ferred into the volatile memory, during a new activation of this application, as and when needed by the application .
  • This action is performed by the low-level operating system and is transparent for the application and the corresponding high-level operating system . Indeed, data displacements between the volatile memory and the non-volatile working memory and conversely are not seen by the high-level operating systems .
  • the low-level operating system previously displaces , towards the working memory, execution data which are considered as the oldest ( those which have been used les s recently) or the less often used .
  • An advantage of the disclosed embodiments is that several applications stay present in the volatile memory even when non active . This allows fast toggling from one application of another .
  • Another advantage of the disclosed embodiments is that the allocation of the volatile memory is "dynamic" , i . e . , used from an application or another . In other words , execution data of an appl ication are trans ferred into the non-volatile memory only when space in the volatile memory is needed by a second application .
  • an application might be divided into one or a plurality of resident sub-applications and one or a plurality of non-resident sub-applications .
  • the resident application might be a portion of another application .

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Techniques For Improving Reliability Of Storages (AREA)

Abstract

La présente description concerne un système électronique intégré ou un procédé mis en œuvre par un tel système comprenant : au moins une mémoire rémanente (RAM); au moins un système d'exploitation à bas niveau gérant l'attribution de zones de la mémoire rémanente à une pluralité de systèmes d'exploitation à haut niveau, comprenant chacun une ou plusieurs applications (App20, App21), des données d'exécution d'une ou de plusieurs tâches de ladite première application (App20) sont partiellement transférées par le système d'exploitation à bas niveau depuis ladite mémoire rémanente vers une mémoire non rémanente (WM) lorsque l'exécution de ladite tâche de la première application est interrompue par l'exécution d'au moins une tâche d'une seconde application (App21).
PCT/EP2021/075778 2020-09-25 2021-09-20 Gestion de mémoire pour des applications d'un élément sécurisé intégré à des systèmes d'exploitation multiples WO2022063720A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202180066011.8A CN116209982A (zh) 2020-09-25 2021-09-20 用于多操作系统嵌入式安全元件的应用程序的存储器管理
EP21770040.0A EP4217861A1 (fr) 2020-09-25 2021-09-20 Gestion de mémoire pour des applications d'un élément sécurisé intégré à des systèmes d'exploitation multiples

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
FRFR2009752 2020-09-25
FR2009751A FR3114670A1 (fr) 2020-09-25 2020-09-25 Elément sécurisé embarqué
FR2009752A FR3114671A1 (fr) 2020-09-25 2020-09-25 Elément sécurisé embarqué
FRFR2009751 2020-09-25

Publications (1)

Publication Number Publication Date
WO2022063720A1 true WO2022063720A1 (fr) 2022-03-31

Family

ID=77750308

Family Applications (2)

Application Number Title Priority Date Filing Date
PCT/EP2021/075780 WO2022063721A1 (fr) 2020-09-25 2021-09-20 Réservation de mémoire pour des applications fréquemment utilisées dans un élément sécurisé intégré
PCT/EP2021/075778 WO2022063720A1 (fr) 2020-09-25 2021-09-20 Gestion de mémoire pour des applications d'un élément sécurisé intégré à des systèmes d'exploitation multiples

Family Applications Before (1)

Application Number Title Priority Date Filing Date
PCT/EP2021/075780 WO2022063721A1 (fr) 2020-09-25 2021-09-20 Réservation de mémoire pour des applications fréquemment utilisées dans un élément sécurisé intégré

Country Status (3)

Country Link
EP (2) EP4217864A1 (fr)
CN (2) CN116235147A (fr)
WO (2) WO2022063721A1 (fr)

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2009751A1 (fr) 1968-05-31 1970-02-06 Adwest Eng Ltd
FR2009752A1 (fr) 1968-05-31 1970-02-06 Kheinstahl Union Ag
EP1524597A1 (fr) 2003-10-14 2005-04-20 Axalto S.A. Méthode de gestion de fils d'exécution dans un système limité en mémoire
US20060133362A1 (en) * 2004-12-17 2006-06-22 Stein Richard E Fast initialization of medical device system having multiple operating systems
US20120047313A1 (en) * 2010-08-19 2012-02-23 Microsoft Corporation Hierarchical memory management in virtualized systems for non-volatile memory models
US20130297924A1 (en) * 2012-04-03 2013-11-07 Insyde Software Method of running multiple operating systems on an x86-based computer
US20150113257A1 (en) 2013-10-23 2015-04-23 Insyde Software Corp. System and method for dual os memory switching
US20180113817A1 (en) 2015-06-15 2018-04-26 Intel Corporation Virtualization-based platform protection technology
US20180165008A1 (en) 2016-12-13 2018-06-14 International Business Machines Corporation Memory transaction prioritization

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2009751A1 (fr) 1968-05-31 1970-02-06 Adwest Eng Ltd
FR2009752A1 (fr) 1968-05-31 1970-02-06 Kheinstahl Union Ag
EP1524597A1 (fr) 2003-10-14 2005-04-20 Axalto S.A. Méthode de gestion de fils d'exécution dans un système limité en mémoire
US20060133362A1 (en) * 2004-12-17 2006-06-22 Stein Richard E Fast initialization of medical device system having multiple operating systems
US20120047313A1 (en) * 2010-08-19 2012-02-23 Microsoft Corporation Hierarchical memory management in virtualized systems for non-volatile memory models
US20130297924A1 (en) * 2012-04-03 2013-11-07 Insyde Software Method of running multiple operating systems on an x86-based computer
US20150113257A1 (en) 2013-10-23 2015-04-23 Insyde Software Corp. System and method for dual os memory switching
US20180113817A1 (en) 2015-06-15 2018-04-26 Intel Corporation Virtualization-based platform protection technology
US20180165008A1 (en) 2016-12-13 2018-06-14 International Business Machines Corporation Memory transaction prioritization

Also Published As

Publication number Publication date
EP4217861A1 (fr) 2023-08-02
CN116235147A (zh) 2023-06-06
CN116209982A (zh) 2023-06-02
EP4217864A1 (fr) 2023-08-02
WO2022063721A1 (fr) 2022-03-31

Similar Documents

Publication Publication Date Title
CN101196974B (zh) 用于软件应用程序的自动配置的方法和系统
US7882198B2 (en) Shared JAVA JAR files
US20010027511A1 (en) 1-chop microcomputer and IC card using same
KR102277238B1 (ko) 업데이트가능한 집적 회로 무선장치
US11847225B2 (en) Blocking access to firmware by units of system on chip
US8434127B2 (en) Access control system, access control method, electronic device and control program
US20230342149A1 (en) Embedded system
JP6913621B2 (ja) 自動車用電子制御装置
US11720358B2 (en) Embedded system
JP6326047B2 (ja) 集積回路型無線
US20220004509A1 (en) Embedded secure element
WO2022063720A1 (fr) Gestion de mémoire pour des applications d'un élément sécurisé intégré à des systèmes d'exploitation multiples
US20220245253A1 (en) Secure element and method for starting an application
KR20160102040A (ko) 집적 회로 무선장치
JP5057829B2 (ja) 携帯可能電子装置およびｉｃカード
CN116302298A (zh) 容器运行方法、装置、电子设备和存储介质
EP3320437B1 (fr) Carte à circuit intégré conçue pour transférer des premières données à partir d'une première application utilisables par une seconde application
US11039318B2 (en) Multi-configuration secure element and associated method

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21770040

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2021770040

Country of ref document: EP

Effective date: 20230425