WO2004061655A1

WO2004061655A1 - Program compaction method employing dynamic code deletion

Info

Publication number: WO2004061655A1
Application number: PCT/FR2003/003736
Authority: WO
Inventors: Renaud Marlet; PHilippe TIGNOL
Original assignee: Trusted Logic
Priority date: 2002-12-18
Filing date: 2003-12-15
Publication date: 2004-07-22
Also published as: AU2003300617A1; FR2849229B1; FR2849229A1

Abstract

The invention relates to a program compaction method employing dynamic code deletion. More specifically, but not exclusively, the invention relates to the compaction of programs which are executed on platforms having small memory resources, e.g. small on-board systems such as chip cards and payment terminals. The inventive method comprises four steps, namely: the determination of fragments of a program which, under certain hypotheses, can be deleted without modifying the semantics; the instrumentation of a program in order to mark fragments which can be deleted and the conditions in which they can be deleted; the optional transformation of the program in order to increase the memory saving that will be produced by the deletion of deletable fragments; and the memory structuring of a program with deletable fragments and the effective deletion of said fragments in order to enable the re-use of the corresponding freed-up memory areas.

Description

METHOD FOR COMPACTING A PROGRAM BY DYNAMIC CODE DELETION.

The present invention relates to a program compacting method by dynamic code deletion.

It has more particularly, but not exclusively, the object of compacting programs which execute on platforms having low memory resources; this is the case, for example, of small on-board systems such as smart cards and payment terminals.

This method is particularly suitable for the release of memory resources in these systems and therefore allows the reuse of these said memory resources.

It includes four stages:

• the determination of fragments of a program which, under certain assumptions, can be deleted without modifying the semantics,

• the instrumentation of a program to mark deletable fragments and the conditions under which they can be deleted,

• the possible transformation of the program to increase the memory economy that a deletion of the deletable fragments will bring, • the structuring in memory of a program with deletable fragments and the effective deletion of these fragments to allow the reuse of the corresponding freed memory areas.

This program compacting by dynamic code deletion is particularly useful in the following two cases:

• if, during the execution of a program, one or more fragments of this program are no longer useful in the rest of the execution, they can be completely deleted. The corresponding memory space can thus be recovered for other uses, without affecting the behavior of the program.

• the deletion of one or more program fragments can also be forced at any time. The deleted fragment (s), as well as the portions of the program which exploited these deleted fragments, are then replaced by code which signals the deletion of said fragments, so that an error is notified if the execution of the program requires said fragments . Following the deletion of code, the program may thus lose certain functionality. The choice of program fragments to delete therefore achieves a compromise between the functionalities offered by the program and the memory size it occupies.

Deleting program fragments can be done as many times as necessary during an execution to save more memory space.

The deletion of program fragments is also of security interest: if the circumstances require that functionalities of a program must become permanently inoperative for reasons of security, it is safer to actually delete them from system memory than to set up access control.

The need to save memory is not the only reason that small embedded systems are a good target for code deletion compaction; the very nature of the programs that run on these systems also contributes to this. Indeed, it is frequent that programs loaded on these systems are executed only once. However, it is most often programs without real termination that react endlessly to events and commands submitted to them. However, the life cycle of these programs often goes through irreversible phases of initial initialization. Consequently, the program fragments which carry out these initialization phases become useless once the initializations have been carried out, and can therefore be deleted.

Two common cases of such initialization phases are in the case of the smart card: installation, which creates in memory an executable copy of a program, and personalization, which configures this executable copy of program for a particular user.

For example, in systems that accept "Java Card" programs, a language commonly used on smart cards, installation is performed by calling a method (routine) reserved for this single use, called "install" . Once this method is called, its content is never executed again, except to create a new copy of the same program. Under the very frequent assumption that the system should never execute a single copy of this program, the content of the "install" method can be completely deleted, as well as any other auxiliary method called only by "install" (and not by other methods of the program). The situation is the same for personalization. The only difference, in the case of "Java Card", is that the code fragments responsible for personalization are not necessarily identifiable by a particular method. Nevertheless, a very widespread extension of the "Java Card" system, called "Open Platform", introduces a method, called "processData", which is called only in the personalization phase. Once the customization is complete, this method can therefore also be deleted, in the same way as "instaU" for the installation phase, under an identical assumption.

