WO2005001780A1

WO2005001780A1 - Memory management in a portable data carrier

Info

Publication number: WO2005001780A1
Application number: PCT/EP2004/006859
Authority: WO
Inventors: Erich Englbrecht; Robert Hockauf; Thorsten Ulbricht; Rudolf Schubert
Original assignee: Giesecke & Devrient Gmbh
Priority date: 2003-06-27
Filing date: 2004-06-24
Publication date: 2005-01-06
Also published as: DE10329145A1; EP1642245A1

Abstract

The invention relates to a method for the management of memory in a portable data carrier (10). According to the invention, programs are entered into a file system (38, 38'), wherein an entry of a program into a file system (38, 38') comprises at least references to (56.x, 56.x') memory blocks (52.x, 52.x') wherein the program is arranged in the memory (14) of the data carrier (10), and the memory blocks (52.x, 52.x') are compatible, in the position thereof in the memory (14), with lateral frames (50.x, 50.x') which are predetermined by a memory management unit (28) in a manner which enables the program to be executed in areas in the memory (14) defined by the entry in the file system (38, 38'). A data carrier (10) and a computer program product comprise corresponding characteristics. The invention enables execution of programs stored in a file system (38, 38') of a portable data carrier (10) directly at the storage point in the file system (38, 38').

Description

Storage management for a portable data carrier

The invention relates generally to the field of memory management for a portable data carrier and, more particularly, to the field of executing programs contained in a memory of the portable data carrier. A portable data carrier in the sense of the present document can in particular be a chip card (smart card) in different designs or a chip module. The data carriers considered here are relatively powerful and in particular have a memory management unit (MMU).

The article "Multi-application card Controllers go 32-bit" by Bernd Meier in the magazine SECURE - The Silicon Trust Report, published by Infineon Technologies AG, No. 5, 2002, pages 32 - 35, available at http: // www .silicon-trust.com / pdf / secure_5 / 32_techno_l.pdf, describes a virtual storage management system for portable data carriers. The memory available on the data carrier, like a virtual address space, is divided into 64-byte pages. A memory management unit assigns pages in a virtual address space to the respective page frames in physical memory. Programs can still be loaded into the data carrier after it has been personalized. However, a file system for storing such programs and other files is not described.

In general, there is a need for file systems for portable data carriers to arrange the files stored in them as space-saving as possible - ideally without waste. However, if such a file arranged in the memory according to the criteria of the file system contains a program, this must generally be copied or moved for execution by the data carrier. This is necessary because the storage management unit of the data carrier specifies page frames in the memory the limits of which the program must be aligned in order to be executed. It would be pure coincidence if the program in the file system already had the required position in memory. The time-consuming and memory-intensive copying or moving process is a considerable disadvantage.

Accordingly, the object of the invention is to provide a technology for memory management in portable data carriers which enables programs stored in a file system to be executed directly at their storage location in the file system ("execute in place"). The invention should preferably be able to be used in connection with the most varied of file systems, with no or at most a slight adjustment of the proposed file system being required. Then e.g. particularly reliable and / or particularly space-saving file systems can be used.

According to the invention, said object is achieved in whole or in part by a method according to claim 1, a portable data carrier according to claim 10 and a computer program product according to claim 12. The dependent claims relate to preferred embodiments of the invention.

The invention is based on the basic idea of storing programs entered in the file system in memory blocks whose position in the memory is compatible with the page frames of the memory specified by the memory management unit. A program entered in the file system can therefore be executed directly in the memory blocks in which the program is stored without copying or moving operations. The entry of such a program contains at least references the memory blocks in which the program is located; in some configurations, the entry may contain all or some of the memory blocks instead of or in addition to the references.

The invention thus enables an "execute in place" of the programs entered in the file system, without necessarily requiring that all data structures of the file system are completely aligned or rastered to the limits of the memory frame specified by the memory management unit. A complete rasterization of the file system would have the disadvantage of considerable memory waste, especially with small file sizes and / or large page frames. The invention generally also includes such embodiments; However, configurations are preferred in which at least some data structures of the file system are indicated in the memory of the data carrier independently of the page frame boundaries. are arranged. This applies in particular to data structures that are not part of executable programs, e.g. Directories or regular, non-executable files. In this way, particularly good storage space utilization can be achieved.

According to the invention, with regard to the file system used, the only requirement is that the file system be able to hold entries for programs, each entry itself containing at least references to memory blocks. In some configurations, the entries can be regular files in which the references are contained. In other configurations, however, the entries correspond to internal management information of the file system.

The invention can be integrated into virtually any known file system with little or no change. Here are in particular To name file systems that avoid memory wastage because they work with data structures of different sizes (e.g. so-called extents). However, file systems that work purely block-oriented can also be used. A tried and tested and known file system is preferably used.

According to the invention, the position of the memory blocks in which the programs are located in the memory in the memory should be compatible with the page frames of the memory specified by the memory management unit. Here, a "page frame" is to be understood according to the customary usage of an area of the real memory, the limits of which are specified by the memory management unit and which is assigned to an adjustable range of virtual addresses by the memory management unit.

In preferred embodiments, the memory blocks are considered to be compatible with the page frames specified by the memory management unit if the limits of each memory block fall on page frame limits. Here, in some embodiments, each memory block can completely contain multiple page frames. However, configurations in which the memory blocks and the side frames coincide, that is to say have the same size and the same orientation in the memory, are particularly preferred. Embodiments in which each page frame contains several memory blocks are also not excluded. However, it must be ensured that executable programs are always stored in groups of successive memory blocks, because otherwise the program code in the memory would not be compatible with the arrangement of the page frames. The memory blocks in which the programs entered in the file system are stored can be contained in different configurations in the file system and / or in a separate grid area. It can also be provided that the entire file system is divided into memory blocks that are compatible with the page frames. Administrative information of the file system or non-executable files need not be aligned with the block boundaries, so that the waste can be kept to a minimum.

A virtual address space is preferably set up for executing a stored program in that the memory management unit is configured appropriately on the basis of the references contained in the file system. The configuration information can be stored in the main memory of the data carrier or in whole or in part in a separate cache area.

In advantageous configurations, the data carrier has a UNIX®-like operating system. A Linux® operating system and a file system provided for this purpose are particularly preferably used in a suitably modified form. Such file systems are e.g. known per se under the names Ext2fs, Ext3fs, ReiserFS, XFS and JFS. The book "linder standing the Linux Kernel" by D. P. Bovet and M. Cesati, O'Reilly Verlag, 2nd edition, December 2002, to which reference is hereby made, contains a detailed technical description of the Linux® operating system.

The data carrier according to the invention contains a file system and memory blocks with executable programs. The computer program product according to the invention can be a physical medium with stored program instructions, for example a semiconductor memory or a floppy disk or a CD-ROM. However, the computer program product can also be a non-physical medium, for example a signal transmitted over a computer network. In particular, the computer program product can contain an operating system or an operating system module, which is introduced into the portable data carrier in the course of the manufacture, initialization or personalization thereof.

In preferred configurations, the data carrier and / or the computer program product have features which correspond to the features described above and / or to the features mentioned in the dependent method claims.

Further features, advantages and objects of the invention will become apparent from the following description of several exemplary embodiments and alternative embodiments. Reference is made to the drawing, in which:

1 is a block diagram of a data carrier with a file system and a separate raster area according to an embodiment of the invention,

Fig. 2 is a flowchart of a method for executing a program in a data carrier according to the invention, and

FIG. 3 shows a representation of a file system and a block allocation table in an embodiment modified from FIG. 1. The data carrier 10 shown in FIG. 1 has a processor 12, a memory 14 and an interface circuit 16 for contactless or contact-based communication with an external terminal (not shown) on a single semiconductor chip.

The memory 14 is divided into several memory fields. In the present exemplary embodiment, a working memory 18 configured as RAM, a read-only memory 20 configured as ROM and a non-volatile memory 22 configured as EEPROM are provided as memory fields. In the memory 14 - partly in the read-only memory 20 and partly in the non-volatile memory 22 - there is program code which implements an operating system 24. In the present exemplary embodiment, the operating system 24 is a variant of the operating system known under the Linu brand, tailored to use in the data carrier 10.

The processor 12 includes a processor core 26 and a memory management unit (MMU) 28. The processor core 26 can access the memory 14 via an internal address bus 30, an external address bus 32 and a data bus 34. The memory management unit 28 is connected between the internal and the external address bus 30, 32 in order to convert logical addresses which the processor core 26 outputs to the internal address bus 30 during the execution of the program into physical addresses of the memory 14.

The address is implemented with a granularity specified in terms of hardware. The memory management unit 28 assigns a real page in the memory 14 to each page of the virtual address space, if such a real page is available. The real pages in the memory 14 are arranged in a grid specified by the memory management unit 28. Every field in this grid, that is to say every memory area that can accommodate a memory page, is referred to as a page frame. The size of each page frame can be 1 KByte, for example.

The mapping of virtual memory pages into the page frames of the memory 14 is determined by page allocation data 36, which are assigned to the memory management unit 28 in the conceptual representation of FIG. 1. The page assignment data 36 can have one page table or a plurality of hierarchically structured page tables. Furthermore, a cache can be provided in order to accelerate access to frequently required parts of the page assignment data 36. In various configurations, the page assignment data 36 can be contained in whole or in part in the memory 14 or in whole or in part in a special cache area of the processor 12.

The non-volatile memory 22 contains a file system 38 that has a plurality of entries. 1, a directory 40 and three files 42, 44, 46 are shown as entries in the file system 38. In the present exemplary embodiment, the file system 38 has a structure which is known per se; For example, one of the systems known under the names Ext2f s, Ext3f s, ReiserFS, XFS and JFS can be used as file system 38. The file system 36 can be block oriented and e.g. use a block raster that corresponds to the rasterization of the page frames specified by the memory management unit 28. In other configurations, the file system 38 uses the available memory area, however, regardless of the page frame division.

A raster region 48 is further provided in the non-volatile memory 22, which in the exemplary embodiment shown in FIG. 1 is not part of the File system is 38. The grid area 48 is structured such that the grid fields are compatible with the page frames defined by the memory management unit 28. In the exemplary embodiment in FIG. 1, each field shown in the grid area 48 corresponds exactly to one side frame; some of these side frames are provided by way of example with the reference numerals 50.1, 50.2, 50.3, 50.4 - hereinafter referred to collectively as 50.x.

In the example of FIG. 1, the memory 14 contains two programs, which are subdivided into memory blocks and stored in the raster area 48. The memory blocks of the first program are shown in FIG. 1 by vertical hatching, and the memory blocks of the second program are shown by horizontal hatching. A memory block of the first program, namely that located in the page frame 50.2, is provided with the reference symbol 52.1 by way of example. The memory block of the second program located in the page frame 50.4 has the reference symbol 52.2. The memory blocks 52.1 and 52.2 and further memory blocks which contain parts of executable programs are referred to in the following as 52.x.

The grid area 48 has a block assignment table 54 in the side frame 50.1, which - e.g. in the form of a bit field - indicates which page frames 50.x are occupied by memory blocks 52.x and which page frames 50.x are free. The free side frames 50.x are shown in Fig. 1 without hatching. The block allocation table 54 does not necessarily have to be aligned with the page frame grid; In alternative embodiments, it is provided to store the block allocation table 54 outside of the raster area 48.

The link between an entry of an executable program in the file system 38 and the associated memory blocks 52.x is made via References contained in the entry. 1, the entry relating to the first program is formed by the file 42, which in turn contains references - for example pointers or address information - to the memory blocks 52.x of the first program. For example, the reference 56.1 created in the file 42 points to the memory block 52.1 of the first program in the page frame 50.2, and the reference 56.2 contained in the file 46 points to the memory block 52.2 of the second program in the page frame 50.4. In summary, the references to memory blocks 52.x created in the file system 38 are referred to below as 56.x.

In the exemplary embodiment described here, the references 56.x are in regular files of the file system 38 - here e.g. files 42 and 46 - saved. With regard to the management structures of the file system 38, there is therefore no difference between these files 42 and 46 and the file 44, which is not related to an executable program. This configuration has the advantage that no special features of the file system 38 have to be taken into account. In alternative embodiments, however, it can be provided that the entries in the file system 38 which relate to executable programs are not created as regular files, but rather these entries, e.g. to integrate in file system management information.

In the exemplary embodiment described so far, the size and orientation of the memory blocks 52.x in the grid area 48 corresponded exactly to the page frames 50.x specified by the memory management unit 28. In alternative embodiments, however, it can be provided that a memory block 52.x completely fills several page frames 50.x. It can also be provided that several memory blocks 52.x in one Side frame 50.x fall; In this case, however, the administration of the raster area 48 must ensure that such memory blocks 52.x located in a single page frame 50.x always contain a single, contiguous section of the respective program.

FIG. 2 shows an exemplary sequence that is carried out by the data carrier 10 in order to start a program contained in the raster area 48. The process begins in step 60 with the operating system 24 receiving a command to execute the program. In step 62, the entry relating to the program is opened in the file system 38; in the embodiment of Fig. 1 this entry is a reference file - e.g. as file 42 - designed. The references 56.x contained in the reference file are read in step 64.

In step 66, page allocation information is generated and transferred to the memory management unit 28. Processing steps are usually required in order to generate the page assignment data 36 from the content of the entry or the reference file in the format required by the memory management unit 28. The page mapping information mentioned in step 66 may correspond to the raw raw data or the page mapping data 36 or intermediate information that is generated during processing. In particularly simple configurations, the entry in the file system 38 already contains the required page assignment data 36 in a form that can be used directly by the memory management unit 28.

After the reference file - for example the file 42 - has been closed in step 68, the memory management unit 28 provides a virtual address space for the program in step 70. In some configurations Further processing steps of the page allocation data 36 take place, while in other embodiments the memory management unit 28 has already been completely configured in connection with step 66.

The memory management unit 28 is now configured such that it maps the logical addresses of the virtual address space of the program to the corresponding memory blocks 52.x in the raster area 48. The program can thus - without a copying or moving process being required - be executed directly at the storage location of the memory blocks 52.x in the raster area 48. The fact that the program in the real address space of the memory 14 is possibly in memory blocks 52.x which are not contiguous and / or are reversed in order is compensated for by the address mapping carried out by the memory management unit 28. For the program, if desired, e.g. a large contiguous address space can be made available.

In the embodiment of FIG. 1, the raster area 48 is separated from the file system 38. 3 shows an alternative embodiment with a block-oriented file system 38 'which takes up the entire available storage space. The entire file system 38 'is rastered in accordance with the page frames 50.1', 50.2 ', 50.3', 50.4 ', ... - generally designated 50.x' - specified by the memory management unit 28 (FIG. 1). If it is not empty, each page frame 50.x 'in the file system 38' can have either structures of the file system 38 'or a memory block 52.1', 52.2 ', ... - generally designated 52.x' - of an executable program. A file tree with a directory 40 'and three files 42', 44 ', 46' is shown as an example in FIG. 3 as structures of the file system 38 '. Files 42 'and 44' do not refer to executable programs. These files 42 ', 44' are therefore created in accordance with the structure provided by the file system 38 '. In particular, in some configurations it is provided that non-executable files and other structures of the file system 38 '- for example directories or administrative information - are not oriented towards the borders of the page frames 50.x, but rather are arranged in the memory 14 with as little waste as possible. This is illustrated in FIG. 3 using the example of the file 42 ', which extends over a contiguous memory area, which each takes up part of the page frames 50.1' and 50.2 '.

The file 46 'represents an entry of an executable program in the file system 38'. As already explained in connection with FIG. 1, the file 46 'is designed as a reference file, each containing a reference 56.1', 56.2 ', ... - generally designated 56.x '- on the memory blocks 52.x' of the executable program. These memory blocks 52.x ¹ occupied with program code are shown hatched in FIG. 1; each memory block 52.x 'fills exactly one page frame 50.x' of the rasterized file system 38 '. In alternative embodiments, as already mentioned above, the sizes of the page frames 50.x 'and the memory blocks 52.x' may differ from one another, provided that only the position of the memory blocks 52.x 'is compatible with the predetermined limits of the page frames 50.x'.

FIG. 3 also shows a block assignment table 54 ', the content of which reflects the exemplary assignment of the section of the rasterized file system 38' shown in FIG. 3. The block allocation table 54 'can be stored in the file system 38' or separate from it. Various modifications that have already been described above in connection with FIG. 1 can be applied accordingly to the file system 38 'of FIG. 3. In particular, it can be advantageous not to create entries in the file system 38 'which correspond to executable programs as regular files - such as the file 46'. Rather, such entries can be integrated into the actual file tree by including the corresponding references 56.x ', for example in administration information of the file system 38'. In some configurations, such administrative information can be so-called index nodes or inodes.

A program stored in the rasterized file system 38 'of Fig. 3 is called e.g. according to the method described above and shown in Fig. 2.

Claims

Patent claims

1. A method for memory management in a portable data carrier (10) which has at least one memory (14) and a processor (12) with a memory management unit (28), the processor (12) for executing programs which are stored in the memory ( 14) are included, can use the memory management unit (28) to access the memory (14), characterized in that in the memory (14) a file system (38, 38 ') is also administered, in which at least some of the programs are entered an entry of a program in the file system (38, 38 ') contains at least references (56.x, 56.x') to memory blocks (52.x, 52.x ¹ ) in which the program is stored in the memory ( 14), and the memory blocks (52.x, 52.x ') in their position in the memory (14) with the page frames (50.x, 50.x') specified by the memory management unit (28) of the memory (14) are compatible to the processor (12) the execution of the program to the by the unit rag in the file system (38, 38 ') specified locations in the memory (14).

2. The method according to claim 1, characterized in that each memory block (52.x, 52.x '), to which an entry of a program in the file system (38, 38') refers, at its limits with the limits of page frames (50. x, 50.x ') in the memory (14) which are predetermined by the memory management unit (28).

3. The method according to claim 1 or claim 2, characterized in that the memory blocks (52.x) in which the programs entered in the file system (38) are stored in one raster area (48) separate from the file system (38) are contained.

4. The method according to claim 1 or claim 2, characterized in that the file system (38 ') contains the memory blocks (52.x ¹ ) in which the programs entered in the file system (38') are stored.

5. The method according to any one of claims 1 to 4, characterized in that the file system (38, 38 ') at least one data structure, in particular a directory (40, 40') or a file (42, 44, 46, 42 ' , 44 ', 46'), whose position in the memory (14) is independent of the page frames (50.x, 50.x ¹ ) specified by the memory management unit (28).

6. The method according to any one of claims 1 to 5, characterized in that each entry of a program in the file system (38, 38 ') is a regular file (42, 6, 6').

7. The method according to any one of claims 1 to 6, characterized in that information about free and occupied page frames (50.x, 50.x ') are stored in a block allocation table (54, 54').

8. The method according to any one of claims 1 to 7, characterized in that the corresponding entry in the file system (38, 38 ') is evaluated for executing a program, and that on the basis of the references contained in the entry (56.x, 56. x ') the memory management unit (28) in such a way to build a Virtual address space is configured so that the program is executed at the locations in the memory (14) indicated by the entry.

9. The method according to any one of claims 1 to 8, characterized in that the data carrier (10) has a UNIX-like operating system (24), in particular a Linux operating system.

10. Portable data carrier (10), in particular chip card or chip module, which has at least one memory (14) and a processor (12) with a memory management unit (28), the processor (12) for executing programs that are in the Memory (14) are included, using the memory management unit (28) is able to access the memory (14), characterized in that the memory (14) furthermore has a file system (38, 38 ') in which at least some of the programs are entered are, whereby an entry of a program in the file system (38, 38 ') contains at least references (56.x, 56.x') to memory blocks (52.x, 52.x ') in which the program is stored (14), and the memory blocks (52.x, 52.x ') in their position in the memory (14) with the page frames (50.x, 50.x') specified by the memory management unit (28) of the memory (14 ) are compatible to the processor (12) the execution of the program to the by the entry in the date Isystem (38, 38 ') specified locations in the memory (14).

11. Portable data carrier (10) according to claim 10, characterized in that the memory (14) further contains program instructions, which cause the processor (12) to carry out a method according to one of claims 1 to 9.

12. Computer program product which has machine-readable program instructions for a processor (12) of a portable data carrier (10), which cause the processor (12) to carry out a method according to one of claims 1 to 9.