US20060026126A1

US20060026126A1 - Method and system for making a java system call

Info

Publication number: US20060026126A1
Application number: US11/189,245
Authority: US
Inventors: Gilbert Cabillic
Original assignee: Texas Instruments Inc
Current assignee: Texas Instruments Inc
Priority date: 2004-07-27
Filing date: 2005-07-26
Publication date: 2006-02-02
Also published as: US20060023517A1; US20060026574A1; US20060026395A1; US20060026312A1; US20060026322A1; US7587583B2; US20060026200A1; US7930689B2; US20060025986A1; US20060026394A1; US20060026183A1; US20060026201A1; US20060026400A1; US7546437B2; US20060026391A1; US7543285B2; US20060026401A1; US20060026566A1; US7624382B2; US7743384B2

Abstract

A method and system of executing a system call in an object oriented programming language such as Java™. At least some of the illustrative embodiments may be system and method of creating a first package comprising a first inaccessible method and a second package comprising a second method, initiating a native system call, invoking the first inaccessible method from a second method via the native system call, and returning a result to the second method. Invoking the first method further comprises checking a right of access to the first inaccessible method according to a security policy, and invoking the first inaccessible method in place of execution of the second method if access is permitted according to the security policy. An exception is generated if access to the first inaccessible method is not permitted according to the security policy.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of European Patent Application No. 04291918.3, filed Jul. 27, 2004, incorporated by reference herein as if reproduced in full below.

BACKGROUND OF THE INVENTION

Mobile electronic devices such as personal digital assistants (PDAs) and digital cellular telephones increasingly include applications written in the Java™ programming language. Each application is represented by a set of accessible Applications Programming Interface (“APIs”). In execution, such a Java™ application may need to access APIs representing a different application, including those of the operating system.
Due to constraints of object oriented programming languages such as the Java language, applications may be isolated from each other such that they do not share methods kept separate by defined access levels. For example, the Java Virtual Machine (“JVM”) does not allow direct access to individual memory addresses of the underlying system, preventing potentially untrustworthy code from interfering with the native hardware and operating system.
Various operating systems provide the means for an application to access another application. Specifically, an application may access methods of another application (or the operating system), subject to more restricted access than those methods to which the application has access. This type of access is referred to as a system call.
In an operating system such as UNIX, a system call cannot be called directly from a user process. Instead, system calls are made indirectly via an interrupt and look-up in an interrupt table. System calls often use a special machine code instruction which causes the processor to change mode (e.g. to “supervisor mode” or “protected mode”), allowing the operating system to perform restricted actions such as accessing hardware devices or the memory management unit.
Currently, there are no efficient ways of performing a system call in some object-oriented programming languages, such as Java™. It is thus desirable to perform system calls between applications in an operating system programmed in an object-oriented language such as Java™.

SUMMARY

The problems noted above are solved in large part by a method and system of making a Java system call to enable access with security policy checking of a higher privilege code section. At least some of the illustrative embodiments may be a method of making a Java system call, comprising creating a first package comprising a first method inaccessible to packages other than the first package and a second package comprising a second method, invoking the first inaccessible method from a second method, wherein a right of access to the first inaccessible method is checked according to a security policy, and returning a result of invoking the first inaccessible method to the second method.
Some illustrative embodiments are for a computer-readable medium storing a Java program that, when executed by a processor, performs a method comprising creating a first package comprising a first method inaccessible to packages other than the first package and a second package comprising a second method, invoking the first inaccessible method from a second method, wherein a right of access to the first inaccessible method is checked according to a security policy and returning a result of invoking the first inaccessible method to the second method.
Other illustrative embodiments are a system comprising a processor, a virtual machine (“VM”) configured to execute on the processor, and a Java software program configured to execute on the VM, wherein the Java software program is configured to create a first package comprising a first method inaccessible to packages other than the first package and a second package comprising a second method, invoke the first inaccessible method from a second method, wherein a right of access to the first inaccessible method is checked according to a security policy, and return a result of invoking the first inaccessible method to the second method.