In the event that the execution of a deleted program fragment remains physically possible although prohibited by hypothesis, it is recommended to replace the deleted fragment with code that signals an error. In the case of "Java Card", the deleted code can be replaced, whether it covers the complete content of a method or not, by an exception throwing.

It turns out that dynamic code deletion nevertheless raises several questions:

• structuring a program in memory to allow the release of fragments,

• determination of deletable code fragments in a program,

• the instrumentation of the program to signal the deletable fragments, • the possible transformation of the program to optimize the deletable fragments,

• the decision to delete these fragments,

• the effective deletion of these fragments, depending on their form,

• the possible restructuring of the resulting program to increase the possibility of re-using the memory areas thus freed. Beforehand, it is necessary to recall the various functionalities which can be offered by the memory managers present in the execution systems. There are four main types:

• Allowance / release. An ordinary program execution platform is generally provided with a memory manager which comprises at least two functionalities: (1) allocate a memory block, and (2) free up a previously allocated memory block. When a block is released, the corresponding memory area can be re-used for other uses, in particular for a new memory allocation. For example, in "Unix" operating systems, the "malloc" function allocates a memory block of a given size and returns a pointer to the beginning of the block, and the "free" function frees a given block. • Resizing. Memory managers also often include functionality to resize a previously allocated memory block, reducing the size of the block at the end. Some systems also sometimes allow resizing by increasing the size of a block at the end. A block can be physically moved or not in memory to allow this resizing. For example, in type systems

"Unix", the "realloc" function reduces (or increases) the size of a block from the end. Reducing the size of the allocated block thus makes it possible to delete a final fragment and to free the corresponding memory so that it can be reused by the system.

• Dynamic cutting. More rarely, memory managers also make it possible to dynamically split a previously allocated memory block into several fragments, as if as many blocks had initially been allocated separately. Selected fragments can thus be released and re-used by the system. • Defragmentation. Some memory managers also perform a defragmentation of the memory, whether transparent or not for the user. This operation consists in moving the allocated memory blocks to group them. Defragmentation reduces the number of small gaps in free areas between allocated memory blocks, which are difficult to reuse.

The displacement of allocated memory blocks however induces certain constraints concerning the pointers towards the interior of blocks. In particular, if displacements of portions of the program take place, in particular after a possible phase of editing links, relocation of addresses and jumps displacements may be necessary.

It turns out that to allow the removal of fragments from a program, and especially the efficient reuse of the corresponding memory, the program must be structured in memory wisely. Four typical cases for managing the memory representation of a program are to be considered: static prefragmentation (before execution) of a program, dynamic fragmentation (after execution), dynamic reduction in block size, and program restructuring after deleting fragments.

• Static pre-fragmentation. If, during the loading of a program, the system has knowledge of the fragments which could be deleted in the future, it can structure the program in memory in several blocks, using for this its ordinary mechanism of memory allocation. In this case, an individual memory space is allocated for each deletable fragment, which can thus be freed separately, without impacting the rest of the program.

• Dynamic fragmentation. If the program did not receive any particular structuring when it was loaded, fragments can nevertheless be flagged as deleted during the execution. So that the corresponding memory areas can be reused, the system can perform a dynamic division of the memory block initially allocated for the program and thus reduce itself to the above scenario of a pre-fragmented program. • Dynamic block size reduction. However, not all systems have a memory manager powerful enough to perform dynamic fragmentation. There is however a special case that systems with simple memory management generally know: it is when the memory fragment to be deleted is located at the final end of the block allocated for the program. In this case, it is sufficient that the system allows a readjustment of the size of the memory blocks already allocated. Reducing the size of the block allocated for the program thus makes it possible to delete the final fragment and free up the corresponding memory so that it can be reused by the system.

