WO2009156615A1 - Procede et dispositif de mise a jour d'application informatique - Google Patents

Procede et dispositif de mise a jour d'application informatique Download PDF

Info

Publication number
WO2009156615A1
WO2009156615A1 PCT/FR2009/000637 FR2009000637W WO2009156615A1 WO 2009156615 A1 WO2009156615 A1 WO 2009156615A1 FR 2009000637 W FR2009000637 W FR 2009000637W WO 2009156615 A1 WO2009156615 A1 WO 2009156615A1
Authority
WO
WIPO (PCT)
Prior art keywords
software
partition
version
update
during
Prior art date
Application number
PCT/FR2009/000637
Other languages
English (en)
Inventor
Alain Molinie
Eric Lavigne
Vincent Leclaire
Original Assignee
Awox
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Awox filed Critical Awox
Priority to US12/995,746 priority Critical patent/US20110145807A1/en
Priority to EP09769456A priority patent/EP2310941A1/fr
Publication of WO2009156615A1 publication Critical patent/WO2009156615A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates

Definitions

  • the present invention relates to a method and a device for updating a computer application. It applies, in particular, to the program update in embedded systems.
  • the device may become unusable
  • a user or hacker can install software that is not necessarily licensed, or certified, by the device provider for use on the device .
  • bootloader and boot parameters including optionally a boot logo
  • Levels 2 and 3 are generally referred to as "software” below.
  • Each of these levels uses different procedures and different tools and is itself possibly subject to several sub-levels, especially in the case of the bootloader. Because of this complexity, many devices support only the update of a subset of these levels, usually the last, or alternatively uses a very primitive form of update that directly replaces the total contents of the memory. nonvolatile.
  • DRM digital rights management
  • the present invention aims to remedy these disadvantages.
  • the present invention aims at a method of updating a computer application, characterized in that it comprises:
  • the launch of the new version is easy and, in case of failure of the update or choice of the user for that, the old version can be used again without having to reload for a external source said old version of the software since it is present in the first partition.
  • software in a partition works while other partitions contain old proprietary software, are reusable or have free space that can be used for new software or for new versions of a software already present.
  • new software is written to an empty or reusable partition and the system is left running for a possible rollback to the previous version. Indeed, if the user does not wish to continue using the updated system, for whatever reason, he may choose to switch back to the previously active proprietary software or any other proprietary software kept in the system.
  • the environment variables of the bootloader are kept in the software partition and not in a bootloader partition, so that this bootloader partition does not need to be changed during a boot. proprietary software day.
  • a software partition allocation card is also created, listing the software versions present, their status, and indicating which version of the software is active.
  • the method that is the subject of the present invention comprises a step of determining whether the new version of the software works and, if so, a step of assigning to the new version of a indication that it is active, and assignment to the previous version of an indication that it is inactive.
  • said indications are stored in a software partition map.
  • this partition scheme is such that, at most, only the software partition map and one of the proprietary software partitions are changed during software update.
  • At least part of the partition assignment map is kept outside the non-volatile memory retaining the proprietary software, for example in a separate non-volatile memory.
  • This operating mode is said to be “static” and is more secure than the so-called “dynamic” operating mode, in which the partition assignment card is modified during an update and is kept in the same memory as the different versions of the proprietary software.
  • the update and partition scheme thus supports the maintenance of all or part of the user parameters and / or other partitions of interest, between the updates, without compromising the back-up capabilities since said parameters have been modified. copied before modification and are therefore preserved for the previous version.
  • a free or reusable zone of sufficient size is sought in the partitions and, if at least one of them is found, the step of performing a free or reusable zone is performed. writing the new version different from the current version of the software, boot loader environment variables of said new version of the software, and at least one kernel image and a root file system image.
  • the present invention aims at a device for updating a computer application, characterized in that it comprises:
  • writing means adapted to write, in a first partition, a first version of a software, boot loader environment variables of said first version of the software, and at least one image of operating system kernel and, during the update of said software, to write, in a second partition different from the first partition, a new version different from the current version of the software, loader environment variables. booting said new version of the software, and at least one OS kernel image.
  • the present invention aims a computer program loadable in a computer system, said program containing instructions for the implementation of the method object of the present invention, as briefly described above.
  • the present invention aims at a support for information readable by a computer or a microprocessor, removable or not, retaining instructions of a computer program, characterized in that it allows the implementation of the method object of the present invention as succinctly set forth above.
  • this program and this information medium are similar to those of the updating method that is the subject of the present invention, as briefly described above, they are not recalled. right here.
  • FIG. 1A represents, in the form of a logic diagram, the steps implemented during a normal launch of a standard on-board system, according to the state of the art, without a recovery or maintenance procedure,
  • FIG. 1B represents, in the form of a logic diagram, steps implemented during a launch of an on-board system according to the state of the art supporting a simple mode of maintenance
  • FIG. 1C represents, in the form of a logic diagram, steps implemented during a launch in a particular embodiment of the method that is the subject of the present invention
  • FIGS. 2A and 2B represent, in the form of logic diagrams, substeps implemented during software loading in a particular embodiment of the method that is the subject of the present invention
  • FIG. 3 represents, in logic diagram form, the steps implemented in a maintenance mode in a particular embodiment of the method that is the subject of the present invention
  • FIG. 4 represents, in logic diagram form, the steps implemented during a software update in a particular embodiment of the method that is the subject of the present invention
  • FIG. 5 schematically represents a partition organization implemented in particular embodiments of the present invention
  • FIG. 6 schematically represents a partition assignment card format implemented in particular embodiments of the present invention
  • FIG. 7 schematically represents information concerning each of the partitions of a memory, information implemented in particular embodiments of the present invention
  • FIG. 8 represents, schematically, a software format implemented in particular embodiments of the present invention.
  • FIG. 9 schematically represents a list of information on the subparts implemented in particular embodiments of the present invention.
  • FIG. 10 schematically represents information on a sub-part implemented in particular embodiments of the present invention.
  • FIG. 11 represents, schematically, an example of configurations of partitions in non-secure dynamic mode, before and after the update
  • FIG. 12 represents, schematically, an example of configurations of partitions in static secure mode with re-author (re-encryption), before and after the update,
  • FIG. 13 represents, schematically, an example of partition configurations in restoration mode alone, before and after the update and
  • FIG. 14 shows, schematically, an example of partition configurations in dynamic switching mode, before and after the update.
  • update indate
  • upgrade in English "upgrade”
  • the secure update concerns the various software layers of an embedded system to improve reliability, security and to reduce the risks of rendering the system unusable during the update.
  • several new features are implemented to obtain, compared to known updates, a more flexible, safer and more reliable update of embedded system software.
  • the storage space of the proprietary software is divided into several partitions.
  • Each partition contains a version of the software.
  • each version of the software is broken down into several subparts, including:
  • boot loader environment variables
  • kernel image (abbreviated as “kernel” or “kernel)
  • root file system image a root file system image
  • optional images of generic data one or more optional images of generic data.
  • each of these sub-parts is associated with a set of flags and parameters for supporting the advanced functions of the present invention.
  • a boot loader is a software program for launching one or more operating systems (known as "multi-boot”), that is, it allows use different systems at different times on the same machine.
  • the partition scheme supports two partition assignment modes:
  • the partition scheme can implement different proprietary software with different sizes.
  • the partition scheme is designed so that only the assignment map, in the case where the dynamic mode is used, and one of the proprietary software partitions are modified during the proprietary software update.
  • the static partition assignment mode makes it possible to keep in memory the allocation assignment status outside the non-volatile memory holding the proprietary software, for example in a flash memory of a companion microcontroller.
  • the update and partition scheme supports encryption and / or signing and re-authoring of all or part of the software update.
  • the update and partition scheme supports the maintenance of all or part of the user settings and / or other partitions of interest, between updates, with or without update of format and without compromising the ability to roll back.
  • FIG. 1A represents steps for a normal launch of a standard on-board system, of the state of the art, without a recovery or maintenance procedure. During this launch, a step 105 of loading the boot loader is performed, a step 110 for loading the kernel of the operating system ("kernel”) and a step 115 for loading the kernel. application.
  • kernel the kernel of the operating system
  • FIG. 1B represents steps for launching a state-of-the-art embedded system supporting a simple maintenance mode. It includes steps 105 to 115 described with reference to Figure 1. However, between steps 105 and 110, there is added a step 107 during which it is determined whether the launch is in normal mode. If yes, we go to step 110. Otherwise, we go into maintenance mode, during a step 120.
  • FIG. 1C represents steps for a launch according to a particular embodiment of the method that is the subject of the present invention. During this launch, it performs a step 125 of loading, by the processor, the bootloader, possibly encrypted and signed.
  • a partition map is loaded and it is deciphered if it is encrypted.
  • step 135 If the result of step 135 is negative, it goes to the maintenance mode described with reference to FIG. 3. If the result of step 135 is positive, during a step 140, the search is made in the map of partition, the standard active proprietary software. During a step 145, it is determined whether this active proprietary software was found. Otherwise, we go to maintenance mode. If yes, during a step 150, it is determined whether the previous launch was successful. Otherwise, we go to maintenance mode. If yes, during a step 155, it is determined whether re-authoring should be performed.
  • the proprietary software is loaded, as shown in FIG. 2. If yes, during a step 160, the software is loaded, re-authored and rewritten the proprietary software after re-encryption and erase the corresponding flag.
  • step 205 in order to load the proprietary software, during a step 205, the previous successful launch flag of this proprietary software is "failed". Then, during a step 210, the next sub-part in the proprietary software is taken as the current sub-part, the repetition of step 210, starting from step 255, making it possible to process each sub-part parts of the software.
  • step 215 it is determined whether the current subpart must be loaded in the random access memory according to the value of the corresponding flag. If no, go to step 225. If yes, during a step 220, the sub-part is loaded in the random access memory and then goes to step 225.
  • step 225 it is determined whether the subpart is signed. If not, proceed to step 235. If the result of step 225 is positive, during a step 230, it is determined whether the signature is verified. If not, we go into maintenance mode. If the result of step 230 is positive, go to step 235, during which it is determined whether the subpart is encrypted. If not, go to step 245. If the result of step 235 is positive, in step 240, an attempt is made to decipher the sub-part and determining whether the decryption is successful. If not, we go into maintenance mode. If yes, during step 245, it is determined whether the subpart is a logo. If no, we proceed to step 255.
  • step 250 we display the logo and go to step 255 during which it is determined if all the sub-parts of the proprietary software have have been treated. If no, return to step 210. If yes, in step 260, it is determined whether all required subparts have been found. For example, for a Linux-based system, this is at least one kernel subpart and a subpart with the root file system. If you are in a secure mode, the kernel must be encrypted and the root file system must be signed.
  • step 260 If the result of step 260 is negative, it goes to maintenance mode. If the result of step 260 is positive, during a step 265, the proprietary software is launched. For example, for Linux, the kernel is loaded into RAM, and the root file system and other sub-list information are passed as parameters. Then, during a step 270, the proprietary software sets the previous launch flag, for this proprietary software, to "successful".
  • step 305 the previous standard proprietary software and restoration software are searched in the partition card. Then, during a step 310, it is determined if more software has been found in step 305. If no, go to step 320. If yes, in a step 315 , we display the list of found software and we ask the user to choose one. Once this choice is made by the user, we go to step 320, during which it is determined whether to perform a re-authoring of the software, according to the value of the associated flag. If no, we go to a step 330. If yes, during a step 325, we proceed to re-authoring and re-writes the proprietary software and we erase the associated flag. Then, we go to step 330 during which we load the proprietary software.
  • Figure 4 shows the update of proprietary software.
  • step 405 current proprietary software downloads proprietary update software.
  • step 410 it seeks, in the partition map, a free area or, alternatively, a reusable area of sufficient size.
  • step 415 it is determined whether such a zone has been found. If yes, proceed to step 425. If no, during a step 420, a message is displayed asking the user whether he agrees to make it impossible to return to the current proprietary software. If the user's response is negative, the process ends. If the user's response is positive, the partition of the current software is selected to perform the following steps.
  • step 425 the next sub-part of the downloaded proprietary software is considered, this next sub-part being the first sub-part during the first iteration of step 425. Then, during a step 430, it is determined whether this subpart must be obtained by copying from the previous version during the update, according to the value of the associated flag. If not, proceed to step 435 which consists in writing said subpart in the non-volatile memory and go to step 450. If yes, during a step 440, it is determined whether a subset part has the same name in the current proprietary software. If no, go to step 450. If yes, in step 445, copy the subpart having the same name in the current proprietary software to form a part of the proprietary software updated.
  • step 450 it is determined whether all the images of the updated proprietary software have been processed. If no, return to step 425. If yes, proceed to step 455, where the new proprietary software is declared active and the old proprietary software (if any) as reusable. Then the process ends.
  • the organization of partitions of a memory implemented by the present invention can take the form of a partition, 505 reserved for the "bootloader", of a partition 510 reserved for a card assigning software partitions ("software partition map”) and a plurality of partitions 515 (only three partitions are shown in FIG. 5) for the proprietary software ("firmware") 1 to n.
  • the partitions 505 and 510 may have a fixed size if this proves necessary or simplifies the implementation.
  • the partitions 515 are, preferably, of variable sizes according to their content.
  • the format of the card partition 510 may take the form of an optional card header 605 to check the conformance of the format.
  • the map partition format 510 includes information 610 about each of the partitions represented in the memory, described with reference to Fig. 7.
  • the partition format of card 510 has an end flag 615 which means the end of the list of partitions.
  • the information 610 relating to each proprietary software, in the partition card 510 comprises the following fields:
  • Offset 705 which represents the starting position of the partition (Firmware offset) determined from the beginning of the non-volatile memory.
  • sub-type which may take, in the case of a "proprietary software” type, the "standard”, “maintenance”, “development” and “reserved” values,
  • the proprietary software format includes:
  • the Subpart Information List has 905 information on each of the subparts and an indicator 910 which means the end of the list.
  • the information 905 on a sub-part comprises the following fields:
  • type 1020 which represents the type of subpart, among the values "Logo”, “kernel”, “root file system” (“RootFilesystem”), “generic file system” ( “GenericFilesystem”),
  • file system type 1025 which specifies the format of the file system used for that subpart (eg "CRAMFS”, “Ext3” and “Yaffs2", registered trademarks),
  • RAM for example: operating system kernel
  • Compression 1035 which indicates the type of compression (ex: “none”, “gzip”, “” Izo ", registered trademarks) and
  • the bootloader partition contains at least one copy of the bootloader.
  • this bootloader can be subdivided into different phases and sub-partitions.
  • some integrated circuits of the brand "Texas Instruments” (registered trademark) starts with a "UBL” of less than 15 kilobytes which, in turn, launches a "UBOOT”.
  • the present invention supports these situations by grouping the different steps of loading the bootloader within a single "generic" step, the implementation taking care of the specific aspects of these situations.
  • the environment variables of the bootloader are kept in the proprietary software partition and not in the bootloader partition, so that the bootloader partition does not need to be modified during an update. proprietary software.
  • bootloader or part of bootloader, for example to allow the update of the bootloader, to compensate for the risk of a damaged block appears in the bootloader partition to compensate for the limitations of some systems that do not manage such blocks.
  • the preferred implementation uses a bootloader that supports damaged blocks.
  • the bootloader implementation can support either static mode only, for maximum security, or both static and dynamic mode, or only dynamic mode, as discussed below.
  • the bootloader is preferably encrypted or signed.
  • the software partition map partition partition contains the partition map.
  • the partition map In the case of static mode, the partition map can be saved only once in the first valid zone in the partition specified for this purpose and is never rewritten.
  • the partition map In the case of dynamic mode, the partition map is always written in two consecutive valid zones of the partition allocated to it. Thus, even if one of these zones becomes invalid, for example because of a damaged block when using a "NAND" memory, the partition map is still available and is rewritten in another valid zone . Since the number of updates is supposed to be limited, having a small number, for example five, of zones allocated for this purpose within the partition dedicated to the partition map should be sufficient.
  • the partition map contains information about the partitioning structure of proprietary software stored in non-volatile memory, and is updated during the proprietary software update, in dynamic mode.
  • the partition map must be re-encrypted after modification.
  • Some systems do not support re-encryption using hidden private keys to prevent hackers from using these keys to generate encrypted proprietary software. In this case, either we implement a separate key stored in encrypted form at the beginning of the partition map or in the bootloader, or we use the static mode.
  • each partition contains proprietary software.
  • Proprietary software contains the bootloader environment variables, the list of subheadings, and one or more subparts.
  • a sub-part can be a logo (optional), a kernel that is essential, or a root file system, or the application or the application parameters.
  • the system may include in one partition maintenance software that is never deleted. This maintenance software can be useful if a proprietary software update fails and no usable proprietary software can be found.
  • the maintenance software partition has a particular subtype and is not reusable for new versions of the software but may optionally be reused when updating the maintenance software.
  • the bootloader environment variables and the list of subpart information are preferentially encrypted.
  • Each subpart is encrypted or signed if its "encrypted / signed" flag means it.
  • the kernel and root filesystem sub-parts must be signed (in the case of medium security) or encrypted (case of high security). If this does not happen, the bootloader should not launch the kernel.
  • the other subparts can be either signed or unsigned, for example if they are user parameters.
  • the number of full proprietary software must be greater than or equal to two.
  • the update tool downloads the new proprietary update software (for example using one of the HTTP protocols, acronym for “hypertext transfer protocol” for hypertext transfer protocol, or MTP, acronym for “media transfer” protocol “for media transfer protocol, or local files) and verifies the version information and
  • the update tool reads the partition map and obtains the address of a free or reusable partition of appropriate size.
  • the update tool finds an index for a new proprietary software by taking the next index in the list of partitions. This partition is used to write the new software.
  • the update tool searches, in the list of information of subparts of the new proprietary software, any subpart having the flag "To be copied during the update",. If it finds such subparts, this tool looks for a subpart with the same name as the subpart in the current proprietary software and copies the contents of that subpart into the new software. It is noted that this step is essentially intended for the reuse of existing user parameters.
  • secure mode since the partition map is encrypted in static mode, and since decryption is often only available at system startup, a full partition map must be kept in RAM at launch time, which is the preferred embodiment, either a partition description to be used for the update is transferred to the kernel.
  • the update tool updates the partition map by adding information about the new proprietary software and setting its flag to "active".
  • the flags of the previously active proprietary software are also set to "reusable / inactive" and the date of last use is updated.
  • the update tool updates the indexes and states of the current proprietary software in the subsystem used for their storage.
  • the update tool restarts the system or, preferably, directly launches the new software.
  • FIG. 11 shows an example of configurations of partitions in non-secure dynamic mode, before and after the update.
  • the partition configuration Prior to the update, the partition configuration includes bootloader partition 1105, partition card partition 1110, software partition A, active, 1115, software partition B, free, 1120, and partition (optional) of the software C, recovery, 1125.
  • the partition configuration includes the bootloader partition 1105, the modified partition card partition 1130, the partition of the software A, become reusable, 1135, the partition of the software B , become active, 1140 and the (optional) software partition C, recovery, 1125.
  • FIG. 12 shows an example of partition configurations in static secure mode with re-author, during and after the update.
  • the partition configuration includes bootloader partition 1205, partition card partition 1210, software partition A, active, 1215, software partition B, reauthorer, 1220, and partition (optional). ) of the C software, recovery, 1225.
  • the partition configuration includes the bootloader partition 1205, the partition card partition, unchanged, 1210, the reusable and unmodified software partition A, 1235, the partition of the software B, active after reauthoring, 1240 and the partition (optional) of the software C, recovery, 1225.
  • nonvolatile memory is constrained, for example for cost reasons, and it is not possible to store at least two complete versions of the software to allow a rollback, then only a complete software and a software of maintenance, reduced managing critical cases, are stored, the new version of the software simply replace the current version ..
  • This embodiment of the present invention is called "maintenance only".
  • FIG. 13 shows an example of partition configurations in maintenance mode only, during and after the update.
  • the partition configuration includes the bootloader partition 1305, the partition card partition 1310, the software partition A being written (dirty), 1315, and the software partition B, maintenance, 1320.
  • the Partition configuration includes 1305 bootloader partition, 1310 partition card partition, C software partition, active, 1335, and maintenance software partition B, 1320.
  • FIG. 14 shows an example of partition configurations in dynamic switching mode from the back-to-front and maintenance-only mode after, before and after the update.
  • the partition configuration Prior to the update, the partition configuration includes the bootloader partition 1405, the partition card partition 1410, the software partition A, active, 1415, and the reusable software partition B, 1420.
  • the partition configuration includes the bootloader partition 1405, the modified partition card partition 1430, the active and modified software partition C, 1435, and the modified maintenance software partition D 1445.
  • version checking is performed on the server side.
  • the client sends the number of its current version along with other information, such as the device identifier, to the server, using the HTTP request "GET”.
  • the server If no software update is available, the server returns the "204 No Content” response. If an updated version is available, the server returns the answer "200 OK" and, in the body of the response, a description of the update (version, size and new features). This can be done using a form of free text, an XML form (acronym for "extensible markup language” for extensible markup language) or an ".ini” syntax, depending on the tool available to use this response. One can also specify a language in the request, using a header "Accept-Language", so that the server returns a description in this language.
  • the server finds the appropriate version that is likely to update the current version, which may not be the latest version, as discussed below. This procedure also helps in case the update pays off. In such a case, the server returns information indicating that the updated software can only be downloaded after payment. The user can contact the seller to make this payment.
  • a local update method such as USB (Universal Serial Bus), as explained below, can be used for the update.
  • USB Universal Serial Bus
  • version verification for local update, for example from USB / MMC-SD (acronym for "USB / multimedia card - Secure Digital" for secure digital multimedia USB card ). This is useful in the case of a downgrading, for example for a demonstration or an evaluation version.
  • the client In the case where the non-volatile memory is damaged, and the user presses a forced update button, the client is not always able to send the information indicating the current version to the server. In this case, only the device identification is sent to the server. Based on this identification, the server returns the latest free available version of the software for the identified device model.
  • the user accesses, for example, the "parameters” menu and then "update” to determine if an update is available.
  • an update update search is performed periodically and the user is notified by an alarm if an update is available.
  • the file of the proprietary update software can be downloaded using the HTTP "GET" command, for example:
  • the server If the request is valid, the server returns the update file. Otherwise, the server returns an error message, for example "404 file not found".
  • GUI graphical user interface
  • the boot loader or bootloader
  • the boot loader is able to detect at startup a key combination or a specific infrared code if the product is equipped with a remote control. This is to interrupt the normal launch and display a substitution dialog.
  • the dialogue is, for example, as follows:
  • This option is particularly useful in case the main system is damaged and the normal launch does not work.
  • This method can also be used as an installation instruction when the user has received paid software and stored it in local media, such as a USB stick. At launch, the user can select to launch the device in maintenance mode and navigate to select this local file.
  • the launch loader fails the successful launch flag of the proprietary software it is launching.
  • the software sets to "succeeded" this flag at the end of the sequence of launch.
  • the launch loader checks this flag when it looks for a proprietary software to launch and if this flag does not indicate a success, the loader displays a dialog box as described above and proposes by default the latest version of the software used owner that resulted in a successful launch.
  • the behavior of the launch loader depends on the available choices.
  • a dedicated file system is used to store them, such as WiFi connection settings and MAC address (acronym media access control for media access control), the user's language, and so on.
  • This file system is stored as a sub-part of the software to allow the parameter values to be saved.
  • this sub-part of the software uses the flag "To be copied during the update" in the information. If this flag indicates a copy to be made, the update tool searches the active proprietary software for an image of the same name and copies its contents into the new proprietary software in non-volatile memory.
  • the information necessary for re-authoring is kept outside the non-volatile memory retaining the proprietary software, for example in a flash memory of a companion microcontroller.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

Le procédé de mise à jour d'application informatique comporte : - une étape de création, dans une mémoire non volatile, de partitions pour logiciels, - une étape d'écriture, dans une première partition, d'une première version d'un logiciel, de variables d'environnement de chargeur d'amorçage de ladite première version du logiciel, et d'au moins une sous-partie de noyau de système d'exploitation et - lors de la mise à jour dudit logiciel, une étape d'écriture, dans une deuxième partition différente de la première partition, d'une nouvelle version différente de la version courante du logiciel, de variables d'environnement de chargeur d'amorçage de ladite nouvelle version du logiciel, et d'au moins une sous- partie de noyau de système d'exploitation. Dans des modes de réalisation, le procédé comporte une étape de détermination si la nouvelle version du logiciel fonctionne et, si oui, une étape d'affectation, à la nouvelle version, d'une indication qu'elle est active et d'affectation, à la précédente version, d'une indication qu'elle est inactive, lesdites indications étant conservées dans une partition de carte d'affectation de partitions.

Description

PROCEDE ET DISPOSITIF DE MISE A JOUR D'APPLICATION INFORMATIQUE
La présente invention concerne un procédé et un dispositif de mise à jour d'application informatique. Elle s'applique, en particulier, à la mise à jour de programme dans des systèmes embarqués.
La plupart des dispositifs embarqués supportent maintenant une mise à jour de leur logiciel propriétaire. Cependant, la procédure de mise à jour est généralement :
- dangereuse, notamment en cas d'arrêt d'alimentation électrique, le dispositif pouvant devenir inutilisable ;
- irréversible, c'est-à-dire qu'un utilisateur ne peut revenir en arrière à l'ancien logiciel s'il n'est pas satisfait du nouveau et
- non sécurisée, c'est-à-dire qu'un utilisateur ou un pirate informatique (« hacker ») peut installer un logiciel qui n'est pas nécessairement agréé, ou certifié, par le fournisseur du dispositif pour être utilisé sur le dispositif.
Les dispositifs embarqués les plus récents fonctionnent avec des systèmes d'exploitation évolués de type Linux (marque déposée) ou Windows CE (marque déposée) et ont un système de lancement (« booting process ») compliqué et comportant plusieurs étapes. Typiquement, ce lancement concerne plusieurs niveaux :
1) le chargeur d'amorçage (« bootloader ») et les paramètres d'amorçage y compris optionnellement un logo de démarrage ;
2) le noyau de système d'exploitation (« kernel ») et son système de fichier racine (« Root File System «) et
3) l'application et les paramètres applicatifs.
Les niveaux 2 et 3 sont, globalement, dénommés « logiciel » ci-après.
Chacun de ces niveaux utilise différentes procédures et différents outils et est éventuellement lui-même objet de plusieurs sous-niveaux, notamment dans le cas du bootloader. Du fait de cette complexité, beaucoup de dispositifs ne supportent que la mise à jour d'un sous-ensemble de ces niveaux, généralement le dernier, ou alternativement utilise une forme très primitive de mise à jour qui remplace directement le contenu total de la mémoire non volatile.
Cette technique crée des problèmes additionnels potentiels avec certains types de mémoire non volatile (par exemple, NAND flash, de plus en plus utilisée pour des raisons économiques), qui peuvent présenter des blocs perdus qui soit existent dès l'origine soit apparaissent au moment de l'exécution (« runtime ») notamment lors de la réécriture.
De plus, les mécanismes de gestion de droits numériques (« DRM » pour « Digital Rights Management ») embarqués dans les dispositifs mettant en œuvre des médias numériques requièrent des mécanismes de sécurités forts, tels que le chiffrement, la signature électronique et le « reauthoring » (ré- encryptage, ou re-chiffrement, destiné à lier de façon unique un logiciel à un matériel) des logiciels intégrant ces mécanismes. De fortes contraintes sont associées à ces protections et sont donc critiques à implémenter.
Cela est généralement non ou mal supporté par les dispositifs existants de mise à jour de logiciels embarqués et/ou conflictuel avec le besoin d'une mise à jour tout à la fois flexible et simple pour l'utilisateur.
La présente invention vise à remédier à ces inconvénients.
A cet effet, selon un premier aspect, la présente invention vise un procédé de mise à jour d'application informatique, caractérisé en ce qu'il comporte :
- une étape de création, dans une mémoire non volatile, de partitions pour logiciels,
- une étape d'écriture dans une première partition, d'une première version d'un logiciel, de variables d'environnement de chargeur d'amorçage de ladite première version du logiciel, et d'au moins une sous-partie de noyau de système d'exploitation et
- lors de la mise à jour dudit logiciel, une étape d'écriture dans une deuxième partition différente de la première partition, d'une nouvelle version différente de la version courante du logiciel, de variables d'environnement de chargeur d'amorçage de ladite nouvelle version du logiciel, et d'au moins une sous-partie de noyau de système d'exploitation.
Grâce à ces dispositions, le lancement de la nouvelle version est aisé et, en cas d'échec de la mise à jour ou de choix de l'utilisateur pour cela, l'ancienne version peut être utilisée de nouveau sans avoir à recharger depuis une source externe ladite ancienne version du logiciel puisqu'elle est présente dans la première partition. Ainsi, à tout moment, un logiciel présent dans une partition fonctionne alors que d'autres partitions contiennent des logiciels propriétaires anciens, sont réutilisables ou présentent de l'espace libre qui peut être utilisé pour de nouveaux logiciels ou pour de nouvelles version d'un logiciel déjà présent. Quand un utilisateur décide de mettre à jour le système, un nouveau logiciel est écrit dans une partition vide ou réutilisable et on laisse le système en fonctionnement intact pour un éventuel retour en arrière à la version précédente. En effet, si l'utilisateur ne souhaite pas continuer à utiliser le système mis à jour, quelle qu'en soit la raison, il peut choisir de commuter en arrière vers le logiciel propriétaire précédemment actif ou vers n'importe quel autre logiciel propriétaire conservé dans le système. On note aussi que les variables d'environnement du bootloader sont conservées dans la partition de logiciel et non dans une partition de bootloader, de telle manière que cette partition de bootloader n'ait pas besoin d'être modifiée au cours d'une mise à jour de logiciel propriétaire.
Selon des caractéristiques particulières, au cours de l'étape de création de partitions, on crée, en outre, une carte d'affectation des partitions de logiciel listant les versions du logiciel présentes, leur état, et indiquant quelle version du logiciel est active.
Selon des caractéristiques particulières, au cours d'au moins une étape d'écriture dans une partition, on écrit, outre des variables d'environnement de chargeur d'amorçage, une version de logiciel incluant un noyau, système de fichier racine. Selon des caractéristiques particulières, le procédé objet de la présente invention, tel que succinctement exposé ci-dessus, comporte une étape de détermination si la nouvelle version du logiciel fonctionne et, si oui, une étape d'affectation à la nouvelle version d'une indication qu'elle est active, et d'affectation à la précédente version d'une indication qu'elle est inactive.
Selon des caractéristiques particulières, lesdites indications sont conservées dans une carte d'affectation de partitions de logiciel.
Ainsi, c'est seulement une fois que la mise à jour logicielle est finalisée et réussie que la carte d'affectations de partitions de logiciel (« software partition map ») est mise à jour pour que le nouveau logiciel devienne actif et fonctionne en lieu et place de l'ancien. De plus, ce schéma de partitions est tel que, au plus, seulement la carte d'affectations de partitions de logiciel et une des partitions de logiciel propriétaire sont modifiées pendant la mise à jour d'un logiciel.
Selon des caractéristiques particulières, au moins une partie de la carte d'affectation de partition est conservée en dehors de la mémoire non-volatile conservant le logiciel propriétaire, par exemple dans une mémoire non-volatile séparée.
Ce mode de fonctionnement est dit « statique » et est plus sécurisé que le mode de fonctionnement dit « dynamique », dans lequel la carte d'affectation de partitions est modifiée lors d'une mise à jour et est conservé dans la même mémoire que les différentes versions du logiciel propriétaire.
Selon des caractéristiques particulières, lors de la mise à jour du logiciel, pour chaque sous- partie du logiciel de mise à jour, on détermine si cette sous-partie doit être copiée depuis la précédente version dudit logiciel et, si oui, on copie la sous-partie correspondante depuis la partition de l'ancienne version dans la partition de la nouvelle version.
Grâce à ces dispositions, on peut conserver des sous-parties du logiciel et, notamment, des paramètres utilisateurs (« user settings ») d'une version du logiciel à la suivante. Le schéma de mise à jour et de partition supporte ainsi le maintien de tout ou partie des paramètres utilisateurs et/ou d'autres partitions d'intérêt, entre les mises à jour, sans compromettre les capacités de retour en arrière puisque lesdits paramètres ont été copiés avant modification et sont donc préservés pour la version précédente.
Selon des caractéristiques particulières, lors de la mise à jour, on recherche une zone libre ou réutilisable de taille suffisante dans les partitions et, si on en trouve au moins une, on effectue, dans une zone libre ou réutilisable, l'étape d'écriture de la nouvelle version différente de la version courante du logiciel, de variables d'environnement de chargeur d'amorçage de ladite nouvelle version du logiciel, et d'au moins une image de noyau et une image de système de fichier racine.
Selon des caractéristiques particulières, si on ne trouve pas de zone libre ou réutilisable de taille suffisante, on effectue une étape de demande à l'utilisateur de choisir s'il accepte de ne pouvoir revenir à la version courante du logiciel après la mise à jour et, si l'utilisateur accepte, on effectue, dans une zone recouvrant la première partition, l'étape d'écriture de la nouvelle version différente de la version courante du logiciel, de variables d'environnement de chargeur d'amorçage de ladite nouvelle version du logiciel, et d'au moins une image de noyau et une image de système de fichier racine. Selon un deuxième aspect, la présente invention vise un dispositif de mise à jour d'application informatique, caractérisé en ce qu'il comporte :
- un moyen de création, dans une mémoire non volatile, de partitions pour logiciels et
- un moyen d'écriture adapté à écrire, dans une première partition, d'une première version d'un logiciel, de variables d'environnement de chargeur d'amorçage de ladite première version du logiciel, et d'au moins une image de noyau de système d'exploitation et, lors de la mise à jour dudit logiciel, à écrire, dans une deuxième partition différente de la première partition, d'une nouvelle version différente de la version courante du logiciel, de variables d'environnement de chargeur d'amorçage de ladite nouvelle version du logiciel, et d'au moins une image de noyau de système d'exploitation.
Selon un troisième aspect, la présente invention vise un programme d'ordinateur chargeable dans un système informatique, ledit programme contenant des instructions permettant la mise en oeuvre du procédé objet de la présente invention, tel que succinctement exposés ci-dessus.
Selon un quatrième aspect, la présente invention vise un support d'informations lisibles par un ordinateur ou un microprocesseur, amovible ou non, conservant des instructions d'un programme informatique, caractérisé en ce qu'il permet la mise en œuvre du procédé objet de la présente invention, tel que succinctement exposés ci-dessus.
Les avantages, buts et caractéristiques particulières de ce dispositif, de ce programme et de ce support d'information étant similaires à ceux du procédé de mise à jour objet de la présente invention, tel que succinctement exposé ci-dessus, ils ne sont pas rappelés ici.
D'autres avantages, buts et caractéristiques de la présente invention ressortiront de la description qui va suivre, faite, dans un but explicatif et nullement limitatif, en regard des dessins annexés, dans lesquels :
- la figure 1A représente, sous forme de logigramme, des étapes mises en œuvre au cours d'un lancement normal d'un système embarqué standard, selon l'état de l'art, sans procédure de récupération ou de maintenance,
- la figure 1 B représente, sous forme de logigramme, des étapes mises en œuvre au cours d'un lancement d'un système embarqué selon l'état de l'art supportant un mode simple de maintenance,
- la figure 1C représente, sous forme de logigramme, des étapes mises en œuvre au cours d'un lancement dans un mode de réalisation particulier du procédé objet de la présente invention,
- les figures 2A et 2B représentent, sous forme de logigrammes, des sous-étapes mises en œuvre au cours d'un chargement de logiciel dans un mode de réalisation particulier du procédé objet de la présente invention,
- la figure 3 représente, sous forme de logigramme, des étapes mises en œuvre dans un mode de maintenance dans un mode de réalisation particulier du procédé objet de la présente invention,
- la figure 4 représente, sous forme de logigramme, des étapes mises en œuvre au cours d'une mise à jour de logiciel dans un mode de réalisation particulier du procédé objet de la présente invention, - la figure 5 représente, schématiquement, une organisation de partitions mise en œuvre dans des modes de réalisation particuliers de la présente invention,
- la figure 6 représente, schématiquement, un format de carte d'affectation de partitions mis en œuvre dans des modes de réalisation particuliers de la présente invention,
- la figure 7 représente, schématiquement, de l'information concernant chacune des partitions d'une mémoire, information mise en œuvre dans des modes de réalisation particuliers de la présente invention,
- la figure 8 représente, schématiquement, un format de logiciel mis en œuvre dans des modes de réalisation particuliers de la présente invention,
- la figure 9 représente, schématiquement une liste d'information sur les sous-parties mise en œuvre dans des modes de réalisation particuliers de la présente invention,
- la figure 10 représente, schématiquement, de l'information sur une sous-partie mise en œuvre dans des modes de réalisation particuliers de la présente invention,
- la figure 11 représente, schématiquement, un exemple de configurations de partitions en mode dynamique non sécurisé, avant et après la mise à jour,
- la figure 12 représente, schématiquement, un exemple de configurations de partitions en mode statique sécurisé avec re-author (re-chiffrement), avant et après la mise à jour,
- la figure 13 représente, schématiquement, un exemple de configurations de partitions en mode restauration seule, avant et après la mise à jour et
- la figure 14 représente, schématiquement, un exemple de configurations de partitions en mode de commutation dynamique, avant et après la mise à jour.
Dans toute la description, on utilise indifféremment les termes de mise à jour (en anglais « update ») et de mise à niveau (en anglais « upgrade ») pour signifier le remplacement d'une version d'un logiciel propriétaire par un autre.
Dans le mode de réalisation décrit et représenté en regard des figures, la mise à jour sécurisée concerne les différentes couches de logiciel d'un système embarqué pour en améliorer la fiabilité, la sécurité et pour réduire les risques de rendre le système inutilisable lors de la mise à jour. Dans ce mode de réalisation décrit, on met en œuvre plusieurs nouvelles caractéristiques pour obtenir, par rapport aux mises à jour connues, une mise à jour plus flexible, plus sûre et plus fiable d'un logiciel de système embarqué.
A cet effet, d'une part l'espace de stockage du logiciel propriétaire est divisé en plusieurs partitions. Chaque partition contient une version du logiciel.
D'autre part, chaque version du logiciel est décomposée en plusieurs sous-parties, notamment :
- des variables d'environnement de chargeur d'amorçage (« bootloader »),
- un logo (optionnel), à afficher au démarrage,
- une image de noyau de système d'exploitation (en abrégé « noyau », ou « kernel »),
- une image de système de fichier racine (« root file System image ») et - une ou plusieurs images optionnelles de données générique.
Enfin, à chacune de ces sous-parties est associé un ensemble de drapeaux et paramètres permettant le support des fonctions avancées objets de la présente invention.
Un chargeur d'amorçage (ou « Boot loader ») est un logiciel permettant de lancer un ou plusieurs systèmes d'exploitation (connu sous le nom de « multi-boot »), c'est-à-dire qu'il permet d'utiliser plusieurs systèmes, à des moments différents, sur la même machine.
A tout moment, un seul logiciel propriétaire fonctionne (il est alors dit « actif ») alors que d'autres partitions contiennent des logiciels propriétaires anciens, et donc sont réutilisables, ou contiennent un logiciel de récupération, ou présentent de l'espace libre qui peut être utilisé pour de nouveaux logiciels propriétaires.
Quand un utilisateur décide de mettre à jour le système, un nouveau logiciel propriétaire est écrit dans une partition vide ou réutilisable et on laisse le système en fonctionnement intact. C'est seulement une fois que la mise à jour logicielle est finalisée et réussie que la carte d'affectations de partitions (en anglais « partition map ») est mise à jour pour que le nouveau logiciel propriétaire devienne actif et fonctionne en lieu et place de l'ancien.
Si l'utilisateur ne souhaite pas continuer à utiliser le système mis à jour, quelle qu'en soit la raison, il peut choisir de commuter en arrière vers Ie logiciel propriétaire précédemment actif ou vers n'importe quel autre logiciel propriétaire conservé dans le système.
Le schéma de partition supporte deux modes d'affectation de partition :
- un mode statique, essentiellement utilisé pour des dispositifs nécessitant des mécanismes hautement sécurisés et
- un mode dynamique, essentiellement utilise pour donner de la flexibilité d'usage.
Le schéma de partitions peut mettre en œuvre différents logiciels propriétaires possédant différentes tailles. Le schéma de partition est conçu pour que seulement la carte d'affectations, dans le cas où le mode dynamique est utilisé, et une des partitions de logiciel propriétaire soient modifiées pendant la mise à jour de logiciel propriétaire.
Le mode d'affectation de partition statique permet de conserver en mémoire le statut d'affectation de répartition en dehors de la mémoire non volatile conservant le logiciel propriétaire, par exemple dans une mémoire flash d'un microcontrôleur compagnon.
Le schéma de mise à jour et de partition supporte le chiffrement et/ou la signature et le re- authoring de tout ou partie de la mise à jour logicielle.
Le schéma de mise à jour et de partition supporte le maintien de tout ou partie des paramètres utilisateurs (« user settings ») et/ou d'autres partitions d'intérêt, entre les mises à jour, avec ou sans mise à jour de format et sans compromettre les capacités de retour en arrière.
Le schéma de mise à jour et de partition peut être implémenté et utilisé d'une manière générique, indépendante du système d'exploitation. L'exemple de schéma de mise à jour et de partition décrit ci-dessous est optimisé en combinaison avec UBOOT (marque déposée) comme « bootloader » et Linux comme système d'exploitation, sur un processeur d'architecture ARM9 (marque déposée). La figure 1A représente des étapes pour un lancement normal d'un système embarqué standard, de l'état de l'art, sans procédure de récupération ou de maintenance. Au cours de ce lancement, on réalise une étape 105 de chargement du chargeur d'amorçage (« bootloader »), une étape 110 de chargement du noyau de système d'exploitation (« kernel ») et une étape 115 de chargement de l'applicatif.
La figure 1B représente des étapes pour un lancement d'un système embarqué selon l'état de l'art supportant un mode simple de maintenance. On y retrouve les étapes 105 à 115 décrites en regard de la figure 1. Cependant, entre les étapes 105 et 110, s'y ajoute une étape 107 au cours de laquelle on détermine si le lancement s'effectue en mode normal. Si oui, on passe à l'étape 110. Sinon, on passe en mode de maintenance, au cours d'une étape 120.
La figure 1C représente des étapes pour un lancement conforme à un mode de réalisation particulier du procédé objet de la présente invention. Au cours de ce lancement, on effectue une étape 125 de chargement, par le processeur, du bootloader, éventuellement chiffré et signé.
Puis, au cours d'une étape 130, on charge une carte de partition et on la déchiffre si elle est chiffrée. Au cours d'une étape 135, on détermine si le mode de lancement est normal, c'est-à-dire s'il ne s'agit ni d'une maintenance ni d'un retour à une version antérieure.
Si le résultat de l'étape 135 est négatif, on passe au mode de maintenance décrit en regard de la figure 3. Si le résultat de l'étape 135 est positif, au cours d'une étape 140, on recherche, dans la carte de partition, le logiciel propriétaire actif standard. Au cours d'une étape 145, on détermine si ce logiciel propriétaire actif a été trouvé. Sinon, on passe au mode de maintenance. Si oui, au cours d'une étape 150, on détermine si le lancement précédent a été réussi. Sinon, on passe au mode maintenance. Si oui, au cours d'une étape 155, on détermine si un re-authoring doit être effectuée.
Sinon, on charge le logiciel propriétaire, comme illustré en regard de la figure 2. Si oui, au cours d'une étape 160, on charge le logiciel, procède au re-author et on réécrit le logiciel propriétaire après re-encryptage et on efface le drapeau correspondant.
Comme illustré en figure 2, pour charger le logiciel propriétaire, au cours d'une étape 205, on met à « échec » le drapeau de lancement précédent réussi de ce logiciel propriétaire. Puis, au cours d'une étape 210, on prend la prochaine sous-partie dans le logiciel propriétaire comme sous-partie courante, la réitération de l'étape 210, à partir de l'étape 255, permettant de traiter chacune des sous- parties du logiciel. Au cours d'une étape 215, on détermine si la sous-partie courante doit être chargée dans la mémoire vive en fonction de la valeur du drapeau correspondant. Si non, on passe à l'étape 225. Si oui, au cours d'une étape 220, on charge la sous-partie dans la mémoire vive puis on passe à l'étape 225.
Au cours de l'étape 225, on détermine si la sous-partie est signée. Si non, on passe à l'étape 235. Si le résultat de l'étape 225 est positif, au cours d'une étape 230, on détermine si la signature est vérifiée. Si non, on passe en mode maintenance. Si le résultat de l'étape 230 est positif, on passe à l'étape 235, au cours de laquelle on détermine si la sous-partie est chiffrée. Si non, on passe à l'étape 245. Si le résultat de l'étape 235 est positif, au cours d'une étape 240, on tente de déchiffrer la sous-partie et on détermine si le déchiffrement est réussi. Si non, on passe en mode maintenance. Si oui, au cours de l'étape 245, on détermine si la sous-partie est un logo. Si non, on passe à l'étape 255. Si oui, au cours d'une étape 250, on affiche le logo et on passe à l'étape 255 au cours de laquelle on détermine si toutes les sous-parties du logiciel propriétaire ont été traitées. Si non, on retourne à l'étape 210. Si oui, au cours d'une étape 260, on détermine si toutes les sous-parties requises ont été trouvées. Par exemple, pour un système basé sur Linux, il s'agit d'au moins une sous-partie avec noyau et d'une sous-partie avec le système de fichier racine. Si on est dans un mode sécurisé, le noyau doit être chiffré et le système de fichier racine doit être signé.
Si le résultat de l'étape 260 est négatif, on passe au mode maintenance. Si le résultat de l'étape 260 est positif, au cours d'une étape 265, on lance le logiciel propriétaire. Par exemple, pour Linux, le noyau est chargé en mémoire vive et le système de fichier racine et les autres informations de liste de sous-parties sont passées en paramètres. Puis, au cours d'une étape 270, le logiciel propriétaire met le drapeau de lancement précédent, pour ce logiciel propriétaire, à « réussi ».
Dans le mode de maintenance illustré en figure 3, au cours d'une étape 305, on recherche, dans la carte de partition, les logiciels propriétaire standards précédents et de restauration. Puis, au cours d'une étape 310, on détermine si plus d'un logiciel a été trouvé au cours de l'étape 305. Si non, on passe à l'étape 320. Si oui, au cours d'une étape 315, on affiche la liste des logiciels trouvés et on demande à l'utilisateur d'en choisir un. Une fois ce choix effectué par l'utilisateur, on passe à l'étape 320, au cours de laquelle on détermine si l'on doit effectuer un re-authoring du logiciel, en fonction de la valeur du drapeau associé. Si non, on passe à une étape 330. Si oui, au cours d'une étape 325, on procède au re-authoring et ré-écrit le logiciel propriétaire et on efface le drapeau associé. Puis, on passe à l'étape 330 au cours de laquelle on charge le logiciel propriétaire.
La figure 4 représente la mise à jour d'un logiciel propriétaire.
Au cours d'une étape 405, un logiciel propriétaire courant télécharge un logiciel propriétaire de mise à jour. Au cours d'une étape 410, on recherche, dans la carte de partition, une zone libre ou, subsidiairement, une zone réutilisable, de taille suffisante. Au cours d'une étape 415, on détermine si une telle zone a été trouvée. Si oui, on passe à l'étape 425. Si non, au cours d'une étape 420, on affiche un message demandant à l'utilisateur s'il accepte de rendre impossible un retour au logiciel propriétaire courant. Si la réponse de l'utilisateur est négative, le processus s'achève. Si la réponse de l'utilisateur est positive, on sélectionne la partition du logiciel courant pour effectuer les étapes suivantes.
Au cours d'une étape 425, on considère la prochaine sous-partie du logiciel propriétaire téléchargé, cette prochaine sous-partie étant la première sous-partie lors de la première itération de l'étape 425. Puis, au cours d'une étape 430, on détermine si cette sous-partie doit être obtenue par copie depuis la précédente version au cours de la mise à jour, en fonction de la valeur du drapeau associé. Si non, on passe à l'étape 435 qui consiste à écrire ladite sous-partie dans la mémoire non-volatile et à passer à l'étape 450. Si oui, au cours d'une étape 440, on détermine si une sous-partie possède le même nom dans le logiciel propriétaire courant. Si non, on passe à l'étape 450. Si oui, au cours d'une étape 445, on copie la sous-partie possédant le même nom dans le logiciel propriétaire courant pour former une partie du logiciel propriétaire mis à jour. Puis, au cours de l'étape 450, on détermine si toutes les images du logiciel propriétaire mis à jour ont été traitées. Si non, on retourne à l'étape 425. Si oui, on passe à une étape 455, où on déclare le nouveau logiciel propriétaire comme actif et l'ancien logiciel propriétaire (s'il y en a un) comme réutilisable. Puis le processus s'achève.
Comme on l'observe en figure 5, l'organisation de partitions d'une mémoire mise en œuvre par la présente invention peut prendre la forme d'une partition, 505 réservé au « bootloader », d'une partition 510 réservée à une carte d'affectation de partitions de logiciel (« software partition map ») et d'une pluralité de partitions 515 (seules trois partitions sont représentées en figure 5) pour les logiciels propriétaires (« firmware ») 1 à n. Les partitions 505 et 510 peuvent posséder une taille fixe si cela s'avère nécessaire ou simplifie l'implémentation.. En revanche, les partitions 515 sont, préférentiellement, de tailles variables en fonction de leur contenu.
Comme on l'observe en figure 6, le format de la partition de carte 510 peut prendre la forme d'un en-tête optionnel de carte 605 permettant de vérifier la conformité du format. A la suite de l'en-tête de carte 605, le format de partition de carte 510 comporte de l'information 610 concernant chacune des partitions représentées dans la mémoire, décrite en regard de la figure 7. Enfin, le format de partition de carte 510 comporte un indicateur de fin 615 qui signifie la fin de la liste de partitions.
Comme on l'observe en figure 7, l'information 610 relative à chaque logiciel propriétaire, dans la carte de partition 510, selon une implémentation particulière de la présente invention, comporte les champs suivants :
- « Offset » 705, qui représente la position de début de la partition (« Firmware offset ») déterminée depuis le début de la mémoire non volatile.
- « Taille » 710, qui représente la taille du logiciel propriétaire,
- « Date de Création » 715, qui représente la date à laquelle le logiciel propriétaire a été enregistré dans la mémoire non volatile ; cette valeur est préférentiellement à « 0 » dans le mode statique et n'est pas mise à jour,
- « Description » 720, qui contient notamment dans le cas type « logiciel propriétaire » le numéro de version [ex: « 2.0.1 »] et le numéro de « build » (par exemple, « 20080202213012 »),
- « Date de dernière utilisation » 725 : qui représente la dernière date d'utilisation du logiciel propriétaire ; cette valeur peut être utilisée quand la mise à jour du logiciel propriétaire échoue et que le système doit revenir à un autre logiciel propriétaire ; cette valeur est préférentiellement à « 0 » en mode statique et n'est pas mise à jour,
- « Type » 730, qui contient les types de partition et les drapeaux suivants :
- « Type », qui peut prendre les valeurs « libre », « logiciel propriétaire » ou « réservé »,
- « sous-type », qui peut prendre, dans le cas d'un type « logiciel propriétaire », les valeurs « standard », «maintenance », « développement » et « réservé »,
- « drapeaux », utilisés uniquement en mode dynamique et mis à une valeur spéciale en mode statique : - « sale » qui signifie que cet espace est dans un état inconnu, probablement à la suite d'une erreur lors d'une mise à jour et
- « réutilisable », qui signifie que cet espace comporte des données inutilisées, par exemple un ancien logiciel propriétaire, et qu'il peut être réutilisé, par ré-écriture, par exemple pour une mise à jour.
Dans le cas d'un type « logiciel propriétaire » :
- un drapeau « succès » indique la réussite du lancement et
- un drapeau « status » prenant une valeur parmi :
- « actif » (qui signifie que le logiciel propriétaire est le logiciel propriétaire en cours d'activité),
- « inactif » (qui signifie qu'il s'agit d'un logiciel propriétaire précédemment utilisé),
- « à ré-encrypter » (qui signifie que, pour devenir actif, ce logiciel propriétaire nécessite un ré-encryptage) et
- « réservé ».
Comme on l'observe en figure 8, le format des logiciels propriétaires comporte :
- des variables d'environnement de bootloader 805,
- une liste d'information sur les sous-parties 810, de taille variable et
- les sous-parties 815 (seules trois sous-parties sont représentées en figure 8).
Comme on l'observe en figure 9, la liste d'information sur les sous-parties comporte de l'information 905 sur chacune des sous-parties et un indicateur 910 qui signifie Ia fin de la liste.
Comme on l'observe en figure 10, l'information 905 sur une sous-partie, selon une implémentation particulière, comporte les champs suivants :
- « taille » 1005 qui représente la taille de la sous-partie,
- « adresse de chargement » 1010 qui représente l'adresse de chargement en mémoire,
- « point d'entrée » 1015, qui représente l'adresse du point d'entrée lorsque la sous-partie est du code,
- « type » 1020, qui représente le type de sous-partie, parmi les valeurs « Logo », « noyau » (« kernel »), « système de fichier racine » (« RootFilesystem »), « système de fichier générique » (« GenericFilesystem »),
- « type de système de fichiers » 1025, qui précise le format du système de fichiers employé pour ladite sous-partie (par exemple : « CRAMFS », « Ext3 » et « Yaffs2 », marques déposées),
- des drapeaux 1030 qui représentent :
- si la sous-partie est chiffrée et/ou signée ou ni chiffrée ni signée,
- si la sous-partie doit être chargé en mémoire vive (par exemple : noyau de système d'exploitation),
- si la sous-partie du logiciel propriétaire doit être copiée pour un nouveau logiciel propriétaire au moment d'une mise à jour. Ceci est utile par exemple pour préserver des paramètres utilisateurs (« User Settings ») lorsque l'on permet un retour en arrière. Dans un tel cas, une sous-partie de logiciel qui doit être copiée possède ce drapeau dans le nouveau logiciel propriétaire avec le même nom d'image. Le processus de mise à jour va donc chercher dans l'ancien logiciel propriétaire et trouver la précédente sous-partie correspondante et la copier dans le logiciel propriétaire courant.
- « Compression » 1035, qui indique le type de compression (ex : « aucune », « gzip », « « Izo », marques déposées) et
- « nom » 1040, qui représente le nom de la sous-partie.
On décrit, ci-dessous, un exemple d'implémentation. En ce qui concerne la partition de bootloader, elle contient au moins une copie du bootloader. On note que, dans certains systèmes, du fait de limitations techniques, ce bootloader peut être subdivisé en différentes phases et sous-partitions. Par exemple, certains circuits intégrés de la marque « Texas Instruments » (maque déposée), démarre avec un « UBL » de moins de 15 kilooctets qui, à son tour, lance un « UBOOT ». La présente invention supporte ces situations en regroupant les différentes étapes de chargement du bootloader au sein d'une seule étape « générique », l'implémentation se chargeant des aspects spécifiques de ces situations. On note aussi que les variables d'environnement du bootloader sont conservées dans la partition de logiciel propriétaire et non dans la partition de bootloader, de telle manière que la partition de bootloader n'ait pas besoin d'être modifiée au cours d'une mise à jour de logiciel propriétaire.
On note enfin que certains systèmes peuvent utiliser plusieurs copies de bootloader ou de partie de bootloader, par exemple pour permettre la mise à jour du bootloader, pour compenser le risque qu'un bloc endommagé apparaisse dans la partition de bootloader pour compenser les limitations de certains systèmes qui ne gèrent pas de tels blocs. L'implémentation préférée utilise un bootloader qui supporte des blocs endommagés.
L'implémentation du bootloader peut supporter soit uniquement le mode statique, pour une sécurité maximale, ou à la fois le mode statique et le mode dynamique, ou uniquement le mode dynamique, comme exposé ci-dessous. On note que, pour les systèmes très sécurisés, le bootloader est préférentiellement chiffré ou signé.
En ce qui concerne la partition de carte d'affectation de partitions de logiciel, elle contient la carte de partition. Dans le cas du mode statique, la carte de partition peut être enregistrée uniquement une fois dans la première zone valide dans la partition spécifiée à cet effet et n'est jamais réécrite. Dans le cas du mode dynamique, la carte de partition est toujours écrite dans deux zones valides consécutives de la partition qui lui est allouée. Ainsi, même si l'une de ces zones devient invalide, par exemple en raison d'un block endommagé lorsque l'on utilise une mémoire « NAND », la carte de partition est toujours disponible et est ré-écrite dans une autre zone valide. Du fait que le nombre de mises à jour est supposé être limité, disposer d'un faible nombre, par exemple cinq, de zones allouées à cet effet au sein de la partition dédiée à la carte des partitions, devrait être suffisant.
La carte de partition contient l'information sur la structure de partition des logiciels propriétaires conservés dans la mémoire non volatile, et est mise à jour pendant la mise à jour de logiciel propriétaire, dans le mode dynamique. Pour obtenir un mode sécurisé, dans le cas du mode dynamique, la carte de partition doit être re-chiffrée après modification. Certains systèmes ne supportent pas le rechiffrement mettant en œuvre des clés privées cachées afin d'éviter que des pirates n'utilisent ces clés pour générer des logiciels propriétaires chiffrés. Dans ce cas, soit on met en œuvre une clé séparée conservée, sous forme chiffrée, au début de la carte de partition ou dans le bootloader, soit on utilise le mode statique.
En ce qui concerne les partitions de logiciel propriétaire, chaque partition contient un logiciel propriétaire. Un logiciel propriétaire contient les variables d'environnement du bootloader, la liste des entêtes de sous-parties et une ou plusieurs sous-parties. Une sous-partie peut être un logo (optionnel), un noyau (« kernel ») qui est indispensable, ou un système de fichier racine (« root filesystem »), ou l'applicatif ou les paramètres applicatifs.
Le système peut comporter dans une des partitions un logiciel de maintenance qui n'est jamais effacé. Ce logiciel de maintenance peut être utile si une mise à jour de logiciel propriétaire échoue et qu'aucun logiciel propriétaire utilisable ne peut être trouvé. La partition du logiciel de maintenance a un sous-type particulier et n'est pas réutilisable pour de nouvelles versions du logiciel mais peut optionnellement être réutilisé lors de la mise à jour du logiciel de maintenance.
En mode sécurisé, les variables d'environnement de bootloader et la liste des informations sur les sous-parties sont préférentiellement chiffrées. Chaque sous-partie est chiffrée ou signée si son drapeau « chiffré/signé » le signifie. Dans le cas d'un système sécurisé (à sécurité moyenne ou haute), les sous-parties de noyau (« kernel ») et de système de fichier racine (« root filesystem ») doivent être signés (cas de la sécurité moyenne) ou chiffrés (cas de la sécurité haute). Si cela ne s'avérait pas le cas, le bootloader ne doit pas lancer le noyau. Les autres sous-parties peuvent être soit signées, soit non signées, par exemple s'il s'agit des paramètres utilisateur.
En ce qui concerne la mise à jour avec support de retour en arrière, le nombre de logiciels propriétaires complets doit être supérieur ou égal à deux.
Au cours de la mise à jour :
- l'outil de mise à jour télécharge le nouveau logiciel propriétaire de mise à jour (par exemple en utilisant l'un des protocoles HTTP, acronyme de « hypertext transfer protocol » pour protocole de transfert hypertexte, ou MTP, acronyme de « média transfer protocol » pour protocole de transfert de médias, ou des fichiers locaux) et vérifie l'information de version et
- en mode dynamique, l'outil de mise à jour lit la carte de partition et obtient l'adresse d'une partition libre ou réutilisable de taille appropriée. En mode statique, l'outil de mise à jour trouve un index pour un nouveau logiciel propriétaire en prenant l'index suivant dans la liste des partitions. Cette partition est utilisée pour y écrire le nouveau logiciel.
- l'outil de mise à jour recherche, dans la liste d'information de sous-parties du nouveau logiciel propriétaire, toute sous-partie possédant le drapeau « A copier lors de la mise a jour »,. S'il trouve de telles sous-parties, cet outil cherche une sous-partie possédant le même nom que la sous-partie en question dans le logiciel propriétaire courant et copie le contenu de cette sous-partie dans le nouveau logiciel. On note que cette étape est essentiellement destinée à Ia réutilisation des paramètres utilisateurs existants. En mode sécurisé, puisque la carte de partition est chiffrée en mode statique, et puisque le déchiffrement n'est souvent disponible qu'au moment du démarrage du système, soit une carte de partition complète doit être maintenue en mémoire vive au moment du lancement, ce qui constitue le mode de réalisation préférentiel, soit une description de partition devant être utilisée pour la mise à jour est transférée au noyau.
En mode dynamique, l'outil de mise à jour met à jour la carte de partition en ajoutant l'information concernant le nouveau logiciel propriétaire et en mettant son drapeau à « actif ».
On met également les drapeaux du logiciel propriétaire précédemment actif à « réutilisable/ inactif » et on met à jour sa date de dernière utilisation.
En mode statique, l'outil de mise à jour met à jour les index et états du logiciel propriétaire courant dans le sous-système utilisé pour leur stockage.
Enfin, si nécessaire (par exemple : ré-encryptage requis et disponible uniquement au démarrage du système), l'outil de mise à jour redémarre le système ou préférentiellement lance directement le nouveau logiciel.
On observe, en figure 11 , un exemple de configurations de partitions en mode dynamique non sécurisé, avant et après la mise à jour. Avant la mise à jour, la configuration de partitions comporte la partition de bootloader 1105, la partition de carte de partition 1110, la partition du logiciel A, actif, 1115, la partition du logiciel B, libre, 1120 et la partition (optionnelle) du logiciel C, récupération, 1125. Après la mise à jour, la configuration de partitions comporte la partition de bootloader 1105, la partition de carte de partition modifiée 1130, la partition du logiciel A, devenue réutilisable, 1135, la partition du logiciel B, devenu actif, 1140 et la partition (optionnelle) du logiciel C, récupération, 1125.
On observe, en figure 12, un exemple de configurations de partitions en mode statique sécurisé avec re-author, pendant et après la mise à jour. Pendant la mise à jour, la configuration de partitions comporte la partition de bootloader 1205, la partition de carte de partition 1210, la partition du logiciel A, actif, 1215, la partition du logiciel B, à reauthorer, 1220 et la partition (optionnelle) du logiciel C, récupération, 1225. Après la mise à jour, la configuration de partitions comporte la partition de bootloader 1205, la partition de carte de partition, inchangée, 1210, la partition du logiciel A, réutilisable et non modifiée, 1235, la partition du logiciel B, actif après reauthoring, 1240 et la partition (optionnelle) du logiciel C, récupération, 1225.
Si la mémoire non volatile est contrainte, par exemple pour des raisons de coût , et qu'il n'est pas possible de stocker au minimum deux versions complètes du logiciel pour permettre un retour en arrière, alors seulement un logiciel complet et un logiciel de maintenance, réduit gérant les cas critiques, sont stockés, la nouvelle version du logiciel venant simplement remplacer la version courante.. Ce mode de mise en œuvre de la présente invention est appelé « maintenance seule ».
On observe, en figure 13, un exemple de configurations de partitions en mode maintenance seule, pendant et après la mise à jour. Pendant la mise à jour, la configuration de partitions comporte la partition de bootloader 1305, la partition de carte de partition 1310, la partition du logiciel A en cours d'écriture (sale), 1315 et la partition du logiciel B, de maintenance, 1320. Après la mise à jour, la configuration de partitions comporte la partition de bootloader 1305, la partition de carte de partition 1310, la partition du logiciel C, actif, 1335 et la partition du logiciel B, de maintenance, 1320.
En cas de commutation dynamique permettant le retour en arrière par restauration d'une version antérieure, même si le système a été conçu pour supporter le retour en arrière, en prévoyant suffisamment de mémoire non volatile, les mises à jour ultérieures peuvent présenter une taille croissante et dépasser la limite de taille à laquelle deux versions peuvent êtres conservées. Dans un tel cas, l'utilisateur est informé de cette contrainte au cours du processus de mise à jour et a le choix soit de ne pas mettre à jour, soit de perdre la capacité de retour en arrière. Si l'utilisateur choisit de poursuivre la mise à jour, le processus de mise à jour fusionne et recrée les partitions existantes pour :
- créée une grande partition pour le nouveau logiciel propriétaire complet et
- mettre à jour, si nécessaire, ou créer si elle n'existe pas déjà, la partition pour le logiciel de maintenance.
On observe, en figure 14, un exemple de configurations de partitions en mode de commutation dynamique depuis le retour en arrière avant et en mode maintenance seule après, avant et après la mise à jour. Avant la mise à jour, la configuration de partitions comporte la partition de bootloader 1405, la partition de carte de partition 1410, la partition du logiciel A, actif, 1415, et la partition du logiciel B, réutilisable, 1420. Après la mise à jour, la configuration de partitions comporte la partition de bootloader 1405, la partition de carte de partition modifiée 1430, la partition du logiciel C, actif et modifié, 1435 et la partition de logiciel D, de maintenance, modifiée, 1445.
En ce qui concerne la gestion de mise à jour, la vérification de version est effectuée du côté serveur. Le client envoie le numéro de sa version courante avec d'autres informations, telles que l'identifiant de dispositif, au serveur, en utilisant la requête HTTP « GET ». Par exemple, cette requête prend la forme GET « http://maintenance.awox.com/fcheck?version= XXXX&device=YYYY ».
Si aucune mise à jour du logiciel n'est disponible, le serveur retourne la réponse « 204 No Content ». Si une version mise à jour est disponible, le serveur retourne la réponse « 200 OK » et, dans le corps de la réponse, une description de la mise à jour (version, taille et nouvelles fonctionnalités). On peut, pour cela, utiliser une forme de texte libre, une forme XML (acronyme de « extensible markup language » pour langage de balisage extensible) ou une syntaxe « .ini », en fonction de l'outil disponible pour utiliser cette réponse. On peut aussi spécifier un langage dans la requête, en utilisant un en-tête « Accept-Language », de telle manière que le serveur retourne une description dans ce langage.
Le serveur trouve la version appropriée qui est susceptible de mettre à jour la version courante, version qui peut ne pas être la dernière version, comme exposé plus bas. Cette procédure aide aussi dans le cas où la mise à jour est payante. Dans un tel cas, le serveur retourne une information indiquant que le logiciel mis à jour ne peut être téléchargé qu'après paiement. L'utilisateur peut contacter le vendeur pour procéder à ce paiement. Après le téléchargement, une méthode locale de mise à jour, telle que USB (acronyme de « Universal Sériai Bus », pour bus série universel), comme expliqué plus bas, peut être utilisée pour la mise à jour. On note qu'il n'y a pas d'obligation de vérification de version pour la mise à jour locale, par exemple depuis USB/MMC-SD (acronyme de « USB/multimedia card - Secure Digital » pour carte USB multimédia numérique sécure). Cela est utile dans le cas d'une mise à jour par dégradation (« downgrading »), par exemple pour une démonstration ou une version d'évaluation.
Dans le cas où la mémoire non volatile serait endommagée, et que l'utilisateur presse un bouton de mise à jour forcée, le client n'est pas toujours capable d'envoyer l'information indiquant la version courante au serveur. Dans ce cas, seule l'identification de dispositif est envoyée au serveur. Sur la base de cette identification, le serveur retourne la dernière version gratuite disponible du logiciel pour le modèle de dispositif identifié.
L'utilisateur accède, par exemple, au menu « paramètres » puis « mise à jour » pour déterminer si une mise à jour est disponible. En variante, une recherche de mise à disposition d'une mise à jour est effectuée périodiquement et l'utilisateur est averti par une alarme si une mise à jour est disponible.
En ce qui concerne la méthode d'acquisition du logiciel propriétaire, on peut utiliser un réseau, par exemple en mettant en œuvre le protocole HTTP, ou une mémoire locale, par exemple de type à connecteur USB. Dans le premier cas, le fichier du logiciel propriétaire de mise à jour peut être téléchargé en utilisant la commande HTTP « GET », par exemple :
« GET http://maintenance.awox.com/fget?version=XXXXX&device=YYYY »
Si la requête est valide, le serveur retourne le fichier de mise à jour. Sinon, le serveur retourne un message d'erreur, par exemple « 404 file not found » (fichier non trouvé).
Dans le cas d'utilisation d'une mémoire locale, l'interface graphique pour l'utilisateur (« GUI ») fournit une méthode simple de navigation et de sélection d'un fichier de mise à jour local.
En ce qui concerne la commutation manuelle en mode de maintenance, le chargeur d'amorçage, ou bootloader, est capable de détecter au démarrage une combinaison de touches ou un code infrarouge spécifique si le produit est doté d'une télécommande. Ceci afin d'interrompre le lancement normal et afficher une boîte de dialogue de substitution. Le dialogue est, par exemple, comme suit :
« Vous avez sélectionné le mode de maintenance, voulez-vous restaurer votre système ?, pressez 9 pour lancer le mode de maintenance, pressez 1 pour lancer le système avec la version courante v1.2.6, pressez 2 pour lancer le système avec la version précédente v1.2.5, installée le 25 janvier 2007 et utilisée pour la dernière fois le 21 juillet 2007. »
Cette option est particulièrement utile dans le cas où le système principal est endommagé et que le lancement normal ne fonctionne pas. Cette méthode peut aussi être utilisée comme une instruction d'installation lorsque l'utilisateur a reçu un logiciel payant et l'a stocké dans un support local, par exemple une clé USB. Lors du lancement, l'utilisateur peut sélectionner de lancer le dispositif en mode de maintenance et naviguer pour sélectionner ce fichier local.
Le chargeur de lancement met à « échec » le drapeau de lancement réussi du logiciel propriétaire qu'il est en train de lancer. Le logiciel met à « réussi » ce drapeau à la fin de la séquence de lancement. Le chargeur de lancement vérifie ce drapeau lorsqu'il cherche un logiciel propriétaire à lancer et si ce drapeau n'indique pas un succès, le chargeur affiche une boîte de dialogue telle que celle décrite ci-dessus et propose par défaut la dernière version du logiciel propriétaire utilisée qui a donné lieu à un lancement réussi. Le comportement du chargeur de lancement dépend alors des choix disponibles.
En ce qui concerne la partition des valeurs de paramètres du dispositif, notamment les paramètres utilisateur, pour la grande majorité des produits, un système de fichier dédié est utilisé pour les stocker, par exemple les paramètres de connexion WiFi et l'adresse MAC (acronyme de « média access control » pour contrôle d'accès au média), Ia langue de l'utilisateur, etc. Ce système de fichier est stocké comme une sous-partie du logiciel pour permettre aux valeurs de paramètres d'être sauvegardées.
Pour permettre à l'utilisateur de conserver ses valeurs de paramètres personnelles lors d'une mise à jour, cette sous-partie du logiciel utilise le drapeau «A copier lors de la mise a jour» dans l'information. Si ce drapeau indique une copie à effectuer, l'outil de mise à jour recherche dans le logiciel propriétaire actif pour une image de même nom et copie son contenu dans le nouveau logiciel propriétaire en mémoire non volatile.
On note que, dans des modes de réalisation, les informations nécessaires au re-authoring sont conservées en dehors de la mémoire non volatile conservant le logiciel propriétaire, par exemple dans une mémoire flash d'un microcontrôleur compagnon.

Claims

REVENDICATIONS
1 - Procédé de mise à jour d'application informatique, caractérisé en ce qu'il comporte :
- une étape de création, dans une mémoire non volatile, de partitions pour logiciels,
- une étape d'écriture, dans une première partition, d'une première version d'un logiciel, de variables d'environnement de chargeur d'amorçage de ladite première version du logiciel, et d'au moins une sous-partie de noyau de système d'exploitation et
- lors de la mise à jour dudit logiciel, une étape d'écriture, dans une deuxième partition différente de la première partition, d'une nouvelle version différente de la version courante du logiciel, de variables d'environnement de chargeur d'amorçage de ladite nouvelle version du logiciel, et d'au moins une sous- partie de noyau de système d'exploitation.
2 - Procédé selon la revendication 1, caractérisé en ce que, au cours de l'étape de création de partitions, on crée, en outre, une carte d'affectation des partitions de logiciel listant les versions du logiciel présentes, leur état, et indiquant quelle version du logiciel est active.
3 - Procédé selon l'une quelconque des revendications 1 ou 2, caractérisé en ce que, au cours d'au moins une étape d'écriture dans une partition, on écrit, outre des variables d'environnement de chargeur d'amorçage, une liste de sous-parties d'une version de logiciel incluant un noyau et un système de fichier racine.
4 — Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce qu'il comporte une étape de détermination si la nouvelle version du logiciel fonctionne et, si oui, une étape d'affectation, à la nouvelle version, d'une indication qu'elle est active, et d'affectation à la précédente version, d'une indication qu'elle est inactive.
5 - Procédé selon la revendication 4, caractérisé en ce que lesdites indications sont conservées dans une carte d'affectation de partitions de logiciel.
6 - Procédé selon la revendication 5, caractérisé en ce qu'au moins une partie de la carte d'affectation de partition est conservée en dehors de la mémoire non-volatile conservant le logiciel propriétaire, par exemple dans une mémoire non-volatile séparée..
7 - Procédé selon l'une quelconque des revendications 1 à 6, caractérisé en ce que, lors de la mise à jour du logiciel, on détermine si cette version du logiciel doit être ré-encryptée et, si oui, on effectue le réencryptage et on réécrit la version dans la partition correspondante.
8 - Procédé selon la revendication 7, caractérisé en ce que les informations nécessaires au re-authoring sont conservées en dehors de la mémoire non volatile conservant le logiciel propriétaire, par exemple dans une mémoire flash d'un microcontrôleur compagnon.
9 - Procédé selon l'une quelconque des revendications 1 à 8, caractérisé en ce que, lors de la mise à jour, on recherche une zone libre ou réutilisable de taille suffisante dans les partitions et, si on en trouve au moins une, on effectue, dans une zone libre ou réutilisable, l'étape d'écriture de la nouvelle version différente de la version courante du logiciel. 10 - Procédé selon la revendication 9, caractérisé en ce que, si on ne trouve pas de zone libre ou réutilisable de taille suffisante, on effectue une étape de demande à l'utilisateur de choisir s'il accepte de ne pouvoir revenir à la version courante du logiciel après la mise à jour et, si l'utilisateur accepte, on effectue, dans une zone recouvrant la première partition, l'étape d'écriture de la nouvelle version différente de la version courante du logiciel.
11 - Procédé selon la revendication 9, caractérisé en ce que, si on ne trouve pas une zone libre ou réutilisable de taille suffisante mais que la combinaison de plusieurs zones soit suffisante, on effectue une étape de demande à l'utilisateur de choisir s'il accepte de ne pouvoir revenir à Ia version courante du logiciel après la mise à jour et, si l'utilisateur accepte, on effectue, dans une zone recouvrant plusieurs partitions, l'étape d'écriture de la nouvelle version différente de la version courante du logiciel et on modifie la carte des partitions.
12 - Procédé selon la revendication 11 , caractérisé en ce que, en sus de l'écriture de la nouvelle version du logiciel, on crée également une partition supplémentaire et y écrive une version minimale du logiciel utilise exclusivement a des fins de récupération et ou maintenance.
13 - Procédé selon l'une quelconque des revendications 1 à 12, caractérisé en ce que, lors de la mise à jour du logiciel, pour chaque sous-partie du logiciel de mise à jour, on détermine si cette sous-partie doit être copiée depuis la précédente version dudit logiciel et, si oui, on copie la sous-partie correspondante depuis la partition de l'ancienne version dans la partition de la nouvelle version.
14 - Dispositif de mise à jour d'application informatique, caractérisé en ce qu'il comporte :
- un moyen de création, dans une mémoire non volatile, de partitions pour logiciels et
- un moyen d'écriture adapté à écrire, dans une première partition, d'une première version d'un logiciel, de variables d'environnement de chargeur d'amorçage de ladite première version du logiciel, et d'au moins une sous-partie noyau de système d'exploitation et, lors de la mise à jour dudit logiciel, à écrire, dans une deuxième partition différente de la première partition, d'une nouvelle version différente de la version courante du logiciel, de variables d'environnement de chargeur d'amorçage de ladite nouvelle version du logiciel, et d'au moins une sous-partie noyau de système d'exploitation.
15 - Programme d'ordinateur chargeable dans un système informatique, ledit programme contenant des instructions permettant la mise en œuvre du procédé selon l'une quelconque des revendications 1 à 14.
16 - Support d'informations lisibles par un ordinateur ou un microprocesseur, amovible ou non, conservant des instructions d'un programme informatique, caractérisé en ce qu'il permet la mise en œuvre du procédé selon l'une quelconque des revendications 1 à 14.
PCT/FR2009/000637 2008-06-02 2009-06-02 Procede et dispositif de mise a jour d'application informatique WO2009156615A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US12/995,746 US20110145807A1 (en) 2008-06-02 2009-06-02 Method and device for updating a computer application
EP09769456A EP2310941A1 (fr) 2008-06-02 2009-06-02 Procede et dispositif de mise a jour d'application informatique

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0803034 2008-06-02
FR0803034 2008-06-02

Publications (1)

Publication Number Publication Date
WO2009156615A1 true WO2009156615A1 (fr) 2009-12-30

Family

ID=40070917

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2009/000637 WO2009156615A1 (fr) 2008-06-02 2009-06-02 Procede et dispositif de mise a jour d'application informatique

Country Status (3)

Country Link
US (1) US20110145807A1 (fr)
EP (1) EP2310941A1 (fr)
WO (1) WO2009156615A1 (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102646048A (zh) * 2012-05-03 2012-08-22 中兴通讯股份有限公司 移动终端触摸屏固件升级的方法及装置
EP2619705A2 (fr) * 2010-09-24 2013-07-31 Intel Corporation Mode de chiffrement modifiable pour un chiffrement de mémoire avec protection contre des attaques de reproduction
CN105204995A (zh) * 2015-09-21 2015-12-30 上海斐讯数据通信技术有限公司 一种基于手机平台的动态调试关键参数的方法及系统
CN105320534A (zh) * 2014-08-01 2016-02-10 中兴通讯股份有限公司 单板的boot远程升级方法、装置及系统
CN110633091A (zh) * 2019-08-28 2019-12-31 西安超霸电气科技有限公司 一种电子模块及其软件无线升级方法

Families Citing this family (62)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4958692B2 (ja) * 2007-08-31 2012-06-20 キヤノン株式会社 配信装置、配信方法、及びコンピュータプログラム
US9954819B2 (en) * 2010-05-26 2018-04-24 Automation Anywhere, Inc. System and method for compliance based automation
US10430180B2 (en) 2010-05-26 2019-10-01 Automation Anywhere, Inc. System and method for resilient automation upgrade
US10733540B2 (en) 2010-05-26 2020-08-04 Automation Anywhere, Inc. Artificial intelligence and knowledge based automation enhancement
JP5984326B2 (ja) * 2010-07-07 2016-09-06 キヤノン株式会社 情報処理装置、プログラムの更新方法及びプログラム
US8458346B2 (en) 2010-07-30 2013-06-04 Sap Ag Multiplexer for multi-tenant architectures
US8392908B2 (en) * 2010-07-30 2013-03-05 Sap Ag Standardized procedures for implementing software changes
US8522070B2 (en) * 2010-07-30 2013-08-27 Sap Ag Tenant rescue for software change processes in multi-tenant architectures
US8880464B1 (en) * 2011-12-08 2014-11-04 Lockheed Martin Corporation Methods and apparatus for synchronizing closed heterogenous systems
KR20130068630A (ko) * 2011-12-15 2013-06-26 한국전자통신연구원 임베디드 디바이스의 초기화 방법 및 장치
US8924952B1 (en) * 2012-06-27 2014-12-30 Amazon Technologies, Inc. Updating software utilizing multiple partitions
CN102880495A (zh) * 2012-10-15 2013-01-16 华为终端有限公司 移动终端及其软件升级方法
GB2507596B (en) * 2012-10-30 2014-09-17 Barclays Bank Plc Secure computing device and method
CN103914205B (zh) * 2013-01-09 2015-11-25 腾讯科技（深圳）有限公司 一种智能终端的文件缩略图展示方法和装置
CN104903853B (zh) 2013-01-15 2018-09-04 慧与发展有限责任合伙企业 动态固件更新
CN103942225B (zh) * 2013-01-23 2018-06-08 阿里巴巴集团控股有限公司 一种混合型应用客户端的资源调用方法、客户端及系统
FR3010553B1 (fr) * 2013-09-10 2015-09-04 Sagemcom Broadband Sas Procede de mise a jour d'un logiciel de demarrage d'un dispositif multiprocesseur
WO2016007563A1 (fr) * 2014-07-07 2016-01-14 Symphony Teleca Corporation Appareils, procédés et systèmes pour plate-forme de mise à jour de dispositif intégré à distance
JP6333467B2 (ja) * 2015-03-24 2018-05-30 三菱電機株式会社 情報処理装置
JP2017033136A (ja) * 2015-07-30 2017-02-09 富士通株式会社 情報制御プログラム、情報制御装置及び情報制御方法
US9792109B2 (en) 2015-09-30 2017-10-17 Apple Inc. Software updating
CN105893090B (zh) * 2016-03-31 2019-05-10 武汉光迅科技股份有限公司 一种嵌入式系统bootrom和应用程序升级方法
EP3441876B1 (fr) * 2016-04-27 2023-02-15 Honor Device Co., Ltd. Procédé et dispositif de traitement de fichier basé sur une mise à niveau de correctif, terminal et support d'informations
CN106020892A (zh) * 2016-05-26 2016-10-12 深圳创维数字技术有限公司 一种非linux系统软件boot参数传递方法及系统
CN107526574A (zh) * 2016-06-20 2017-12-29 阿里巴巴集团控股有限公司 系统启动模式的控制方法及装置
CN106155961B (zh) * 2016-07-25 2019-08-06 杭州迪普科技股份有限公司 基于BootLoader向内核传参数的方法及装置
US10037203B1 (en) * 2016-07-28 2018-07-31 National Technology & Engineering Solutions Of Sandia, Llc Real-time software upgrade
US10936719B2 (en) * 2016-09-23 2021-03-02 Apple Inc. Preserving trust data during operating system updates of a secure element of an electronic device
JP2019040571A (ja) * 2017-08-29 2019-03-14 オンキヨー株式会社 電子機器
US11775814B1 (en) 2019-07-31 2023-10-03 Automation Anywhere, Inc. Automated detection of controls in computer applications with region based detectors
TWI722269B (zh) * 2018-01-26 2021-03-21 和碩聯合科技股份有限公司 韌體更新方法及使用此方法的電子裝置
US10853097B1 (en) 2018-01-29 2020-12-01 Automation Anywhere, Inc. Robotic process automation with secure recording
US10769427B1 (en) 2018-04-19 2020-09-08 Automation Anywhere, Inc. Detection and definition of virtual objects in remote screens
US10908950B1 (en) 2018-04-20 2021-02-02 Automation Anywhere, Inc. Robotic process automation system with queue orchestration and task prioritization
US10733329B1 (en) * 2018-04-20 2020-08-04 Automation Anywhere, Inc. Robotic process automation system and method with secure credential vault
US11354164B1 (en) 2018-04-20 2022-06-07 Automation Anywhere, Inc. Robotic process automation system with quality of service based automation
US11693923B1 (en) 2018-05-13 2023-07-04 Automation Anywhere, Inc. Robotic process automation system with hybrid workflows
US11556362B2 (en) 2019-03-31 2023-01-17 Automation Anywhere, Inc. Robotic process automation system with device user impersonation
US11113095B2 (en) 2019-04-30 2021-09-07 Automation Anywhere, Inc. Robotic process automation system with separate platform, bot and command class loaders
US11301224B1 (en) 2019-04-30 2022-04-12 Automation Anywhere, Inc. Robotic process automation system with a command action logic independent execution environment
US11243803B2 (en) 2019-04-30 2022-02-08 Automation Anywhere, Inc. Platform agnostic robotic process automation
US11614731B2 (en) 2019-04-30 2023-03-28 Automation Anywhere, Inc. Zero footprint robotic process automation system
CN112015587B (zh) * 2019-05-31 2023-03-24 烽火通信科技股份有限公司 一种增强操作系统可靠性的方法及装置
CN110780943B (zh) * 2019-10-18 2022-07-12 厦门亿联网络技术股份有限公司 一种从设备统一固件的方法及系统
US12017362B2 (en) 2019-10-31 2024-06-25 Automation Anywhere, Inc. Productivity plugin for integration with robotic process automation
US11481304B1 (en) 2019-12-22 2022-10-25 Automation Anywhere, Inc. User action generated process discovery
US10911546B1 (en) 2019-12-30 2021-02-02 Automation Anywhere, Inc. Robotic process automation with automated user login for multiple terminal server hosted user sessions
US11348353B2 (en) 2020-01-31 2022-05-31 Automation Anywhere, Inc. Document spatial layout feature extraction to simplify template classification
US11514154B1 (en) 2020-01-31 2022-11-29 Automation Anywhere, Inc. Automation of workloads involving applications employing multi-factor authentication
US11086614B1 (en) 2020-01-31 2021-08-10 Automation Anywhere, Inc. Robotic process automation system with distributed download
US11182178B1 (en) 2020-02-21 2021-11-23 Automation Anywhere, Inc. Detection of user interface controls via invariance guided sub-control learning
JP7540171B2 (ja) * 2020-03-18 2024-08-27 富士フイルムビジネスイノベーション株式会社 情報処理装置、情報処理システム、及びプログラム
US12111646B2 (en) 2020-08-03 2024-10-08 Automation Anywhere, Inc. Robotic process automation with resilient playback of recordings
US11734061B2 (en) 2020-11-12 2023-08-22 Automation Anywhere, Inc. Automated software robot creation for robotic process automation
US11782734B2 (en) 2020-12-22 2023-10-10 Automation Anywhere, Inc. Method and system for text extraction from an application window for robotic process automation
US11567754B2 (en) * 2021-03-01 2023-01-31 Vmware, Inc. Techniques for non-disruptive operating system upgrade
CN113254048B (zh) * 2021-06-21 2021-09-28 深之蓝(天津)水下智能科技有限公司 引导程序更新方法、装置、设备及计算机可读介质
US12097622B2 (en) 2021-07-29 2024-09-24 Automation Anywhere, Inc. Repeating pattern detection within usage recordings of robotic process automation to facilitate representation thereof
US11820020B2 (en) 2021-07-29 2023-11-21 Automation Anywhere, Inc. Robotic process automation supporting hierarchical representation of recordings
US11968182B2 (en) 2021-07-29 2024-04-23 Automation Anywhere, Inc. Authentication of software robots with gateway proxy for access to cloud-based services
TWI799035B (zh) * 2021-12-29 2023-04-11 威聯通科技股份有限公司 系統更新方法及電子裝置
CN115437670B (zh) * 2022-09-06 2023-11-21 北京斯年智驾科技有限公司 基于tftp的汽车控制器程序升级系统

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5701492A (en) * 1996-03-29 1997-12-23 Canon Kabushiki Kaisha Fail-safe flashing of EPROM
WO2000007106A1 (fr) * 1998-07-31 2000-02-10 Intel Corporation Techniques et dispositif permettant d'actualiser une memoire remanente -

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5210854A (en) * 1989-06-14 1993-05-11 Digital Equipment Corporation System for updating program stored in eeprom by storing new version into new location and updating second transfer vector to contain starting address of new version
CA2357382A1 (fr) * 2001-09-17 2003-03-17 Soma Networks, Inc. Methode, appareil et systeme de mise a niveau de logiciels
US7089549B2 (en) * 2002-04-01 2006-08-08 International Business Machines Corp. Updating flash memory
US20050124332A1 (en) * 2003-12-08 2005-06-09 Clark David R. Mobile device programming system and method
US20090260004A1 (en) * 2008-04-10 2009-10-15 Palm, Inc. Computer program updates for mobile computing device

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5701492A (en) * 1996-03-29 1997-12-23 Canon Kabushiki Kaisha Fail-safe flashing of EPROM
WO2000007106A1 (fr) * 1998-07-31 2000-02-10 Intel Corporation Techniques et dispositif permettant d'actualiser une memoire remanente -

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
DIPERT B ET AL: "DESIGNING AN UPDATABLE BIOS USING FLASH MEMORY", MICROPROCESSORS AND MICROSYSTEMS, IPC BUSINESS PRESS LTD. LONDON, GB, vol. 16, no. 8, 1 January 1992 (1992-01-01), pages 427 - 446, XP000330850, ISSN: 0141-9331 *

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2619705A2 (fr) * 2010-09-24 2013-07-31 Intel Corporation Mode de chiffrement modifiable pour un chiffrement de mémoire avec protection contre des attaques de reproduction
EP2619705A4 (fr) * 2010-09-24 2015-01-21 Intel Corp Mode de chiffrement modifiable pour un chiffrement de mémoire avec protection contre des attaques de reproduction
CN102646048A (zh) * 2012-05-03 2012-08-22 中兴通讯股份有限公司 移动终端触摸屏固件升级的方法及装置
CN105320534A (zh) * 2014-08-01 2016-02-10 中兴通讯股份有限公司 单板的boot远程升级方法、装置及系统
CN105204995A (zh) * 2015-09-21 2015-12-30 上海斐讯数据通信技术有限公司 一种基于手机平台的动态调试关键参数的方法及系统
CN105204995B (zh) * 2015-09-21 2017-12-22 上海斐讯数据通信技术有限公司 一种基于手机平台的动态调试关键参数的方法及系统
CN110633091A (zh) * 2019-08-28 2019-12-31 西安超霸电气科技有限公司 一种电子模块及其软件无线升级方法

Also Published As

Publication number Publication date
EP2310941A1 (fr) 2011-04-20
US20110145807A1 (en) 2011-06-16

Similar Documents

Publication Publication Date Title
WO2009156615A1 (fr) Procede et dispositif de mise a jour d'application informatique
CN109634645B (zh) 固件升级方法及终端
US8799890B2 (en) Generating a version identifier for a computing system based on software packages installed on the computing system
US20080320466A1 (en) Automatic software installation and cleanup
FR2862397A1 (fr) Demarrage securise d'un appareil electronique a architecture smp
EP2466470B1 (fr) Module matériel de sécurité et procédé de traitement dans un tel module
FR2972821A1 (fr) Procede et dispositif d'installation/desinstallation de modules logiciels, avec resolution centralisee de contraintes, dans des equipements d'aeronef
EP2024798B1 (fr) Procédé et dispositif de configuration sécurisée d'un terminal au moyen d'un dispositif de stockage de données de démarrage
US20150039872A1 (en) Multiple Signed Filesystem Application Packages
EP2427823B1 (fr) Capture et chargement d'états de système d'exploitation
WO2005008509A2 (fr) Procede de gestion des composants logiciels integres dans un systeme embarque
WO2009059763A1 (fr) Procede de deverrouillage d'un calculateur de controle moteur
CN113867768A (zh) 操作系统处理方法、装置、电子设备及存储介质
CN115145650A (zh) 信息处理装置、存储介质及信息处理方法
FR3003366A1 (fr) Procede, dispositif et programme d'ordinateur pour l'installation ou la desinstallation automatique de modules logiciels dans des equipements embarques d'un aeronef
CN112988181A (zh) 应用更新方法、装置、终端、服务器和可读存储介质
EP0838053B1 (fr) Procede et dispositif permettant a un programme fige de pouvoir evoluer
CN113110849A (zh) 按需加载资源
US8380969B2 (en) Method of retaining crucial thin client system settings unused by the BIOS in the memory space of a storage device containing the BIOS
EP2048576B2 (fr) Procédé de mise à jour sécurisée d'un programme à lancement automatique et entité électronique portable le mettant en oeuvre
JP5417820B2 (ja) システムファイル共有装置、システムファイル共有方法及びプログラム
EP1559003A2 (fr) Carte a microcircuit comportant des moyens de publication de ses objets informatiques
EP3131005A1 (fr) Equipement électronique ferroviaire comprenant un programme de démarrage comportant une ou plusieurs partitions de démarrage, véhicule ferroviaire et système ferroviaire associés
EP3203405B1 (fr) Procede d'execution d'instructions d'applications orientees objet par un interpreteur
FR2841667A1 (fr) Interface graphique utilisateur permettant d'installer des programmes informatiques d'un lot de demarrage

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: 09769456

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

REEP Request for entry into the european phase

Ref document number: 2009769456

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2009769456

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 12995746

Country of ref document: US