NOTATION AND NOMENCLATURE

Certain terms are used throughout the following description and claims to refer to particular system components. As one skilled in the art will appreciate, semiconductor companies may refer to a component by different names. This document does not intend to distinguish between components that differ in name but not function. In the following discussion and in the claims, the terms “including” and “comprising” are used in an open-ended fashion, and thus should be interpreted to mean “including, but not limited to . . . ”. Also, the term “couple” or “couples” is intended to mean either an indirect or direct connection. Thus, if a first device couples to a second device, that connection may be through a direct connection, or through an indirect connection via other devices and connections.
A “method,” as used with respect to the Java programming language, is a collection of Java statements that can be invoked by other Java code. When a method is invoked, parameters known as arguments may be passed to the method. The method performs some computations and may optionally return a value.
A “class,” as used with respect to the Java programming language, is a collection of fields that hold data values and methods that operate on those values. A class may also contain nested inner classes. Classes are the fundamental structural element of Java programs. Java statements appear within methods, and methods are defined within classes.
A “package,” as used with respect to the Java programming language, is a named collection of classes. A package may also include sub-packages. Packages serve to group related classes and define a namespace for the contained classes.
As part of security built into the Java programming language, each entity—including methods and primitive data elements—has an access level associated with it. The access level may be “public,” indicating that the entity can be accessed by code in any class. The access level alternatively may be “private”, meaning that the entity can only be accessed by code that is contained within the class that defines the entity, or another access level: “default,” such that the entity can be accessed by code that is contained within the class that defines the entity, or by a class that is contained in the same package as the class that defines the entity. An additional access level is “protected” meaning that the entity may be accessed by a separate package, because a protected method of a class of package 1 may be inherited by a class of a separate package. “Final protected” indicates the access level meaning that the entity can only be accessed by code that is contained within the class that defines the entity, or by classes within the same package as the defining class, because the keyword final means that a method cannot be inherited.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more detailed description of the preferred embodiments of the present invention, reference will now be made to the accompanying drawings, wherein:
FIG. 1 shows a diagram of a system in accordance with embodiments of the invention;
FIG. 2 shows an illustrative block diagram of the Java Stack Machine of FIG. 1 in accordance with embodiments of the invention;
FIG. 3 illustrates a flow diagram of a method in accordance with embodiments of the invention; and
FIG. 4 depicts an illustrative embodiment of the system described herein.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The following discussion is directed to various embodiments of the invention. Although one or more of these embodiments may be preferred, the embodiments disclosed should not be interpreted, or otherwise used, as limiting the scope of the disclosure, unless otherwise specified. In addition, one skilled in the art will understand that the following description has broad application, and the discussion of any embodiments is meant only to be exemplary of those embodiments, and not intended to intimate that the scope of the disclosure, is limited to those embodiments.
According to security constraints of the Java language, each package may freely invoke the methods within the package, and may access methods of other packages when the access right for those methods is “public” or “protected” if the class defining the method is inherited. A method of a package may be designed to be inaccessible to other packages in two ways: 1) by using default package protection of Java methods and 2) by using protected package protection of Java final methods. The ability to invoke inaccessible methods of other packages is restricted regardless of any system security policy implemented. System security policies may include capacity based policies, ring based policies or any other security policy which would be known by one skilled in the art. The compiler guarantees isolation between methods (i.e., code section APIs). Accordingly, an application generated using a set of APIs cannot access a second, inaccessible set of APIs for another application. Specifically, in various embodiments, an application may be downloaded or imported from a source that is potentially untrustworthy, and thus may not have access to the APIs for another application. In various embodiments, the application may have restricted access or no access to the APIs for the operating system. Under certain circumstances, it may be desirable for the application to access another application via the operating system, while protecting the accessed application, or alternatively access the operating system, but protect it from malicious attacks from downloaded or imported applications. In order to invoke an inaccessible method of another package, a system call is needed.
FIG. 1 shows a system 100 in accordance with embodiments of the invention. As shown, the system may comprise at least two processors 102 and 104. Processor 102 may be referred to for purposes of this disclosure as a Java Stack Machine (“JSM”) and processor 104 may be referred to as a Main Processor Unit (“MPU”). System 100 may also comprise memory 106, and a display 114 coupled to both the JSM 102 and MPU 104 via one or more busses 122. At least a portion of the memory 106 may be shared by both processors, and if desired, other portions of the memory 106 may be designated as private to one processor or the other. Other components such as disk drives and controllers (not specifically shown) may be included as desired for various applications.
System 100 also comprises a Java Virtual Machine (“JVM”) 108, compiler 110, Java APIs 120, Java native APIs 124, and Java applications 118. The JVM may comprise a class loader, bytecode verifier, garbage collector, and a bytecode interpreter loop to interpret the bytecodes that are not executed on the JSM processor 102. The Java applications 118 are written in Java language source code and may comprise references to one or more classes of the Java Application Program Interfaces (“APIs”) 120 and the Java native APIs 124. The Java native APIs 124 comprises interfaces to classes and methods implemented in other languages such as C++, C or assembler.
The Java source code is converted or compiled to a series of bytecodes 112, with each individual one of the bytecodes referred to as an “opcode.” Bytecodes 112 are provided to the JVM 108, possibly compiled by compiler 110, and provided to the JSM 102 and/or MPU 104 for execution. In some embodiments, the JSM 102 may execute at least some Java bytecodes directly. When appropriate, however, the JVM 108 may also request the MPU 104 to execute one or more Java bytecodes not executed or executable by the JSM 102. In addition to executing compiled Java bytecodes, the MPU 104 also may execute non-Java instructions.
The system 100 may host an operating system (not specifically shown) which performs various functions such as virtual memory management, the system task management (i.e., a scheduler), and most or all other native tasks running on the system, management of the display 114, and receiving input from various devices 116. This operating system may be written in Java in various embodiments of the present disclosure. As is described in more detail herein, embodiments of the method for making a Java system call generally comprise checking the access rights to a method, and only allowing a package to invoke a method of another package if permitted by the security policy.
Java bytecodes perform stack-based operations. For example, an “IADD” (integer add) Java opcode pops two integers off the top of the stack, adds them together, and pushes the sum back on the stack. A “simple” opcode is one in which the JSM 102 may perform an immediate operation either in a single cycle (e.g., an IADD opcode) or in several cycles (e.g., “DUP2_X2”). A “complex” opcode is one in which several memory accesses may be required to be made within the JVM data structure for various verifications (e.g., NULL pointer, array boundaries).
A JSM processor 102 in accordance with embodiments of the invention may execute, in addition to the Java bytecodes, a second instruction set other than Java™ bytecodes. In some embodiments, the second instruction set may comprise register-based and memory-based operations rather than stack-based operations. This second instruction set complements the Java instruction set and, accordingly, may be referred to as a complementary instruction set architecture (“C-ISA”). By complementary, it is meant that some complex Java bytecodes may be replaced by a “micro-sequence” comprising C-ISA instructions. The execution of Java code may thus be made more efficient and run faster by replacing some opcodes with more efficient micro-sequences of C-ISA instructions. For example, the compiler 110 may scan a series of Java bytes codes and replace one or more of such bytecodes with an optimized code segment mixing C-ISA and bytecodes and which is capable of more efficiently performing the function(s) performed by the initial group of Java bytecodes. In at least this way, Java execution may be accelerated by the JSM 102.
FIG. 2 shows an illustrative block diagram of the JSM 102. As shown, the JSM comprises a core 128 coupled to data storage 136 and instruction storage 130. The components of the core 128 preferably comprise a plurality of registers 140, address generation units (“AGUs”) 142 and 147, micro-translation lookaside buffers (micro-TLBs) 144 and 156, a multi-entry micro-stack 146, an arithmetic logic unit (“ALU”) 148, a multiplier 150, decode logic 152, and instruction fetch logic 154. Data pointed to by operands of opcodes may be retrieved from data storage 122 or from the micro-stack 146, and processed by the ALU 148. Instructions may be fetched from instruction storage 130 by fetch logic 154 and decoded by decode logic 152. The AGUs 142 may be used to calculate addresses for C-ISA instructions based, at least in part, on data contained in the registers 140. AGU 147 couples to the micro-stack 146 and may manage overflow and underflow conditions in the micro-stack 146. The micro-TLBs 144 and 156 perform the function of a cache for the address translation and memory protection information bits that are under the control of the operating system.
Java bytecodes may pop data from and push data onto the micro-stack 146, which micro-stack 146 comprises a plurality of gates in the core 128 of the JSM 102. The micro-stack 146 comprises the top n entries of a larger stack that is implemented in data storage 136. Although the value of n may be vary in different embodiments, in accordance with at least some embodiments the size n of the micro-stack may be the top eight entries in the larger, memory-based stack. By implementing the micro-stack 146 hardware in the core 128 of the processor 102, access to the data contained in the micro-stack 146 is very fast, although any particular access speed is not a limitation on this disclosure.
ALU 148 adds, subtracts, and shifts data. The multiplier 150 may be used to multiply two values together in one or more cycles. The instruction fetch logic 154 fetches instructions from instruction storage 130, which instructions may be decoded by decode logic 152. Because the JSM 102 is configured to process instructions from at least two instruction sets, the decode logic 152 comprises at least two modes of operation, one mode for each instruction set. As such, the decode logic unit 152 may comprise a Java mode in which Java bytecodes may be decoded, and a C-ISA mode in which micro-sequences of C-ISA instructions may be decoded.
The data storage 136 comprises data cache (“D-cache”) 138 and data random access memory (“D-RAM”) 139. The stack (excluding the micro-stack 146), arrays and non-critical data may be stored in the D-cache 138, while Java local variables, critical data and non-Java variables (e.g., C, C++) may be stored in D-RAM 139. The instruction storage 130 may comprise instruction RAM (“I-RAM”) 132 and instruction cache (“I-CACHE”) 134. The I-RAM 132 may be used for opcodes or micro-sequences, and the I-CACHE 134 may be used to store other types of Java bytecode and mixed Java/C-ISA instructions.
FIG. 3 illustrates a flow diagram of a process in accordance with embodiments of the invention. Although the actions of this process are presented and described serially, one of ordinary skill in the art will appreciate that the order may differ and/or some of the actions may occur in parallel. In particular, the process may start with creating Java packages, each having one or more Java methods, and each Java method having an associated access level (block 300). The packages may include a first package and a second package. In various embodiments, the first and second packages may be two applications. In various other embodiments, the first package may be an operating system, while the second package may be an application. For various reasons, as discussed previously, the second package may need to invoke an inaccessible method of the first package. For the second package to access a final protected method of the first package, a system call is carried out.
The parameters for a system call may be defined as fields of the objects comprising the methods of the first package and the second package (block 302). These parameters may be assigned a value or may remain void until a value is assigned later. The second package, having a need to invoke an inaccessible method of the first package, makes a system call to the inaccessible method in the first package (block 306). A check is done (block 308) to determine whether, according to the security policy, the second package has access to the inaccessible method of the first package it seeks to invoke. The details of the particular security policy are not material here. Any security policy, now known or developed later, may be implemented with embodiments of the present disclosure. If the second package is attempting to invoke a method of the first package to which it is not permitted access (i.e., the security policy determines that the method should not be accessed), an exception is generated (block 310). The exception may be an invalid syscall exception. When an exception is generated, the process ends.
If, according to the security policy, the second package has permission to invoke the inaccessible method of the first package, the JVM 108 switches from the method (i.e., a particular code segment) of the second package to the inaccessible method (another specific code segment) of the first package (block 312). The JVM 108 creates an object to invoke execution of the inaccessible method of the first package (block 314). Then the method of the first package that was called by the second package may be executed (block 316). When the method of the first package has been executed, the JVM 108 switches back to the method of the second package (block 318). The results of the inaccessible method of the first package being executed are returned to the method of second package as its execution resumes (block 320). This may be accomplished using one of the parameter fields established in block 302.
FIGS. 4 and 5 illustrate an example Java code embodiment of the process described with reference to FIG. 3. FIG. 4 illustrates the code that may be comprised in the first package. A class Titi is defined (lines 1-13). A Java method A of class Titi is defined (lines 9-12), as well as a Java method SyscallA that calls Java method A of class Titi (lines 5-8). Due to the default package protection, Method A and Method SyscallA, are inaccessible to methods of other packages. Various parameters are established for the system call (lines 3-4).
FIG. 5 illustrates exemplary code that may be comprised for the second package, which comprises an application seeking to invoke a method of another application. A class Toto is defined (lines 1-12). Various parameters are established for the system call (lines 3-4). A public Java method A is defined, providing an interface for the system call (lines 5-11).
FIG. 5 additionally illustrates exemplary code defining a Java native method, Syscall, which carries out the system call (lines 13-27). The parameters for the system call include callerpackage (of string type), packageAndClassNameToAccess (of string type), methodToCall (of string type), and callingobject (of object type) (lines 13-16). An object OO is defined to interface between the first and second packages (line 18).
A Java method, checkRights, is invoked to compare the rights of the calling package (i.e., the second package) to the package being accessed (i.e., the first package), and the inaccessible Java method being invoked (i.e., method A) according to the security policy (line 19). If the security policy indicates that the calling package (i.e., the second package) does not have permission to access the first package and the inaccessible method, an invalid syscall exception may be generated.
If the security policy permits access, then the Java Virtual Machine 108 changes the code segment to the targeted first package (FIG. 5, line 20). The JVM 108 creates an object used to invoke a system call (line 21). Then, the JVM 108 copies the fields of the calling object (e.g., an object of class Toto) in OO (line 22). The JVM 108 then calls the invoked Java method, or in other words, makes the system call (line 23). In the example shown, VMCallMethod will invoke the Java method OO.SyscallA(this). Generally speaking, the system call described above will flow as follows: Java method A (line 5 of FIG. 5) invokes the native method (line 9 of FIG. 5), which invokes Syscall A (line 5 of FIG. 4) which invokes Java method A (line 9 of FIG. 4). Once the result is stored, this flow is reversed. After execution of the called Java method, the JVM 108 then copies the fields of OO back into the calling object (line 24), restores the original code segment, resumes the method of the calling package (line 25), and returns the results of the call (line 26).
System 100 may be implemented as a mobile cell phone such as that shown in FIG. 6. As shown, the mobile communication device includes an integrated keypad 412 and display 414. The JSM processor 102 and MPU processor 104 and other components may be included in electronics package 410 connected to the keypad 412, display 414, and radio frequency (“RF”) circuitry 416. The RF circuitry 416 may be connected to an antenna 418.
While the various embodiments of the invention have been shown and described, modifications thereof can be made by one skilled in the art without departing from the spirit and teachings of the invention. The embodiments described herein are illustrative only, and are not intended to be limiting. Many variations and modifications of the invention disclosed herein are possible and are within the scope of the invention. Accordingly, the scope of protection is not limited by the description set out above. Each and every claim is incorporated into the specification as an embodiment of the present invention.