• Defragmentation. It is also possible to dynamically and explicitly defragment a program block where areas of code have been deleted, without going through the memory manager. This operation consists in assembling some of the program portions remaining after deletion so as to form one or more compact, continuous blocks, without a free landlocked region. This technique is useful in several cases. It is first of all applicable in systems whose memory manager does not allow an arbitrary dynamic fragmentation but simply a resizing of the allocated memory blocks: the remaining program portions are assembled in a compact group at the start of the block or blocks and the size of the block (s) is adjusted to their content. Defragmentation can also be useful more generally to increase the possibility of re-using the freed memory areas. Indeed, many small areas are more difficult to reuse than a single large area, which can possibly be cut again. However, note that moving portions of the program into memory may require relocating the resulting code. For example, the addresses or movements of inter-block jumps must be recalculated. It is a delicate task to perform, both on the machine language of a real microprocessor and on the language of a virtual machine. But if whole routines are deleted in a program, relocating the remaining code is often much easier because the information to be updated then relates more to the addresses, movements and indices which make it possible to identify the routines rather than the jumps in the body. routines even.

It turns out that the determination of deletable fragments can be carried out in three ways:

1. A programmer, who has knowledge of the life cycle of the program, knows, from what stages of execution, which fragments of programs can be considered as deletable.

2. Depending on the language, fragments of a program can be deleted by construction, as is the case for "install" and "processData" in "Java

Card ".

3. Finally, automatic program processing makes it possible to determine fragments of code which are no longer materially useful from certain points and conditions of execution: this mode of determination constitutes the first step of the method described below.

In accordance with the method according to the invention, the compaction of a program by dynamic deletion of code is carried out according to the following four steps: • the determination of fragments of a program which, under certain assumptions, can be deleted without modifying the semantics, • the instrumentation of a program to mark deletable fragments and the conditions under which they can be deleted,

• the possible transformation of the program to increase the memory economy that a deletion of the deletable fragments will bring,

• the structuring in memory of a program with deletable fragments and the effective deletion of these fragments to allow the reuse of the corresponding freed memory areas.

First, the determination of fragments of a program that can be deleted is based on static program analysis.

Static program analysis means a set of automatic program processing techniques that allow properties to be determined concerning the execution of a program without having to actually execute it. An extremely common example of static analysis is abstract interpretation, which studies approximations to the execution of a program.

The automatic determination of fragments of programs that can be deleted by static program analysis can be implemented according to the following operating sequence:

• modeling, in the form of an abstract state, of the initial state of an executable copy of the program;

• marking this state as "not yet explored";

• as long as there are one or more non-terminal abstract states marked "not yet explored":

- choice of one of these states; - marking of the state chosen as "now explored"; - abstract execution of the program from this state taking into account all its possible interactions (events and commands received, etc.), which leads to one or more new states; - marking of these new states as "not yet explored";

- merging of the resulting program states which are similar, generalizing them if necessary.

Stopping the algorithm with certainty can be implemented as follows:

• modeling the state of a program so that there is only a finite number of different configurations, or

• more or less effective generalization of the resulting states to limit the number of states to be considered, the arbitrary state generalizing all the others and thus ensuring that the end of the process can always be forced.

This process makes it possible to construct an oriented graph which models the state transitions of the program. The vertices (or nodes) of this graph are made up of the different states encountered; the edges (or arcs) of this graph represent the calculations and interactions carried out by the program, and the corresponding portions of the program executed.

The program fragments determined to be deleted are those which are no longer executable once the program has reached a certain state. In other words, if there exists a vertex S of the graph from which certain edges are not accessible, then the program regions corresponding to these inaccessible edges and not appearing among the regions corresponding to the edges accessible from S are suppressable when the program execution reaches a state corresponding to S. The fragments thus identified can be deleted without affecting the semantics of the program, on the assumption that the program is at its last execution.

