GB2456134A

GB2456134A - Typed application development

Info

Publication number: GB2456134A
Application number: GB0725382A
Authority: GB
Inventors: James Steele
Original assignee: Nokia Oyj; Symbian Software Ltd
Current assignee: Nokia Oyj
Priority date: 2007-12-31
Filing date: 2007-12-31
Publication date: 2009-07-08
Also published as: GB0725382D0; WO2009083734A1

Abstract

A method of developing a typed executable file comprises the steps of producing a file, determining if a stability point has been reached and then verifying the file. The stability point is reached when the file is considered immutable, trustworthy or when it is ready for transport to a device on which it is to be installed. The stability point may also include determining whether it can be included in a ROM image for a computing device. The computing device is mobile device, preferably a computer program. The verification step may be carried out by an installation program or as part of a security enforcement process. In another embodiment a list of files is maintained along with an indication of whether the file is typed or untyped. In a further embodiment the executable file is a related to an associated file in a remote store that contains typing information. In a yet further embodiment, the verification system operates on an executable file that has a data portion and a typing portion wherein the typing portion is used to verify the file and is held remotely from the data portion.

Description

TYPED APPLICATION DEPLOYMENT

TECHNICAL FIELD

This invention relates to the deployment of computer readable code and, in particular, to the deployment of computer readable code in the form of typed applications.

BACKGROUND TO THE INVENTION

Multitasking operating systems run two or more processes by allocating alternating processing cycles to the processes at a speed unobservable to the user so that the processes appear to be running simultaneously.

