Electrical computers and digital processing systems: memory – Storage accessing and control – Control technique
Reexamination Certificate
1999-06-04
2002-12-17
Kim, Matthew (Department: 2186)
Electrical computers and digital processing systems: memory
Storage accessing and control
Control technique
C711S103000, C711S104000, C711S127000, C711S157000, C711S220000
Reexamination Certificate
active
06496910
ABSTRACT:
FIELD OF THE INVENTION
The invention relates to a method and a device for loading instruction codes to a memory and linking said instruction codes. More particularly the invention relates to a combined loading and linking method in a resource-constrained environment such as a smartcard, particularly a smartcard offering a Java environment, such as a Javacard.
BACKGROUND OF THE INVENTION
When loading and linking machine-dependent, size-efficient code for execution in any resource-constrained code execution environment, in all settings where only parts of the overall executable object code are present during compilation, it is necessary to perform a final step of relocation or ling in which as yet unresolved references to external symbols, e.g., functions, variables, or classes, are replaced by actual addresses valid only in the particular execution context. The linkage information is kept separate from the code in the systems where this approach to code development and installation is commonly used, e.g., personal computers, workstations, or cross-development environments for embedded systems.
In environments, where the resources of computing time, communication bandwidth, and transient memory (RAM) are scarce, and where in addition, writing to persistent memory is much more expensive than writing to temporary memory, and where finally no assumptions about the integrity of the communications infrastructure can be made, new problems appear. In particular, time-efficient ways are to be found to load the code and linkage information into the runtime environment in a secure manner ensuring confidentiality and integrity of the data loaded.
The initial setting where these assumptions hold true, are smartcards that are to be updated after they have been issued to the customer. In particular, multifunction cards or JavaCards need an efficient resolution of this issue. Therefore, the term ‘JavaCard’ is used in the following sections inclusively, but not exclusively to denote environments of the nature outlined above.
The first problem is the overall time required to load code and linkage information into the smartcard, perform cryptographic decryption and integrity checks on the smartcard over the loaded data, and finally relocate the newly loaded code to prepare it for execution. The second major issue is the amount of temporary data requited to perform the above operations.
In conventional systems, the relocation information comprises a fix-up information and an address information. The fix-up information points to the address place after an instruction code, which instruction code has an address as a parameter to be determined during linking. The address information contains an offset and a package ID, in the case where the relocation type indicates that the address lies in a package different from the package where the address-parametered instruction code lies. A package id (also called “AID”), serves as the denominator for the starting address, hence designating a package whose starting address is to be used. In the case when the package wherein the address is located is the same package as where the address-parametered instruction code lies, the starting address is already known as the starting address of this package. The address is then determined as the starting address plus the offset. Taking the peculiarities and limitations of smart cards into account, the following basic steps are thus performed to load new executable code into a JavaCard:
Receive the code into a RAM and transfer it to a persistent memory, e.g. an EEPROM.
Receive the linkage information (fix-up information and relocation tables) into the RAM and transfer it to persistent memory.
Optionally, perform decryption and cryptographic integrity checks, commonly known as MACing, of code and linkage information.
valuate the linkage information and, for each relocation entry, determine the fix-up address and according to the relocation type, compute the actual reference address and write this reference into the appropriate fix-up address in the persistent memory.
Remove the linkage information from the persistent memory to make room for further code to be loaded in the future.
This approach however, has the drawback that by performing the cryptographic operations after all data has been loaded, an inefficient number of memory copy operations has to be executed, as those operations can only be run efficiently in RAM.
By placing linkage information into persistent memory, mainly for reasons of ease of decryption and MACing purposes, a big performance penalty has to be paid, as this data has to be deleted afterwards anyway, which in itself is another expensive write operation on persistent memory.
By performing relocation after the complete code has been loaded into persistent memory, another performance penalty is incurred, since writing single bytes to persistent memory is as expensive in terms of time as writing several bytes, namely a page.
It is an object of the invention to provide a method and a device for loading instruction codes to a memory and linking said instruction codes, which takes fewer writing cycles to a memory with a relatively high write-access time. This includes the advantage that the result of a completely loaded and linked instruction code sequence is achievable aster and that the lifetime of the device is extended since due to a limited rewritability, the number of write accesses to the same memory is limited also. The effect is further improved by exploiting the effect that a write cycle to an EEPROM for 1 byte takes the same time as does a write cycle for several bytes, i.e. an EEPROM page, e.g. 64 bytes. During the conventional linking procedure, each linking step for each address needs one memory write-access, which with view to the above fact is a waste of access time. The invention exploits to a much higher degree the writing capability of each write-cycle. To this adds that an eventual decryption, using a streaming cipher and/or integrity-check can be performed also without prior writing to the EEPROM.
Furthermore, it is an object of the invention that the amount of data needed for achieving the linking is reduced in size. The amount of data to be sent to the execution environment is smaller as compared to a format where code and relocation information is not interleaved, but strictly separated. In a setting, where first the code and afterwards the relocation information is sent, it is necessary to add to each relocation entry the information for which code address the respective relocation information is valid. This so-called fix-up information is completely made obsolete by the method presented in this disclosure. Net result is a significant reduction in the amount of data sent to the execution environment, in turn leading to a reduction of the overall time necessary to execute the upload process, significantly so, if the communications speed to the execution environment is low.
Another object of the invention is to provide distinction information enabling a distinction between the instruction codes and the relocation information facilitates access to the relocation information. Using code length information which is loaded before each set of code containing the address-parametered instruction code is advantageous since immediate information is accessible for recognizing the relocation information. Furthermore the code length information can then be erased, respectively overwritten during the lining process which again saves memory space.
Still another object of the invention comprises locating the relative address offset at the address place during the loading step saves memory space because the address place is loaded as a reserved space and is only filled up with insignificant content such as zero values which take up the same space as does the address place filled with the offset value. It proves of advantage when, in the case when the address to be determined is located in a package which is different from the package location of the address-parametered instruction code, the start
Baentsch Michael
Buhler Peter
Eirich Thomas
Hoering Frank
Oestreicher Marcus
Anderson Matthew D.
Dougherty Anne Vachon
Herzberg Louis P.
Kim Matthew
LandOfFree
Method and device for loading instruction codes to a memory... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Method and device for loading instruction codes to a memory..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and device for loading instruction codes to a memory... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2954547