The quantity and size of the removable program fragments determined by this process depend on several parameters, in particular:

• the degree of precision with which the states of the program are modeled,

• the degree of precision with which the interactions with the program are modeled,

• the possible creation of intermediate states between each interaction with the program,

• the conditions of use of the generalization of state to possibly force the termination of the algorithm.

For practical reasons of memory resources, this determination method will generally be implemented outside of the program execution system, before it is loaded. There is nothing to prevent it from taking place on the system itself.

Second, the instrumentation of the program to mark the deletable fragments, as well as the conditions under which they can be deleted, is carried out as follows:

The fragments must first be marked in order to be known to the system. This marking makes it possible on the one hand to structure the program in memory in order to favor the deletion of code, for example with a prefragmentation, and on the other hand to indicate the fragments to be deleted at a given moment of the execution. There are many ways to mark deletable code areas. A fragment consisting of a continuous sequence of instructions of a routine can for example be identified by a start address and an end address of a fragment, or else a start or end address and a length of fragment. A fragment can also be identified by special marks, neutral for execution, to indicate the location of the start and end of a fragment. A fragment made up of a routine can for example be identified by the name of the routine or its memory address.

The code deletion condition associated with a program fragment must also be preserved. It can be arbitrarily complex.

The deletion condition can be based on the current control of the program. It can be for example the address of a program point: when this execution point is reached, then the associated fragment can be deleted. It can also be the designation of a routine of the program: when this routine is called, or when it returns, then the associated fragment can be deleted.

The deletion condition can also be based on the current data handled by the program. For example, it could be the designation of a program variable which, when it takes a certain value, or exceeds a certain threshold, signals that the associated fragment can be deleted.

The indication of the fragments to be deleted can also be present in the executable code itself.

In this case, the program itself signals to the system, during its execution, that a given fragment can be deleted. This type of implementation is particularly well suited to the case of removal conditions complex because we then have all the power of expression of a program to make a decision to delete.

In the case of a "Java Card" system, the additional information concerning the deletable fragments of an executable code (code stored in the "Method Component") can be integrated in a portable manner into the object program ("CAP file") in the form of components of auxiliary programs ("Custom Components"): these components will be ignored by systems which do not know how to manage compaction by deleting code.

Thirdly, the possible transformation of the program to increase the memory economy brought by the deletion of code, is carried out as follows:

The determination of deletable program fragments can be automatic or not, carried out on the very platform of execution of the program or else outside. Following this determination, and the corresponding instrumentation, the program can optionally be automatically transformed, without changing its semantics, in order to optimize the possibility of re-using the freed memory areas. This optimization process is based on several kinds of program transformations, sources of various gains.

Deletable fragments initially separated in the body of the program can be moved to become contiguous. This program transformation reduces the fragmentation of programs where code has been deleted: the total size of the deletable fragments is increased and the number of these fragments is reduced. The possibility of re-using the freed memory areas is therefore better. This transformation is particularly useful for memory management systems that do not have a defragmentation mechanism. Deletable fragments can also be placed in specific routines. As previously mentioned with regard to the structuring of a program in memory (for defragmentation), this transformation facilitates the code deletion mechanism. It does not even require any mechanism if the last routine of the memory block contains the program.

Deletable fragments can also be grouped together at the end of the program, in the reverse order of probable deletion. In other words, the fragment most likely to be deleted is placed at the very end of the program block. The next fragment most likely to be deleted is placed just before, and so on. This transformation facilitates the deletion of code by dynamic reduction of block size. For example, in the case of "Java Card", we can place the "install" method at the end of the "Method Component", preceded by the "processData" method.

