java外文文献

Computer Communications 23 (2000) 1594±1605/locate/comcom On object initialization in the Java bytecode qS. Doyon *, M. DebbabiLSFM Research Group, Department of Computer Science, Laval University, Sainte Foy, Que., Canada G1K 7P4AbstractJava is an ideal platform for implementing mobile code systems, not only because of its portability but also because it is designed with security in mind. Untrusted Java programs can be statically analyzed and validated. The program's behavior is then monitored to prevent potentially malicious operations. Static analysis of untrusted classes is carried out by a component of the Java virtual machine called the veri®er. The most complex part of the veri®cation process is the data¯ow analysis, which is performed on each method in order to ensure type-safety. This paper clari®es in detail one of the tricky aspects of the data¯ow analysis: the veri®cation of object initialization. We present and explain the rules that need to be enforced and we then show how veri®er implementations can enforce them. Rules for object creation require, among other things, that uninitialized objects never be used before they are initialized. Constructors must properly initialize their this argument before they are allowed to return. This paper also deals with initialization failures (indicated by exceptions): the object being initialized must be discarded, and constructors must propagate initialization failures. q 2000 Elsevier Science B.V. All rights reserved.Keywords: Java bytecode; Object initialization; Data¯ow analysis; static analysis; java security1. IntroductionThe Java architecture is particularly well-suited for implementing mobile code systems. A mobile code archi-tecture allows a computer to fetch a program (or parts of a program) from a network source and execute it locally. However, security is a critical aspect of mobile code archi-tectures. The very essence of mobile code is to execute a program that originates from a remote source. This is inher-ently dangerous because it is not known what actions that program will take. By executing the mobile code, we are allowing it to perform operations on our machine and we are giving it access to our local resources.Java is especially well-suited for implementing mobile code systems for three reasons:²Java source is compiled into a platform-independent intermediate form called Java bytecode. Java byte-code is then interpreted by the JVM (Java virtual machine).This makes Java bytecode completely portable, which means a piece of Java code in compiled form should run on any receiving machine.q The research reported in this paper has been supported by the National Science and Engineering Research Council (NSERC), the Fonds pour la formation de chercheurs et l'aide aÁ la recherche (FCAR), and the Defense Research Establishment Valcartier (DREV), Department of National Defense.*Corresponding author. Tel.: _1-41-8656-7035; fax: _1-41-8656-2324.E-mail address: ****************.ca(S.Doyon).²It is dynamically linked: the JVM will load classes from different network sources as they are needed and will link them into the program while it runs.²The Java architecture is built with security in mind: its design makes it possible to enforce suf®cient security to make mobile code safe and practical.Currently, the most popular manifestation of Java mobile code is applets. A JVM (bytecode interpreter) is incor-porated in web browsers. Web pages can then include links that point to the compiled (bytecode) form of programs which are called applets. The applet can then be loaded by the browser and executed locally with no special effort on the user's part.The veri®er is a key component of the Java security archi-tecture. Its role is to examine compiled classes as they are loaded into the JVM in order to ensure that they are well-formed and valid. It checks that the code respects the syntax of the bytecode language and that it respects the language rules. Another component of the Java security architecture, called the security manager, monitors access to system resources and services. The security manager is a security layer, which goes on top of the veri®er and relies on its effectiveness.The most complex step of the veri®cation process performed by the veri®er requires running a data¯ow analy-sis on the body of each method. There are a few particularly tricky issues regarding the data¯ow analysis. In this paper, we focus on the issues relating to the initialization of0140-3664/00/$ - see front matter q 2000 Elsevier Science B.V. All rights reserved. PII: S 0 1 4 0 - 3 6 6 4 ( 0 0 ) 0 0 2 4 5 - 0S. Doyon, M. Debbabi / Computer Communications 23 (2000) 1594±16051595new objects:²Issues relating to object creation: A new object is created in two steps: space is allocated for the new object, and then it is initialized. When performing the data¯ow analysis, the veri®er must ensure that certain rules are respected: the constructor used to initialize an object must be appropriate, an object must not be used before it is initialized, an object must not be initialized more than once and initialization failures (indicated by exceptions) must be handled properly.²Issues relating to constructors: The constructor is respon-sible for initializing a new object. The ®rst part of the constructor's work performs initialization from a typing point of view, which implies directly or indirectly calling a constructor from the superclass. The rest of the constructor performs application-speci®c initialization. The veri®er must ensure that a constructor properly initi-alizes the current object before it returns, that it does not use the current object in any way before calling the super-class constructor and that it propagates any initialization failure occurring in the superclass constructor.The Of®cial documentation on the veri®er, provided in (Ref. [1], Sections 4.8 and 4.9) and in Ref. [2], is relatively sparse; the portions discussing object initialization are very brief, vague, and leave out some important issues. Indepen-dent work presented in Ref. [3] has clari®ed many aspects. Freund and Mitchell have extended the formalization of a subset of the Java bytecode language introduced in Ref. [4]. They used a type system to describe the veri®er's handling of object initialization. Our paper reviews and explains the rules related to object initialization and discusses how a veri®er implementation can enforce them. We also touch on a few issues not discussed in Ref. [3]. Exceptions thrown during object initialization indicate initialization failures and must be handled properly, both inside and outside of a constructor. We also provide a comprehensive, intuitive explanation of how the rules for object creation can be enforced with minimal effort.We assume that the reader has some knowledge of the Java bytecode language, as well as a basic understanding either of data¯ow analysis in general or of the particular analysis technique used by the Java bytecode veri®er. The unfamiliar reader may consult the following references for more complete information: for the Java language the reader may refer to the of®cial speci®cation of the language [5]. The best way to learn Java or to ®nd a more understandable explanation of its concepts is to read Ref. [6]. For details on the Java standard library, see Ref. [7]. The workings of the JVM and the bytecode instruction set are described in the of®cial JVM speci®cation [1]. For a lighter approach, see Ref.[8]. To gain a good understanding of the Java bytecode language, it is necessary to experiment with it. Two tools are essential: a class ®le disassembler, that will print out a class ®le (and in particular the bytecode) in a readable format.Sun's javap tool, which comes with the JDK can be used for this, although other alternatives are available. A byte-code assembler, that produces class ®les from some source with a manageable syntax. Otherwise, constructing binary class ®les by hand would be dif®cult and time consuming.A great solution is the excellent jasmin [9].This paper is organized as follows. Section 2 provides a brief overview of the data¯ow analysis in order to show the context in which veri®cation of object initialization occurs. Section 3 deals with the creation of new objects, while Section 4 explains the special requirements imposed on constructors. Each of these sections ®rst presents the neces-sary rules that the veri®er must somehow enforce, and then discusses how an implementation could achieve the desired result. Section 5 shows that constructors may ªleakº or ªsaveº a copy of their this reference, which means that it is possible for incompletely initialized objects to be actually used. Section 6 lists some of the related work. Some concluding remarks are ultimately sketched as a conclusion in Section 7.2. Data¯ow analysisThe Java bytecode veri®er ensures that the classes loaded by the JVM do not compromise the security of the system, either through disrespect of the language rules or through compromise of the integrity of the virtual machine. The veri®er validates many syntactical aspects of the class ®le. It validates ®eld and method declarations. It makes some checks relating to the superclass. It veri®es references to other classes, other methods and ®elds and it enforces access restriction mechanisms (like protected, private and ®nal). The body of each method is examined in turn: each byte-code instruction and its operands are validated.The most complex yet most interesting part of the veri®-cation process is the data¯ow analysis. It is performed inde-pendently on each method. The data¯ow analysis checks that each bytecode instruction gets arguments of the proper type (from the stack or from the registers), detects and prevent over¯ows and under¯ows of the expression evaluation stack and ensures that subroutines are used consistently. The data¯ow analysis also must check that object initialization is performed correctly. This paper will attempt to clarify the properties that need to be enforced on object creation and constructors. We will also propose ways in which a veri®er implementation can enforce those rules.In order to perform the data¯ow analysis, it is necessary to keep track of the type of each value on the stack and in the registers at each program point. We will assume that each instruction of a method constitutes a program point, although it is possible to use fundamental blocks of instruc-tions as program points. The type, which is recorded by the data¯ow analysis for a given location at a given program point must be consistent, irrespective of the execution path used to reach that program point. When there is a con¯ict1596S. Doyon, M. Debbabi / Computer Communications 23 (2000) 1594±1605because two or more paths would yield different types of values for the same location, then we record for that location a common supertype of all the types that could actually occur. For instance, if at a given program point a certain loca-tion could contain either an instance of FileInputStream or an instance of ByteArrayInputStream, the data¯ow analysis ªmergesº the two types and records the type Input-Stream instead. If there are no common supertypes for the possible types in a certain location, then the type unusable is used, indicating that the value cannot be used by the following instructions. This generalization of types does imply a loss of information and precision. This is what makes the analysis conservative, in the sense that it is pessimistic.Types used in the data¯ow analysis are primitive types (single-word int or ¯oat or double-word long or double) and reference types (the types associated to references to objects or arrays). A reference type may be a class, interface or array type (which speci®es a base type and a number of dimensions). The type returnAddress will be used to describe the return address to a subroutine, as created by the jsr instruction. The special type named unusable is used to mark uninitialized registers. The special reference type null is used to represent the type of null references produced by the aconst_null instruction. Also note that implementations will generally use other special types to represent allocated but not yet initialized objects.3. Object creationCreating a new object is done in two steps. First, space for the object is allocated through the use of the new instruction, which returns a reference that points to the newly allocated memory space. Then, the object is initialized by invoking one of its constructors (a method named k init l).For example, the Java statementnew String()is translated to the following bytecode instructions: ;allocate space for String and push ;reference to it onto the stacknew java/lang/String;duplicate top stack item (reference to ;newly allocated space)dup;call String.String() constructor, uses ;up one of the references to newly allocated;space as ªthisº argument. invokespecialjava/lang/String/ k init l()V;This leaves a reference to the new ;String object on the stack.The constructor is responsible for putting the object in a valid state. Until initialization of the new object completes, its state remains unde®ned and may be inconsistent. The language semantics therefore disallows using a newly allo-cated object before it is initialized. Enforcing this is one of the veri®er's responsibilities. The veri®er must keep track of which object is initialized and which is not, ensure that proper constructors are used to initialize new objects and make sure that uninitialized objects are not used before they are initia-lized. This is one of the tricky points of the data¯ow analysis. Ref. [1] covers this aspect brie¯y. Ref. [3] presents a detailed analysis and formal speci®cation of the language rules related to object initialization. Unfortunately, neither Refs. [3] nor [1] discuss the interaction between object initialization and exception handlers. We will ®rst discuss the rules that the veri®er should enforce, and we will then consider how a veri®er implementation can enforce them.3.1. RulesThe veri®er must enforce the following properties:²An object must not be used before it is initialized.²An uninitialized object must be initialized by one of the constructors declared in its class. A constructor fromanother class cannot be used. Notice that methodsnamed k init l are not inherited.²An object must not be initialized more than once.²If an exception is thrown by the call to the instance initialization method, then the new object must not be used because its initialization is incomplete.We ®rst discuss what it means for an uninitialized object (or rather a reference to it) to be ªusedº. The reference pushed onto the stack by the new instruction should be considered to have a special type, indicating that the object it points to is not initialized. The veri®er must allow moving and copying the reference on the stack and into registers. Any other use of the reference must be disallowed. To be precise:Copying the reference to and from registers using aload and astore is permitted.Moving the reference around on the stack through swap, pop and its variants is permitted. Duplicating the refer-ence through dup and its variants is also allowed.Putting the reference in an object or a class ®eld through put®eld or putstatic is not allowed. Accessing ®elds of the uninitialized object itself (through get®eld or put®eld) is not allowed either. This means that the new reference is unacceptable as either of the two arguments of put®eld.The reference must not be passed as a parameter to a method or used to designate the object on which a method is called. It is therefore disallowed as any of the parameters of invokevirtual, invokespecial and invokeinterface, except of course that anS. Doyon, M. Debbabi / Computer Communications 23 (2000) 1594±16051597k init l methods can be invoked on it by invokespe-cial.The reference may not be thrown as an exception by athrow.The current method may not return the new reference through areturn.The new reference may not be stored into an array through aastore.The reference's type may not be checked through checkcast or instanceof.The monitor of the new object may not be accessed through monitorenter or monitorexit.A newly allocated object can be initialized by calling one of its constructors (instance initialization methods, named k init l). Only the invokespecial instruction may be used to invoke such methods. When the constructor returns, the object is considered to have been properly initialized. Classes may provide several constructors (methods named k init l) with different signatures. There is no restriction as to which constructor should be called. In fact, the class being instantiated might not have been linked yet and the veri®er might not even know which constructors are available: exis-tence of the constructor will be checked during resolution, in the same way as any other method invocation.Invoking a method named k init l is a special case for invokespecial. The veri®er should validate the para-meters being passed to the method as it would normally. The reference indicating on which object the method is being invoked should be a reference to an uninitialized object of the proper type: that is, a reference to an uninitialized object of the same type as the class from which the k init l method is taken. Suppose a class named C is being instantiated. An instruction of the formnew Chas been used to allocate space for the new object. It can be initialized by calling one of the k init l methods of class C on the reference returned by new:invokespecial C/_init _ (¼)VThe class from which the k init l method is taken must correspond to the target class of the new instruction that created the reference. Hencenew Cinvokespecial D/k init l()Vis not acceptable, even if D happened to be C`s superclass. This is not to simple as it is possible to have several different references to uninitialized objects on the stack at one time. The following Java statement, for example,new BufferedReader(newInputStream Reader(System.in));is compiled to;Allocate space for BufferedReadernew java/io/BufferedReaderdup;Allocate space for InputStreamReader new java/io/InputStreamReaderdup;Get in ®eld of System(System.in) getstaticjava/lang/System/inLjava/io/ InputStream;;Call InputStreamReader's constructor, ;taking System.in asparameter. invokespecialjava/io/InputStreamReader/k init l(Ljava/io/InputStream;)V ;Call BufferedReader constructor, taking ;reference to properly initialized;InputStreamReader asparameter. invokespecialjava/io/BufferedReader/k init l(Ljava/io/Reader;)V;Leaves a reference to the properly ;initialized BufferedReader on the stack.There can even be references to multiple uninitialized instances of the same class on the stack at the same time. Consider for example the Java statement:URL u ˆ new URL (new URL (ªhttpº,ªmyhostº,8000,ª/dir1/dir2/page.htmlº),ª../index.htmlº);In this example, two distinct objects are created and both need to be initialized independently. The corresponding bytecode would be:; Outer URLnew java/net/URLdup; Inner URLnew java/net/URLdupldc ªhttpºldc ªmyhostºsipush 8000ldc ª/dir1/dir2/page.htmlº;Initializing innermost URL invokespecialjava/net/URL/k init l(Ljava/lang/String;Ljava/lang/1598S. Doyon, M. Debbabi / Computer Communications 23 (2000) 1594±1605String;ILjava/lang/String;)Vldc ª../index.htmlº;Initializing the other URL, using the ;innermost initialized URL as one of ;the parameters.invokespecial java/net/URL/k init l(Ljava/net/URL;Ljava/lang/String;)V ;Assuming that variable u is contained ;in register 1astore_1We discuss a way to cope with this situation in Section 3.2.Once the instance initialization method returns, the object is considered to have been initialized. The type of the refer-ences to the object should be changed to show the real type of the initialized object. This will make it possible for the references to be used normally as argument to various byte-code instructions. The only complication here is that the reference to the new object may have been copied to many stack locations and registers. Consider the bytecode:new Cdupastore_1dupastore_2dupdupinvokespecial C/k init l()VThis code leaves two references to the new object in regis-ters 1 and 2 as well as two references on the stack. This creates an aliasing problem. When the invokespecial instruction completes, the type of each of these references should be changed from the uninitialized type to type C. When the invokespecial instruction is used to call a method named k init l (a constructor), the this argument it receives must not be a reference to an already initialized object. This ensures that an object will not be initialized more than once.Finally, if an exception is thrown by the call to a construc-tor, then it can be assumed that the initialization process terminated abnormally. In that case, there is no guarantee that the object was properly initialized. Any use of an incor-rectly initialized object must be disallowed. It might not even be safe to try to initialize the object again, therefore invoking a second constructor on the object should not be permitted. The object practically becomes worthless as nothing can be done with it. If the exception is not caught, then the problem is avoided as execution of the current method terminates and the reference to the incorrectly initi-alized object is lost. Any handler that might catch an excep-tion thrown during the invokespecial instruction that calls a constructor must be prevented from using the incorrectly initialized object. The best way to do this is probably to change the type of all references to the object to the type indicating an unusable value. As the stack is discarded when an exception is caught, only references in registers are affected.1The JVM speci®cation (Ref. [1], Section 4.9.4) imposes the following requirements:A valid instruction sequence must not have anuninitialized object on the operand stack or in a localvariable during a backward branch, or in a localvariable in code protected by an exception handler ora ®nally clause.This restriction is not necessary. The strategy it suggests is impractical and has been abandoned.3.2. Enforcing the rulesDevising an implementation to verify the rules for object initialization is tricky. There are subtle issues, which make the analysis of proposed solutions rather complex. Fortunately, once de®ned, the solution is easy to implement.New types must be used to distinguish uninitialized objects from other objects, so that uninitialized objects are rejected as arguments to most instructions. The types used to represent uninitialized objects must somehow²include or point to the type that the object will have when it is initialized, so that the data¯ow analysis can verify that a constructor invoked on the uninitialized object is appropriate;²allow distinction between multiple uninitialized instances of the same class, so that when an object is initialized, only the references pointing to that object have their type changed.Refs. [1] and [3] agree on roughly the same solution. The uninitialized type should include the instruction number or the offset of the new instruction that created the uninitialized object. Thus, the type that the object should have when it is initialized can be obtained from the uninitialized type by consulting the operand of the associated new instruction. Alternatively, both the instruction number of the new instruction and the ultimate type of the object can be included in the uninitialized type. We observed in Section 3.1 that it is possible to have several distinct uninitialized instances of the same class in existence on the stack and in registers at the same time. However, the data¯ow analysis will ensure that each of these instances has been created by different new instructions. Thus, associating the instruction number of the new to the uninitialized type it creates suf®ces to make the types of two uninitialized objects distinct, even if both objects are instances of the same class.1There does not seem to be any situation in which there would be a compelling necessity for storing references to uninitialized objects in registers.S. Doyon, M. Debbabi / Computer Communications 23 (2000) 1594±16051599The veri®er can easily decide whether the constructor being called to initialize an object is appropriate. If an k init l method is called on an uninitialized object of type uninit(i), then the class from which the k init l method is taken must be the same as the class speci®ed by the new instruction at instruction number i. In the typing state result-ing from the initialization, all occurrences of the uninit(i) type on the stack or in the registers are changed to the appropriate initialized type. If an exception occurs during initialization, then the object that was being initialized must be discarded. Therefore, a slightly different resulting state is merged in any exception handler successors of the invoke-special instruction which called the constructor: any occurrence of uninit(i) in the registers is changed to unusa-ble. Let us go back to the example given in Section 3.1.Table 1 reports the stack state evolution while analyzing the class ®le.The constructor invocation at instruction 9 is appropriate because the class from which the constructor is taken is the same as that speci®ed by the operand of the new instruction at instruction 3. In the state resulting from instruction 9 (associated to instruction 10), the type of any remaining occurrence of uninit(3) is changed and the occurrences of uninit(1) are left alone.Merging two uninitialized types produces the type unusable, unless both are exactly the same type. If both uninitialized types are the same (they refer to the same new instruction) then the merge produces that same uninitialized type. Merging an uninitialized type with an initialized type or with a primitive type produces unusable. Merging the null type with an uninitialized type could produce that same uninitialized type: attempting to initialize a null reference will trigger a run-time exception. However,there is no situation in which it would be useful to merge an uninitialized type with the null type. This possibility is never encountered in code produced by a Java compiler. As we will explain shortly, it might be simpler for the merge of an uninitialized type and null to produce the unusable type.One might think that a problematic situation could arise if a method managed to execute the same new instruction (with instruction number i) twice without initializing the object created by the ®rst execution of new. Then there would be two identical uninit(i) types describing two distinct uninitialized objects. If one of them were to be initialized, the veri®er would think that both have been initialized and it would therefore allow an uninitialized object to be used. However, except in one case, this situation cannot occur. Suppose a new instruction can be found at offset or instruction number i. The ®rst time the data¯ow analysis visits this instruction, there can be no reference of type uninit(i) anywhere on the stack or in the registers. Suppose the code following the new instruction leaves the uninitialized object in a register or stack location l. If the control ¯ow gets back to the new instruction, then the typing states from the ®rst and second visit will be merged. Whatever type location l contained during the ®rst visit to the new instruction will be merged with uninit(i) to produce the unusable type. Thus, the object that was created by the ®rst visit to new and that was never initialized has effec-tively been forgotten: it can no longer be used in any way; it cannot even be initialized.This reasoning depends on the fact that merging uninit(i) with any type but itself should produce unusable. The case in which this reasoning does not hold is when the merging of uninitialized object types and the null type is de®ned toTable 1Illustration of the stack stateI# Instruction Stack1 new java/net/URLà ¼2 dup uninit(1)ü3 new java/net/URL uninit(1)à uninit(1)ü4 dup uninit(3)à uninit(1)à uninit(1)ü5 ldc ªhttpºuninit(3)à uninit(3)à uninit(1)à uninit(1)ü6 ldc ªmyhostºString Ãuninit(3)Ãuninit(3)Ãuninit(1)Ãuninit(1)ü7 sipush 8000String à String Ãuninit(3)Ãuninit(3)Ãuninit(1)Ãuninit(1)ü8 ldc ª/dir1/dir2/int ÃStringÃStringà uninit(3)à uninit(3)à uninit(1)à uninit(1)üpage.htmlºString Ãintà String à String Ãuninit(3)Ãuninit(3)Ãuninit(1)Ãuninit(1)ü9 invokespecial java/net/URL/k init l (Ljava/lang/String;Ljava/lang/String;ILjava/lang/String;)VURL Ãuninit(1)Ãuninit(1)ü10 ldc ª../index.htmlº11 invokespecial java/String à URL Ãuninit(1)Ãuninit(1)ünet/URL/k init l(Ljava/net/URL;Ljava/lang/String;)VURL ü12 astore_1。