Electrical computers and digital processing systems: interprogra – Application program interface
Reexamination Certificate
2001-04-24
2004-12-21
An, Meng-Al T. (Department: 2126)
Electrical computers and digital processing systems: interprogra
Application program interface
C717S140000, C713S167000
Reexamination Certificate
active
06834391
ABSTRACT:
BACKGROUND
1. Field of the Invention
The present invention relates to computer instruction codes. More specifically, the present invention relates to a method and an apparatus for automatically isolating native code from platform-independent code written in a safe computer programming language.
2. Related Art
A common trend among computer specialists is to use safe computer-programming languages and systems such as JAVA™ to implement computer programs. (JAVA is a trademark or registered trademark of Sun Microsystems, Inc., Palo Alto, Calif., in the United States and other countries.) Typically, programs written in these safe computer-programming languages are compiled to a platform-independent code for execution within a safe virtual machine on a variety of target computers. In this context, the term “safe” indicates a level of confidence that the program and runtime system will not interfere with other applications running on the target computer and will not adversely affect memory use.
The growing popularity of these safe computer-programming languages has not, however, obviated the need for using native code on the target computers. Native code is code that has been compiled into the native instruction set of a particular computer processor. While safe languages offer many benefits, including inherent code reliability, increased programmer productivity, and ease of code maintenance, it is quite often desirable to execute user-supplied native code. There are several reasons for accepting this impurity, such as higher performance, access to devices and programming interfaces for which there is no standard mapping from the platform-independent runtime system, and direct interaction with operating system services. Nevertheless, native code is unsafe and, as such, breaks the contract offered by the safe language.
As an example of how native code is accessed by safe code running in a safe environment,
FIG. 1
illustrates platform-independent runtime environment
104
accessing native code library
106
. Platform-independent runtime environment
104
is contained within process
102
and is typically executing a platform-independent program. Process
102
also includes native code library
106
and platform-independent native interface (PINI)
108
. Platform-independent runtime environment
104
and any executing platform-independent programs access native code library
106
through PINI
108
. The interaction through PINI
108
can have two forms: downcall
110
(when a platform-independent program calls a native sub-routine) and upcall
112
(when a native sub-routine needs to access data or invoke sub-routines of the platform-independent program). PINI
108
is the only access point to native code library
106
from platform-independent runtime environment
104
. In operation, a platform-independent program running in platform-independent runtime environment
104
can make downcall
110
to a sub-routine within native code library
106
. In turn, native code library
106
can make an upcall to platform-independent runtime environment
104
to access data and platform-independent sub-routines.
Making native code not violate certain safety policies while it is executing in the same address space as the platform-independent code has been the focus of several research projects. Descriptions of relevant research projects can be found in the following references:
Efficient software fault isolation
(Wahbe, R., Lucco, S., Anderson, T., and Graham, S., 14
th
ACM Symposium on Operating Systems Principles, Asheville, N.C. December 1993) describes augmenting native code with safety-enforcing software checks.
Safe Kernel Extensions without Runtime Checking
(Necula, G, and Lee, P., Proceedings of the Second Symposium on Operating Systems Design and Implementation, Seattle, Wash., 1996) describes statically analyzing native code and proving it to be memory safe.
TALx
86
: A Realistic Typed Assembly Language
(Morrisett, G., Crary, K., Glew, N., Grossman, D., Samuels, R., Smith, F., Walker, D., Weirich, S., and Zdancewic, S., Proceedings of ACM SIGPLAN Workshop on Compiler Support for System Software, Atlanta, Ga., May 1999) describes designing a low-level, statically typed target language for compiling native code.
While the methods used in these research projects have been successful to a point and are useful in some circumstances, their usefulness for addressing problems with an arbitrary native library is rather limited. Augmenting the native code with safety-enforcing software checks can incur a substantial performance penalty, which is difficult to accept when considered in conjunction with the fact that the native code is often used as a performance-boosting mechanism. Statically analyzing the native code and proving that it is safe requires the availability of the source code for the native code and the generation of formal proofs of correctness, which is difficult or impossible.
Most platform-independent systems contain a mix of native code, native code compiled from bytecode, native code that is part of the platform-independent virtual machine (PIVM) runtime and interpreter, native code that is part of the core libraries, and, optionally, user-specified native code. While most of this native code is logically part of the PIVM runtime, is designed, implemented, and tested by the developers of the particular implementation of the PIVM, and is totally under their control, user-specified native code has not been subjected to the same rigor and, therefore, is subject to a multitude of problems.
Native code is usually thought of as being written against two interfaces: the PINI, which is its sole interaction with the PIVM and platform-independent application, and the host operating system interfaces involving the usual libraries for input/output (I/O), threading, math, networking, and the like. The host operating system interface is also the interface against which the PIVM is written, and therein lies a problem. The PIVM has to make certain decisions regarding the use of the host operating system interface and of available resources. For example:
Signal handlers may need to be instantiated to handle exceptions that are part of the operation of the PIVM (e.g., to detect null pointer and other memory exceptions, to detect arithmetic exceptions, to detect an interrupt signal, etc.).
The PIVM must choose a memory management regime (involving such things as malloc/free and mmap/munmap) for its own purposes, including the allocation of thread stacks and red zones.
Platform-independent threads are typically mapped onto the underlying system's threading mechanism and a convention is adopted to suspend and resume threads for garbage collection (GC), to assign threads to GC and compilation tasks, etc.
The PIVM must decide how to manage I/O (e.g., the use of blocking or non-blocking calls).
The core classes automatically take care of freeing some system resources (e.g., closing open file descriptors); this policy does not extend to the very same resources used exclusively by native code.
Few, if any, of these mechanisms are composable, in the sense that it is not possible to take two arbitrary native programs, which use the PINI and the host operating system interface, put them together into one process, and expect the resulting system to work correctly. So, in reality, the user specific native code has to be written to a set of implicit interfaces that do not conflict with the way the PIVM uses system resources. These implicit conventions are rarely documented (because they are highly dependent on the implementation decisions within the PIVM, which are subject to frequent change, and are usually thought of as private to the PIVM), and do not have to be common across even the same vendor's PIVMs on the same platform, much less PIVMs on differing platforms and certainly not across different vendor's PIVMs. Furthermore, it is rare that legacy libraries will respect these conventions: the economics of amending these libraries to respect these conventions are prohibitive (e.g., so
Czajkowski Gregorz J.
Daynes Laurent P.
Wolczko Mario I.
An Meng-Al T.
Anya Charles E.
Park Vaughan & Fleming LLP
Sun Microsystems Inc.
LandOfFree
Method and apparatus for automated native code isolation 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 apparatus for automated native code isolation, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Method and apparatus for automated native code isolation will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3308890