In the general case, there is no optimal order for the ordering of the deletable fragments because the choices of deletion can depend on dynamic data: there is no sort better than the others. In the case where the deletable fragments are determined by automatic program processing, as described above, a suitable order is provided by first traversing the state graph in depth, starting from the initial state, and a selection of deletable fragments encountered during this journey. Certain fragments which can be deleted as a function of dynamic data (therefore unknown at the time of scheduling) can be omitted from the deletion to arrange a continuous chain of fragments whose successive deletion is certain.

These transformations may require the introduction of jumps or routine calls. To the extent that these program transformations displace code, they may also require relocation of program areas affected by code movements.

These transformations can be automated or manual, that is to say left to the discretion of the person preparing the program for compacting by deleting code.

It should be noted that these transformations are not mutually exclusive; they can be combined.

Regarding the decision to delete program fragments, three entities can decide to delete a code fragment: the program, the system and the system administrator.

The program can be instrumented, manually or automatically, to signal to the system that one of its fragments can be deleted. It is the very execution of the program which then triggers the deletion. Signaling that a fragment can be deleted can be implemented in various ways: instruction or group of specialized instructions, call to a specific routine of the system, etc. The specification of the deletable fragment can be implemented in various ways: designation of one or more code areas, of a routine or a group of particular routines, of the current routine, etc. For example, in "Java Card", the "install" method could be ended by calling a system method which would signal that the method being executed is no longer useful and can be deleted.

The system, if it has information concerning the possible deletion of program fragments during execution (whether these fragments and conditions for deletion have been determined automatically or not), can take the initiative to delete some of these fragments as soon as the corresponding conditions are met. The person managing the system can also force the deletion of certain program fragments. In this case, the system must have a command which makes it possible to stipulate program fragments to be deleted.

These three sources of choice are not mutually exclusive; they can be combined.

Fourth, the structuring in memory of a program with deletable fragments and the effective deletion of these fragments to allow the reuse of the corresponding freed memory areas is carried out as follows:

Once the decision has been made to delete certain fragments, the release of the corresponding memory areas only becomes effective as a function of the actual structure of the program in memory. It boils down to the following cases:

• if the program is statically prefragmented, each fragment to be deleted is released individually, to the memory manager of the system.

• if the system memory manager allows dynamic fragmentation, the program is fragmented on the fly and the fragments to be deleted are released individually, as in the previous case.

• if the fragments to be deleted are located at the end of memory blocks, the corresponding memory space is freed by resizing the blocks to reduce their size.

• if the system is equipped with a mechanism to relocate code, all the elements not deleted from the program are gathered at the beginning of the block, relocated, and the block is resized to reduce its size. These different types of effective deletion are not exclusive; they can be combined.

If a code fragment can be deleted without preserving the semantics of the program (the program then loses some of its functionality), it is recommended to set up a control mechanism. An error will thus be notified if the execution of the program requires a deleted fragment. To do this, you can for example replace the deleted code with code that throws an error.

If a deleted fragment must be replaced by code that signals an error, a new memory block can be allocated for this purpose. Alternatively, the deleted block can also be reused by resizing it to adapt to the size of the code that signals the error.

Thus the method proposed according to the invention is particularly suitable for the release of memory resources on platforms such as small on-board systems and therefore allows the reuse of these said memory resources.

Claims

1. A method of compacting a program by dynamic deletion of code, characterized in that it comprises the following steps:

• the determination of fragments of a program which can be deleted either without modifying the semantics when the program is at its last execution or by modifying the semantics when these modifications are acceptable, • the instrumentation of a program to mark deletable fragments and the conditions under which they can be deleted,

2. Method according to claim 1, characterized in that before the aforesaid structuring in memory of a program, the method comprises the transformation of the program to increase the memory economy that will bring the deletion of deletable programs.

3. Method according to claim 1, characterized in that the above determination of deletable program fragments is carried out automatically by static program analysis.

4. Method according to claim 3, characterized in that the above determination of fragments of deletable programs is carried out from an oriented graph constructed according to the following operating sequence: • modeling, in the form of an abstract state, of the initial state of an executable copy of the program;