Claims

1. A method of making a Java system call, comprising:

creating a first package comprising a first method inaccessible to packages other than the first package and a second package comprising a second method;

invoking the first inaccessible method from a second method, wherein a right of access to the first inaccessible method is checked according to a security policy; and

returning a result of invoking the first inaccessible method to the second method.

2. The method of claim 1, wherein invoking the first method further comprises:

invoking the first inaccessible method in place of execution of the second method if access is permitted according to the security policy.

3. The method of claim 1, wherein invoking the first inaccessible method further comprises:

creating an object for execution of the first inaccessible method.

4. The method of claim 1, wherein invoking the first inaccessible method further comprises:

executing the first inaccessible method; and

resuming execution of the second method; wherein the result of the execution of the first inaccessible method is returned to the second method.

5. The method of claim 1, further comprising:

initiating a native system call.

6. The method of claim 1, further comprising:

passing one or more parameters of the second method to the first inaccessible method.

7. The method of claim 2, further comprising:

generating an exception if access to the first inaccessible method is not permitted according to the security policy.

8. The method of claim 1, wherein invoking the first inaccessible method from a second method further comprises:

invoking the inaccessible operating system method in place of execution of the application method if access is permitted according to the security policy;

generating an exception if access to the inaccessible operating system method is not permitted according to the security policy;