A process may comprise one or more series of instructions (or code'), a series of instructions being termed a thread'. However, the procedure of switching execution from one thread to another (termed context switching') can cause problems and is time consuming, particularly where the processes share memory resources or access memory resources used by the kernel. In particular, the concept of "process isolation" is used to describe the extent to which processes of a particular system may avoid sharing memory resources and the extent to which the effects of the behaviour of one process may be isolated from other processes.

Often, when switching contexts, it is necessary to manage memory allocation for different threads. This management can involve the flushing and invalidating of the Memory Manager Unit (MMU) mappings and the flushing of caches, a process which is relatively time-consuming. By way of example, it has been found that the process of switching the user-mode address space may require more than 100 milliseconds in the ARMv5 processor.

Process isolation is desirable in that it reduces these overheads. Furthermore, process isolation protects integrity and prevents security breaches, for example through buffer overflows.

Traditionally, processes have been isolated by only allowing processes to access certain pages of physical memory and by preventing untrusted code from accessing system resources such as the MMU or interrupt controllers. This approach suffers from the disadvantages however that exception handling is slower under these constraints, as are translation lookaside buffer lookups and reloads. For larger applications it has been found that the performance costs are too great to strictly enforce process isolation using this traditional approach.

l'here are a number of more recent known approaches to isolating processes. In a hardware approach, the MMU defines a number of memory domains where access is controlled according to the addresses defining these domains. These domains prevent processes from accessing memory belonging to other processes.

A second approach to isolating processes is a software-based approach which relies on verifying the safe behaviour of executable code and whether the corresponding process is capable of being isolated (i.e. whether the process is "safe" or not). Verification will determine whether the process is capable of being isolated and will not access memory belonging to another process or to the kernel. The difficulty when using this approach lies in being able to verify any particular application.

According to one known software related approach, programming languages are used which provide a method of verifying the safety of a program. Languages such as Java and C#, for example, provide the safety verification needed at both compile-time and run-time.

A further software related approach to isolating processes involves the provision of typed languages. For example, Typed Assembly Language (TAL) provides an assembly language with a method of denoting, in the executable file, the data type of each value that is manipulated by any application specified in that language. By including the data type with the application, the safety of the application may be verified without the need for additional run-time verification.

Proof Carrying Code (PCC) is a software mechanism where the executable code includes a formal proof of specific behaviours of the code. This too can provide compile-time verification without the need to provide additional run-time verification.

Languages such as TAL and PCC, which obviate the need for both run-time and compile-time verification, are herein referred to as "typed" languages and the corresponding executable files as "typed" executable files.

"Deconstructing Process Isolation" by M. Aiken, M. Fähndrich et al, Microsoft Research Technical Report MSR-TR-2006-43, discusses the aforementioned known approaches to process isolation.

The current use of typed languages for process isolation suffers from two disadvantages. Firstly, the inclusion of the type increases the size of the resulting executable file and secondly, the time taken to verify a typed executable file is non-negligible.

In addition to the aforementioned uses of typed files, such files advantageously provide improved security as the typing information may be used to detect unauthorised alterations to the executable file or detect malicious executable files such as viruses.

It is desirable to reduce the size of the executable files produced from a typed language.

It is further desirable to reduce the time and resources needed to verify typed

executable files.

SUMMARY OF THE iNVENTION

According to a first aspect, the invention provides a method of developing a typed executable file which includes the steps of: (a) producing a typed executable file; (b) determining a stability point when the typed executable file may be considered immutable; and (c) verifying the typed executable file at any time after the stability point has been reached.

By determining a point in time, the stability point, after which it is unlikely that the typed executable file will undergo further alteration, the invention provides a method which allows a reduction in the number of times a typed executable file needs to be verified. In particular, if the typed executable file is produced according to this aspect of the invention, it is not necessary to repeat the verification process once the stability point has been reached.

This aspect of the invention has a number of advantages. Firstly, it is generally more efficient if the verification of an executable file need only be performed once. Secondly, where a single verification is required, the information used in the verification may be moved after the verification has been performed (e.g., by being deleted).

The stability point may be a point in the life cycle of the executable file. For a particular device, the stability point may be taken as constant for all executable files to be installed on that device. Alternatively, the stability point may be set for each executable file individually or the same stability point may be applied to a group of executable files.

The step of determining the stability point may include the step of determining when said executable file may be considered trustworthy.

The step of determining a stability point may include the step of determining when the typed executable file is ready for transport to a computing device upon which said executable file is to be installed.

The step of determining a stability point may include the step of determining when the typed executable file is ready for inclusion in a ROM image for a computing device.

ROM images are used in both "closed" and "open" systems where an "open" system is one where additional executable files may be added by a user and a "closed" system is one where all of the executable files are determined at the time the system is compiled.

Alternatively, the stability point may be taken as the point at which the typed executable file is ready to be installed on a computing device. In this instance, the invention is applicable to open systems and, in particular, to the executable files later added by users of the system.

Preferably, where the stability point relates to an open system, the step of verifying said executable files is carried out by an installation program.

The step of verifying said executable file may include the step of determining whether a process corresponding to the typed executable file is capable of being isolated.

Preferably said step of verifying said typed executable file is carried out once and only once for each executable file on a computing device.

As stated, the typed executable file includes typing information and, once the executable file has been verified, the typing information may be discarded or deleted as this information is no longer required, in view of the fact that it has been determined that the executable file is now considered immutable.

The step of verifying said typed executable file may be carried out as part of a security enforcement process. In this instance, the typing information is advantageously used to determine the trustworthiness of the executable file and is additional used to verify the

executable file.

The method may include the additional step of storing a result of said verification process. Preferably the result of said verification process is an indication of whether the executable file is safe or not.

According to a further aspect, the invention provides for a typed executable file comprising typing information wherein said typing information is encoded as part of an executable file representation of the typed executable file. Preferably, the typing information is stored in compressed form. The typing information may be encoded in an executable file image header.

The typing information may be accessed through a Uniform Resource Identifier (URI).

According to a further aspect, the invention relates to a method of maintaining a computing system, the computing system comprising both typed and untyped executable files, wherein the method includes the steps of: (a) maintaining a list of executable files installed on the system; and (b) including with said list an indication of whether a corresponding executable file is typed or untyped.

The system is able to determine, by reference to the list, whether a particular executable file is a typed or an untyped executable file and manage the memory allocation accordingly. Such a list may be used in applying executable files according to the aforementioned aspect of the invention to existing mobile computing devices to ensure that both typed and untyped executable files run on the same computing device. In general, a system according to a preferred embodiment of the invention is able to execute a mixture of typed and untyped applications.

According to a further aspect, the invention provides a file comprising a set of computer readable instructions and typing information relating to said instructions, said typing information being located remote from said instructions. By locating the instructions remote from the typing information, memory usage for a particular device may be reduced as only the data portion need be stored on that device.

The typing information may be accessed through a Uniform Resource identifier (URI). The file may further comprise data.

According to a further aspect, the invention provides for a verification system for an executable file, the executable file having a data portion and a typing portion, wherein said typing portion may be used to verify said data portion, and wherein said typing portion is maintained at a location remote from said data portion, the verification system being adapted to access said typing information and, on the basis of said typing information, to verify said

executable file.

According to a further aspect, the invention provides for an operating system arranged to cause a computing device to operate according to the method herein described.

According to a further aspect, the invention provides for a computer readable medium comprising instructions for directing a computer to perform the method herein described.

According to a further aspect, the invention provides for a computer program or a suite of computer programs suitable for causing a computing device to operate in accordance with the method herein described.

BRIEF DESCRIPTION OF THE DRAWINGS

Preferred embodiments of the invention will now be described with reference to the accompanying drawings, in which: Figure 1 is a schematic diagram of a mobile computing device; Figure 2 is a schematic diagram of the mobile computing device of Figure 1 connected to a further computing device; Figure 3 is a schematic drawing of components of the mobile computing device of Figure 1; Figure 4 is a schematic diagram of application development and deployment; Figure 5 is a flow diagram of a preferred embodiment of the invention; Figure 6a is a schematic illustration of a typed executable file according to an embodiment of the invention; Figure 6b is a schematic illustration of the typed executable file of Figure 5a after modification; and Figure 7 is a schematic illustration of a verification system according to a preferred embodiment of the invention.

DESCRIPTION OF PREFERRED EMBODIMENTS

Figure 1 illustrates a mobile computing device 10 having a casing 12. The casing 12 encapsulates a keypad 14, a screen 16, a speaker 18 and a microphone 20. The device 10 further includes an antenna 22. The mobile computing device operates as a telephone and as a computer in a manner known in the art and is capable of running computer programs. As used herein a computer program will be referred to as an "application". It is to be realised however that the term "application" is intended to refer to any code capable of affecting the operation of a computing device. The associated file type will be referred to herein as an executable file although a single computer program may comprise one or more executable files.

Executable files to be run on the mobile computing device 10 are generally produced on another computing device and then transported to the computing device 10. Figure 2 illustrates one example where executable files are produced on a further computing device, computer 20, and transported to mobile computing device 10. As illustrated, the executable files may be transported to mobile device 10 by means of a wired connection 26 or a wireless connection 24.

Figure 3 is a schematic illustration of certain components of the mobile computing device 10. Device 10 includes a kernel 70 which represents the operating system of the device 10. In the embodiment shown, the operating system is the Symbian operating system produced by Symbian Software Ltd., U.K. The kernel 70 is connected to a volatile system memory 72 which is controlled by means of a memory management unit 74, which is a part of the kernel 70. Device drivers 76, 78 and 80 are connected to kernel 70 and control the behaviour of, and communication with, respective devices: keyboard 82, network card 84 arid monitor 86. It is to be realised that the mobile computing device 10 includes many more devices and components than those illustrated here. The network card 84 facilitates communication with other computing devices such as computer 20 by means of wired connection 26 and is one of the ways in which the mobile computing device 10 receives data from external sources.

The device 10 includes typed applications 88 which communicate with the kernel 70 and untyped applications 90 which also communicate with the kernel 70. The typed applications are specified using a typed language. In the embodiment shown, the Typed Application Language (TAL) has been used, although other typed languages such as Proof Carrying Code (PCC) may be used instead.

The device 10 further includes a verification application 89 which acts to verify typed executable files in the manner described below.

The kernel 70 controls the system memory 72 and the devices 82, 84 and 86 (by means of device drivers 76, 78 and 80) in a known manner. In this embodiment of the invention, the kernel 70 accesses a typing list 92 which lists the typed and the untyped applications of the device 10 together with an indication of whether the application is typed or untyped.

According to an embodiment of the invention, a stability point is identified in the development and deployment of a typed application 88 (Figure 3) at which time the application may be considered immutable. Although changes to an application are always possible in that the application may be erased and replaced by another version, or may be updated, such changes take place within the trusted deployment environment in a controlled manner. Therefore, identifying the stability point involves identifying that point in the life cycle of an application when the development has ceased and the application may be considered ready for deployment as the application is now relatively immitable. In other words, this involves determining a point during the life cycle of the application when the application may be trusted.

It will be realised that drawing a distinction between trusted and untrusted aspects of the life cycle of an application will depend on the manner in which the particular application has been deployed and developed, as well as depending on practical considerations such as: to what extent a particular application developer or communication channel may be trusted and designating an environment or communication channel with known vulnerabilities as trusted.

Figure 4 is a general illustration of the portions of the life cycle of the typed 88 and untyped 90 applications of Figure 3 including development and subsequent deployment of the applications. During the development phase 30, which occurs on computing device 20 of Figure 2 in this embodiment, the application is specified using a computer language which is then compiled to produce the typed or untyped executable file. As mentioned, an application may comprise a number of executable files and data files, all of which are packaged together.

Once the application has been developed and is ready for use, the executable file is deployed (together with any other necessary files) in deployment stage 32. Generally, deployment stage 32 involves the transport of the executable file to the mobile computing device 10 and the installation on the device in such a manner that the mobile computing device 10 is able to run the corresponding application. This last step is referred to as the installation of the application.

Both the development and the deployment stages will vary significantly depending on a range of factors such as: the computer language used to develop the application, the complexity and functionality of the application, the data files needed for the application to operate, the manner in which the executable file of the application is transported to the mobile computing device 10, the manner in which the application is installed on the mobile computing device.

Regardless of the variation in the development and deployment of the application, the development stage 30 is distinguished from the deployment stage 32 in this embodiment of the current invention in that an application is only considered as trusted once it enters the deployment stage 32 (as illustrated in Figure 3). The term "trusted" refers to the fact that the environment in which the application is developed is less trustworthy than the environment in which the application is deployed.

In this embodiment, the stability point is considered as the line 3 1 between development and deployment. The line 31 represents the point in the life cycle of this application where the contents of the executable file can be considered trustworthy.

However, in other embodiments, or for other applications, or groups of applications, the point at which the content of the executable file is to be considered trustworthy may correspond to the point when the executable file is created. In other instances, the stability point may correspond to the time in the life cycle of the application when the application is ready to be installed (therefore excluding any transport of the executable file).

Various policies for declaring the stability point may be implemented. In one embodiment, the same policy for determining the stability point is used for all applications running on a given device. In an alternative embodiment the stability point is set according to an application classification. In this embodiment, applications are classified as either trustworthy (in which case the stability point is set at the time when the executable file is created), or as untrustworthy (in which case the stability point is set at the point the corresponding executable file is installed on the device).

Figure 5 is a flow diagram illustrating a method of a preferred embodiment of the invention. This represents the process whereby any of the typed applications 88 are installed onto device 10 of Figure 3, for example. Step 40 represents the development of the application, as well as any transport of the corresponding executable file, up to the point where the executable file of the application may be considered as trusted. At point 42 a stability point is determined as described above with reference to Figure 4. As previously stated, the stability point will depend on the particular development process involved and will depend on a number of factors such as the trustworthiness of the development process. The stability point is set at a time in the development and deployment process at which it is considered that the risks of the application changing are considered acceptable. In the current embodiment, the stability point is set at that time in the development process when it is determined that it is unlikely that the executable file will undergo any changes, i.e. when the executable file is in a form in which it is ready to be installed.

Once the stability point has been set at step 42, the executable file or files of this application are verified to determine whether the application is safe, i.e. whether the processes of the application, when run, are capable of being isolated. With reference to Figure 4, this represents the end of the development process 30 occurring on computing device 20. The resulting executable file is then transported to mobile computing device 10 by means of the wired connection 26 which connects to the network card 84 (Figure 3).

With reference to Figure 3, in this embodiment, the executable file is received by means of the network card 84. The verification step 44 is carried out by the verification application 89. As part of the verification step 42, the verification application 89 updates the typing list 92 with an entry containing an identifier for the application as well as an indication that the executable file for this application is a typed executable file. The verification application 89 further includes an indication of whether the process of the application, when run, will be safe with the entry in the list 92 for this application.

After the application has been verified as safe or not, at step 46 the executable file is modified by deleting the typing information. However, step 46 is an optional step which will depend on the scarcity of storage space in the device concerned. It is possible to delete the typing information due to the previous determination of the stability point rendering future validation of the executable file unnecessary and retention of the typing information optional.

In an alternative embodiment, the executable file is modified by first copying the typing information to a remote location, such as computing device 20 (Figure 2), and then deleting this typing information from the executable file.

In step 48, the executable file is installed in the mobile computing device 10. This installation process may also occur in a number of different ways. For example, the executable file may be installed by copying it onto a ROM image which is then installed in the device 10. Alternatively, the executable file is installed by means of an installation application. It is to be realised that where an installation application is used, the installation application will incorporate the verification application 89 and, in this instance, the verification application will not be provided integrated with device 10.

In the embodiment illustrated, the typing list 92 maintains a list of each of the applications 88 and 90 installed on the device 10. Therefore, when an application is installed on the device 10, a corresponding entry will be made in the typing list 92. Similarly, when an application is deleted from the device 10, the corresponding entry in the typing list 92 will be removed.

Certain of the typed 88 and the untyped 90 applications will be installed in the device 10 during a manufacture process. The manufacturer will therefore know which applications are typed and which are untyped and appropriate entries will be made in the typing list 92 when the ROM image for the device 10 is compiled. Other of the typed 88 and the untyped applications wilt be installed during use of the device 10 (i.e. after manufacture). When an application is installed, the installation program will verify the application as described above and update the list 92 with an identifier for that application together with an indication of whether that application is typed or not. The information regarding whether the application is safe or not is also included in the list 92.

When the application is run by the device 10, the MMU will access the list 92 and organise the memory in the manner described. Due to the fact that the MMU is now aware of how certain of the processes will behave when executed, the MMU is able to reduce the number of instances in which the cache need be cleared and the MMU mappings and need be invalidated, therefore improving the speed with which the processor of the device is able to switch between execution of threads belonging to different processes.

Where the device 10 comprises both typed and untyped applications, the memory management unit 74 is able to arrange and organise the memory by partitioning the memory appropriately when processes corresponding to both typed and untyped executable files are running. In the embodiment shown, the MMU will partition the memory into at least two domains and the first of these domains will be used to run applications corresponding to typed executable files. The second of these domains will be used to run applications corresponding to untyped executable files. Therefore, any switching between threads belonging to typed executable files will occur quickly and the device 10 will operate more quickly than a corresponding device running only applications corresponding to untyped

executable files.

Figure 6a illustrates a typed executable file 50 according to an embodiment of the invention. The typed executable file 50 includes a header portion 52 and a data portion 54.

The header portion 52 includes the typing information pertaining to the data portion 54. In this embodiment the header information, which includes the typing information, is compressed. In the embodiment shown, the header information has been compressed by use of the LZW algorithm, but in further embodiments any suitable compression algorithm may be used.

Figure 6b illustrates the executable file 50 after undergoing the modification step 46 when the process of Figure 4 is applied to the typed executable file 50 of Figure 5a. In this embodiment, the modification which the executable file has undergone comprises the separation of the header portion 52 from the data portion 54. Once the header 52 containing the typing information has been separated from the data 54, the data may be installed on the computing device 10 and the application of the data will operate in a normal manner. By separating the header 52 and the data 54, the size of the executable file is reduced, resulting in the utilization of less storage space. It is to be realised however that the separation of the header portion from the data portion 54 may occur at any point, and need not occur after validation.

In a further embodiment, the header 52 is separated from the data 54 in the executable file 50 prior to the step of verification. As the header containing the typing information is separate from the data, the verification process will operate remotely with respect to this embodiment.

Figure 7 illustrates a verification system comprising a verification application 64 in communication with a data portion 60 of an executable file and in communication with a header portion 62 of the same executable file. In this embodiment, the data portion 60 is stored remotely from the header portion 62, on a separate device. Furthermore, the verification application 64 operates on an independent computing device. Therefore, the communication between the verification application 64 and both the data 60 and the header 62 occurs by means of TCP/IP communications (although it is to be realised that other forms of communication may alternatively be used). In order that the data portion 60 and the header portion 62 may be located, their respective locations are specified by means of Uniform Resource Identifiers (URI).

The verification application 64 verifies the data portion 60 of the executable by accessing the header portion 62 in a known manner.

With reference to Figure 2, the data portion 60 may be stored on mobile computing device 10 and the header portion 62 on the computer 20 (both on appropriate storage devices associated with the respective computing devices). The verification application may reside on either the mobile computing device 10 or on the computer 20. Alternatively, the verification application resides on a further computing device connected to the mobile computing device 10 where the data portion is stored and to the computer 20 where the header portion is stored. In this embodiment, the verification application will communicate with the header portion 62 and the data portion 60 by means of a computer network.

Claims

Claims 1. A method of developing a typed executable file which includes the steps of: (a) producing a typed executable file; (b) determining a stability point when the typed executable file may be considered immutable; and (c) verifying the typed executable file at any time after the stability point has been reached.
2. The method according to claim 1 wherein said step of determining the stability point includes the step of determining when said executable file is to be considered trustworthy.
3. The method according to claim I or claim 2 wherein the step of determining a V stability point includes the step of determining when the typed executable file is ready for transport to a computing device upon which said executable file is to be installed.
4. The method according to claim I or claim 2 wherein the step of determining a stability point includes the step of determining when the typed executable file is ready for inclusion in a ROM image for a computing device.
5. The method according to claim I or claim 2 wherein the step of determining a stability point includes the step of determining when the typed executable file is ready to be installed on a computing device.
6. The method according to claim 5 wherein said step of verifying said typed executable file is carried out by an installation program and wherein installation of said executable file is performed by said installation program.
7. The method according to any one of claims 4 to 6 wherein said computing device is a mobile computing device.
8. The method according to claim 7 wherein said mobile computing device comprises a phone.
9. The method according to any preceding claim wherein said typed executable file is verified once and only once.
10. The method according to any preceding step wherein said step of verifying said executable file includes the step of determining whether a process corresponding to said typed executable file is capable of being isolated.
11. The method according to any preceding claim wherein the step of verifying said typed executable file is carried out as part of a security enforcement process
12. The method according to any preceding claim which includes, after the step of verifying the typed executable file, the step of removing a typing information from said typed

executable file.
13. The method according to any preceding claim further comprising the step of storing a result of said verification process.
14. The method according to claim 13 wherein the result of said verification process is an indication of whether the executable file is safe or not.
15. A method of maintaining a computing system, the computing system comprising both typed executable files and untyped executable files, wherein the method includes the steps of: (a) maintaining a list of executable files installed on the system; and (b) including an indication with said list of whether a corresponding executable file is typed or untyped.
16. The method according to claim 15 including the additional step of including with said list safety-related information regarding whether a typed application is safe or not.
17. The method according to claim 16 further comprising the step of managing a memory according to the safety-related information of said list.
18. An executable file comprising typing information wherein said typing information is encoded as part of an executable file.
19. The executable file according to claim 18 wherein said typing information is stored in compressed form.
20. The executable file according to claim 19 further comprising computer instructions and data.
21. A file comprising a set of computer readable instructions and typing information relating to said instructions, said typing information being located remote from said instructionS.
22. The file according to claim 21 wherein said typing information may be accessed through a Uniform Resource Identifier (URI).
23. The file according to claim 21 or claim 22 further comprising data.
24. A verification system for an executable file, the executable file having a data portion and a typing portion, wherein said typing portion may be used to verify said data portion, and wherein said typing portion is maintained at a location remote from said data portion, the verification system being adapted to access said typing information and, on the basis of said typing information, to verify said executable file.
25. The verification system according to claim 24 wherein said verification system is adapted to establish whether a typed application is safe or not.
26. The verification system according to claim 25 further comprising means for removing said typing portion after said executable file has been verified.
27. An operating system arranged to cause a computing device to operate according to the method of any one of claims 1 to 14.
28. A computer readable medium comprising instructions for directing a computer to perform the method of any one of claims Ito 14.
29. A computer program or a suite of computer programs suitable for causing a computing device to operate in accordance with the method of any one of claims 1 to 14.