• marking this state as "not yet explored";

• as long as there are one or more non-terminal abstract states marked as "not yet explored":

- choice of one of these states;

- marking of the state chosen as "now explored";

- abstract execution of the program from this state taking into account all its possible interactions and producing one or more new states;

- marking of these new states as "not enclosed explored";

- merging of the resulting program states which are similar, generalizing them if necessary; the nodes of the graph being constituted by the different states encountered in the above operating sequence, the arcs between two states of this graph representing the portions of the program executed to pass from one state to another in the above operating sequence, and the fragments deletable being the portions of the program corresponding to the arcs which are no longer accessible from a certain node under the condition that the execution leads to the state represented by this node.

5. Method according to claim 4, characterized in that the stopping of the above sequence with certainty is implemented according to at least one of the following two processes: • modeling the state of a program so as to that there are only a finite number of different configurations,

• the generalization of the resulting states to limit the number of states to be considered, the arbitrary state generalizing all the others and thus guaranteeing that the end of the process can always be forced.

6. Method according to claim 4, characterized in that it comprises a determination of the deletable program fragments which is carried out as a function of one or more of the following parameters: • the degree of precision with which the states of the program are modeled ,

• the possibility of creating intermediate states between each interaction with the program,

• the conditions of use of the generalization of state to force the termination of the algorithm.

7. Method according to claim 1, characterized in that the instrumentation of the program consists of one or more of the following information:

• auxiliary data that does not alter the execution of the program and intended to be used by the execution system,

• additional instructions included in the body of the program and intended to be executed in the same way as ordinary program instructions.

8. Method according to claim 1, characterized in that it comprises a marking of the deletable fragments carried out in the following manner:

• the identification of a start address and an end address of the fragment, and / or

• the location of a start or end address and the length of the fragment, and / or • the location of a routine identifier, and / or • the introduction of special marks, neutral for execution, to indicate the location of the start and end of a fragment.

9. Method according to claim 1, characterized in that the suppression conditions are based on:

• routine control of the program, and / or

• the current data handled by the program.

10. Method according to claim 2, characterized in that the transformation of the program to increase the memory economy provided by the deletion of code is carried out according to at least one of the following three possibilities:

• the displacement of the deletable fragments initially separated in the body of the program, to become contiguous, “the positioning of the deletable fragments in specific routines,

• regrouping of the fragments that can be deleted at the end of the program block in the reverse order of probable deletion.

11. Method according to one of claims 4 and 10, characterized in that, in the case where the deletable fragments are determined by static program analysis, a suitable deletion order is provided by first traversing the graph in depth state, starting from the initial state, and a selection of the deletable fragments encountered during this journey.

12. Method according to claim 10, characterized in that certain fragments which can be deleted as a function of the dynamic data, can be omitted from the deletion to arrange a continuous chain of fragments whose successive deletion is certain.

13. Method according to claim 1, characterized in that the structuring in memory of a program with deletable fragments and the effective deletion of these fragments to allow the reuse of the corresponding freed memory areas is carried out according to at least one of the four following types of deletion:

• if the program is statically prefragmented, each fragment to be deleted is freed individually, with the memory manager of the system,

• if the system memory manager allows dynamic fragmentation, the program is fragmented on the fly and the fragments to be deleted are released individually, as in the previous case,

• if the fragments to be deleted are located at the end of memory blocks, the corresponding memory space is freed by resizing the blocks to reduce their size, • if the system is equipped with a mechanism to re-code, all the elements not deleted from the program are gathered at the start of the block, re-located, and the block is resized to reduce its size.

14. The method of claim 1 intended to be implemented on embedded systems, characterized in that a program with removable fragments executing on these above systems is structured in memory according to the information made available by the instrumentation of this program , and in that deletable fragments are effectively deleted when the conditions stipulated by the instrumentation of the program are fulfilled.