passing one or more parameters of an application to an operating system;

creating an object for execution of the inaccessible operating system method;

initiating a native system call;

executing the inaccessible operating system method; and

resuming execution of the application method;

wherein the result of the invoking the inaccessible operating system method is returned to the application method; and

wherein the operating system comprises the first package, the inaccessible operating system method comprises the first method inaccessible to packages other than the first package, the application comprises the second package, and the application method comprises the second method.

9. A computer-readable medium storing a Java program that, when executed by a processor, performs a method comprising:

10. The computer-readable medium claim 9, wherein invoking the first method further comprises:

11. The computer-readable medium claim 9, wherein invoking the first method further comprises:

creating an object for execution of the first inaccessible method.

12. The computer-readable medium claim 9, wherein invoking the first method further comprises:

executing the first inaccessible method; and

13. The computer-readable medium of claim 9, the method further comprising:

initiating a native system call.

14. The computer-readable medium of claim 9, the method further comprising:

15. The computer-readable medium of claim 9, the method further comprising:

16. The computer-readable medium of claim 9, wherein invoking the first inaccessible method from a second method further comprises:

passing one or more parameters of an application to an operating system;

creating an object for execution of the inaccessible operating system method;

initiating a native system call;

executing the inaccessible operating system method; and

resuming execution of the application method;

17. A system, comprising:

a processor;

a virtual machine (“VM”) configured to execute on the processor; and

a Java software program configured to execute on the VM,

wherein the Java software program is configured to:

create a first package comprising a first method inaccessible to packages other than the first package and a second package comprising a second method;

invoke the first inaccessible method from a second method, wherein a right of access to the first inaccessible method is checked according to a security policy; and

return a result of invoking the first inaccessible method to the second method.

18. The system of claim 17, wherein invoking the first method further comprises:

19. The system of claim 17, wherein invoking the first method further comprises:

creating an object for execution of the first inaccessible method.

20. The system of claim 17, wherein invoking the first method further comprises:

executing the first inaccessible method; and

21. The system of claim 17, wherein the Java software program is further configured to initiate a native system call.

22. The system of claim 17, wherein the Java software program is further configured to pass one or more parameters of the second method to the first inaccessible method.

23. The system of claim 17, wherein the Java software program is further configured to generate an exception if access to the first inaccessible method is not permitted according to the security policy.

24. The system of claim 17, wherein invoking the first inaccessible method from a second method further comprises:

passing one or more parameters of an application to an operating system;

creating an object for execution of the inaccessible operating system method;

initiating a native system call;

executing the inaccessible operating system method; and

resuming execution of the application method;

25. The system of claim 17, wherein the system comprises a mobile device.