9/23/2015
`
`Kava ­ A Reflective Java Based on Bytecode Rewriting. (PDF Download Available)
`
`Conference Paper
`Kava ­ A Reflective Java Based on Bytecode Rewriting.
`
`Ian Welch
`
`Robert J. Stroud
`
`DOI: 10.1007/3­540­45046­7_9 Conference: Reflection and Software Engineering,
`Papers from OORaSE 1999, 1st OOPSLA Workshop on Reflection and Software
`Engineering, Denver, CO, USA, November 1999
`Source: DBLP
`
`ABSTRACT Current implementations of reective Java typically either require
`access to source code, or require a modied Java platform. This makes them
`unsuitable for applying reection to Commercial­o­the ­ Shelf (COTS) systems. The [more]
`
`Full­text
`
`Available from: Ian Welch, Sep 24, 2015
`
`Download full­text
`
`The authors of this publication are on ResearchGate and have made the full­text
`available on their profiles.
`
`Sign up for a free account to access
`more full­texts.
`
`Conference Paper: Kava ­ A Reflective Java Based on Bytecode Rewriting.
`Available from: Ian Welch
`
`Join for free
`
`0 FOLLOWERS · 15 READS
`
`Data provided are for informational purposes only. Although carefully collected, accuracy cannot be guaranteed. The impact factor represents a rough estimation of the journal's impact factor and
`
`http://www.researchgate.net/publication/221141803_Kava_­_A_Reflective_Java_Based_on_Bytecode_Rewriting
`
`1/2
`
`JOIN FOR FREE
`
`LOG IN
`
`Blue Coat Systems - Exhibit 1008 Page 1
`
`

`
`9/23/2015
`
`Kava ­ A Reflective Java Based on Bytecode Rewriting. (PDF Download Available)
`
`does not reflect the actual current impact factor. Publisher conditions are provided by RoMEO. Differing provisions from the publisher's actual policy or licence agreement may be applicable.
`
`REFERENCES (25)
`
`CITED IN (41)
`
`"It is easy to see how our proposed architecture could be implemented for software platforms based on the Java language
`runtime. Java­based systems already support both code manifests and strong cryptographic code identity [15]; many already
`contact the platform creators through an online service for sending error reports and retrieving updates; and it has been
`demonstrated that it is simple to accommodate both the identification and hooking required for the mediation framework [13]
`[54]. Indeed, architectures similar to our proposal have already been implemented for Java­based application server
`platforms, the Wily Interscope management and monitoring system being one example [55]. "
`
`Source
`
`Article: Ad hoc extensibility and access control.
`Úlfar Erlingsson · John MacCormick
`[Show abstract]
`
`ACM SIGOPS Operating Systems Review 07/2006; 40:93­101. DOI:10.1145/1151374.1151393
`
`"Moving reflective mechanisms from the programming to the system level is a relatively recent trend [3] [7]. Most of the
`existing reflective languages support reflection through the introduction of linguistic hooks 3 . "
`
`Conference Paper: Implementing the essence of reflection: a reflective run­time environment.
`Massimo Ancona · Walter Cazzola
`[Show abstract]
`
`Source
`
`Proceedings of the 2004 ACM Symposium on Applied Computing (SAC), Nicosia, Cyprus, March 14­17, 2004; 01/2004
`
`"The former approach is used for Java extensions such as Kava [17] and Javassist [2]. The latter is adopted by languages such
`as OpenC++ [1] and OpenJava [15] "
`
`Conference Paper: Introducing distribution into applications: a reflective approach for transparency and dynamic fine­grained object
`allocation
`A. Di Stefano · G. Pappalardo · E. Tramontana
`[Show abstract]
`
`Computers and Communications, 2002. Proceedings. ISCC 2002. Seventh International Symposium on; 02/2002
`
`Source
`
`Note: This list is based on the publications in our database and might not be exhaustive.
`
`Show more
`
`SIMILAR PUBLICATIONS
`
`Side effect monitoring for Java using bytecode rewriting
`Manuel Geffken, Peter Thiemann
`
`Mobile Process Resumption In Java Without Bytecode Rewriting
`Matthew Sowders, Jan Baekgaard Pedersen
`
`Optimistic­parallel process­oriented DES in Java using Bytecode Rewriting
`Andreas Kunert
`
`© 2008‐2015 researchgate.net. All rights reserved.
`
`About us ·  Contact us ·  Careers ·  Developers ·  News ·  Privacy ·  Terms   |   Advertising  ·  Recruiting
`
`http://www.researchgate.net/publication/221141803_Kava_­_A_Reflective_Java_Based_on_Bytecode_Rewriting
`
`2/2
`
`Blue Coat Systems - Exhibit 1008 Page 2
`
`

`
`See discussions, stats, and author profiles for this publication at: http://www.researchgate.net/publication/221141803
`
`Kava - A Reflective Java Based on Bytecode
`Rewriting.
`
`CONFERENCE PAPER · JANUARY 1999
`
`DOI: 10.1007/3-540-45046-7_9 · Source: DBLP
`
`CITATIONS
`41
`
`READS
`16
`
`2 AUTHORS, INCLUDING:
`
`Ian Welch
`Victoria University of Wellington
`
`91 PUBLICATIONS 730 CITATIONS
`
`SEE PROFILE
`
`Available from: Ian Welch
`Retrieved on: 24 September 2015
`
`Blue Coat Systems - Exhibit 1008 Page 3
`
`

`
`Kava - A Reflective Java based on Bytecode
`Rewriting
`
`Ian Welch and Robert J. Stroud
`
`University of Newcastle-upon-Tyne, United Kingdom NE1 7RU
`{I.S.Welch, R.J.Stroud}@ncl.ac.uk,
`WWW home page:http://www.cs.ncl.ac.uk/people/
`{I.S.Welch, R.J.Stroud}
`
`Abstract. Current implementations of reflective Java typically either
`require access to source code, or require a modified Java platform. This
`makes them unsuitable for applying reflection to Commercial-off-the-
`Shelf (COTS) systems. The high level nature of Java bytecode makes
`on-the-fly rewritings of class files feasible and this has been exploited by
`a number of authors. However, in practice working at bytecode level is
`error prone and leads to fragile code. We propose using metaobject pro-
`tocols in order to specify behavioural changes and use standard bytecode
`rewritings to implement the changes. We have developed a reflective Java
`called Kava that provides behavioural runtime reflection through the use
`of bytecode rewriting of Java classes. In this paper we discuss the binary
`rewriting approach, provide an overview of the Kava system and provide
`an example of an application of Kava.
`
`1 Introduction
`
`We are interested in the problems of applying non-functional requirements to
`Commercial Off-the-Shelf (COTS) software components. In an environment such
`as Java, components are usually supplied in a compiled form without source code,
`and can be integrated into a system at runtime.
`Metaobject protocols [12] offer a principled way of extending the behaviour
`of these components. Metaobjects can encapsulate the behavioural adaptations
`necessary to satisfy desirable non-functional requirements (NFRs) such as fault
`tolerance or application level security [1][2][18][19] transparently at the met-
`alevel. Ideally we want to apply these metaobjects to compiled code that executes
`on a standard Java platform.
`The Java 2 Reflection package java.lang.reflect provides introspection,
`dynamic dispatch and the ability to generate proxies for classes on-the-fly. How-
`ever, this is not sufficient to build a rich metaobject protocol that can be applied
`transparently. There are a number of alternative extensions for Java that provide
`more powerful and more transparent reflection. However, they all have flaws that
`do not make them applicable to the problem of adapting components. These flaws
`include the requirement for customised Java Virtual Machines (JVMs), limited
`reflective capabilities, or weak non-bypassability. The term non-bypassability
`
`Blue Coat Systems - Exhibit 1008 Page 4
`
`

`
`refers to the binding between the base level and the meta level. For a number of
`NFRs such as security the meta level should never be able to be bypassed. This
`is what we term strong non-bypassability. However, in a number of implemen-
`tations the techniques used to implement the bindings are easily bypassed. We
`refer to this as weak non-bypassability.
`We have produced our own implementation of a reflective extension for Java
`called Kava that provides a rich metaobject protocol, requires only a standard
`JVM and provides strong non-bypassability. Kava implements a runtime be-
`havioural metaobject protocol through the application of standard byte code
`rewritings, and behavioural adaptation is implemented using Java metaobject
`classes. This is to be distinguished from structural reflection where a metaobject
`protocol provides an interface for a programmer who wants to change the actual
`structure of an object.
`The rest of the paper is organized as follows. In section two we provide a
`review of different approaches to implementing reflection in Java. Section three
`introduces the Kava metaobject protocol. Section four explains the byte code
`rewriting approach. Section five gives an example of an application of Kava.
`Finally section six provides some conclusions about the general approach.
`A prototype implementation of Kava has been completed and is available
`from http : //www.cs.ncl.ac.uk/people/i.s.welch/kava.
`
`2 Review of Reflective Java Implementations
`
`In this section we briefly review a number of reflective Java implementations
`and attempt to categorize them according to the point in the Java class lifecycle
`that reflection is implemented.
`The Java class lifecycle is as follows. A Java class starts as source code that
`is compiled into byte code, it is then loaded by a class loader into the JVM for
`execution, where the byte code is further compiled by a Just-In-Time compiler
`into platform specific machine code for efficient execution.
`Different reflective Java implementations introduce reflection at different
`points in the lifecycle. The point at which they introduce reflection charac-
`terizes the scope of their capabilities. In order to realise reflective control by
`a metalevel the baselevel system is modified through the addition of traps on
`operations. These traps are known as metalevel interceptions [26]. For exam-
`ple, in Reflective Java method calls sent to the base object are brought under
`control of an associated meta object by trapping each method call to the base
`object. These traps are added at the source code stage of the lifecycle making it
`necessary to have access to the source code. In contrast MetaXa adds the traps
`into the JVM, here the implementation of the dispatch mechanism of the JVM
`is changed in order to take control over method calls. As the traps are added
`to the runtime system source code is no longer required. The drawback of this
`approach is that unlike Reflective Java a specialized JVM must be used.
`Table 1 summarizes the features of the different reflective Java implementa-
`tions.
`
`Blue Coat Systems - Exhibit 1008 Page 5
`
`

`
`Table 1. Comparison of Reflective Java Implementations
`
`Description
`
`Capabilities
`
`Restrictions
`
`Reflective
`Point
`Java
`in Lifecycle
`Source Code Reflective
`Java [25]
`
`Compile Time OpenJava [21]
`
`Preprocessor.
`
`Compile-time
`metaobject
`protocol.
`
`Byte Code
`
`Bean
`Extender [9]
`
`Byte code
`preprocessor.
`
`Dynamic switching
`of metaobjects.
`Intercept method
`invocations.
`
`Can intercept wide
`range of operations,
`and extends language
`syntax.
`No need to have
`access to source
`code.
`
`Can’t make a
`compiled class
`reflective,
`requires access to
`source code.
`Requires access to
`source code.
`
`Restricted to Java
`Beans, requires
`offline
`preprocessing.
`
`Dalang [22][23]
`
`Byte code
`rewriting as late.
`as loadtime
`
`No need to have
`access to source
`code.
`
`Javassist [4]
`
`Byte code
`rewriting as late.
`as loadtime.
`
`No need to have
`access to source
`code.
`
`Runtime
`
`MetaXa [7]
`
`Reflective
`JVM.
`
`Can intercept wide
`range of operations,
`Can be dynamically
`applied.
`
`Suffers from known
`problems with class
`wrapper approach -
`delegation, identity, weak
`encapsulation etc.
`
`Focus on
`metaobject protocol
`for structural adaptation.
`Weak encapsulation.
`Custom JVM.
`
`Rjava [8]
`
`Guarana [15]
`
`Wrapper based
`reflection allowing
`dynamic
`binding.
`
`Intercepts method
`invocations, and
`allows dynamic
`extension of classes.
`
`Custom JVM -
`addition of new
`byte code.
`
`Reflective
`kernel
`supported by
`modified JVM.
`
`Interception of
`message sends, state
`access and supports
`metaobject
`composition.
`
`Custom JVM.
`
`java.lang.reflect [20] Reflective capabilities Runtime introspection, Overall introspection
`part of the standard dynamic dispatch, and rather than behavioural
`Java development kit. on-the-fly generation
`or structural reflection.
`of proxies.
`Can take advantage
`of facilities present
`in the native
`platform. No need
`for access to
`source code.
`
`Just-in-time OpenJIT [14]
`Compilation
`
`Compile-time
`metaobject
`protocol for
`compilation to
`machine
`language.
`
`No behavioural
`metaobject
`protocol.
`
`Blue Coat Systems - Exhibit 1008 Page 6
`
`

`
`All these implementations have drawbacks that make them unsuitable for use
`with compiled components or in a standard Java environment where the purpose
`is to add security. Some require access to source code, others are non-standard
`because they make use of a modified Java platform, and none of the portable
`approaches support strong non-bypassability.
`In contrast, Kava does not require access to source code because it is based
`on bytecode rewriting, doesn’t require a non standard Java environment and
`provides a rich set of capabilities. It also provides strong non-bypassability. Most
`implementations add traps through renaming of classes, or of methods which
`means that it may be possible to call the original methods and therefore bypass
`the meta layer. However, Kava actually adds the traps directly into the method
`bodies avoiding this problem.
`Recently a new reflective Java called Javassist has been developed that pro-
`vides a metaobject protocol for structural modification of Java classes and sup-
`ports a simple metaobject protocol for behavioural reflection. It is the most
`similar in character to Kava of all the reflective Java implementations. However,
`it uses method renaming to implement the trapping of method calls and there-
`fore doesn’t support strong non-bypassability. It also currently doesn’t support
`the same range of reflective capabilities of Kava.
`
`3 Kava Metaobject Protocol
`
`The Kava metaobject protocol provides an interface to the Java runtime ob-
`ject model that gives programmers the ability to modify a Java application’s
`behaviour safely and incrementally. Each object is causally connected with a
`unique metaobject. The metaobject provides a representation of the structure
`of the object, and of the behaviour of the object. Metaobjects are implemented
`in the Java language in the same way that objects are implemented. However,
`bytecode rewriting techniques are used to create the causal connection between
`the meta and base levels. This approach allows Kava is be used in a standard
`Java environment, means that it can be applied to compiled Java classes and
`allows for a rich metaobject protocol. The idea of bytecode rewriting is not new
`but using it to implement behavioural reflection is a new idea.
`When Kava creates a reflective Java class then a binding is created between
`the class and a metaobject class (or metaclass). In Kava a metaobject class is
`a Java class that implements the interface Metaobject. Whenever an instance
`of the class is created then a unique instance of the metaobject implementation
`is also created. By creating different metaobject implementations the program-
`mer can create standard redefinitions of the Java runtime object model. These
`different implementations are bound to base level objects in order to customize
`the behaviour of the base level objects.
`In the following sections we first look at the aspects of base level behaviour
`under the control of the metaobject protocol, and then at how the binding be-
`tween objects and metaobjects is specified.
`
`Blue Coat Systems - Exhibit 1008 Page 7
`
`

`
`3.1 Scope of Metaobject Protocol
`
`The aspects of base level behaviour that can be redefined in Kava are:
`
`– Method calls to base objects.
`– Method calls from base objects.
`– State access by base objects.
`– Creation of new instances by base objects.
`– Initialisation of base objects.
`– Finalization of base objects.
`
`The metaobject associated with the base object traps the base level be-
`haviours and specifies what will happen before the behaviour and what will hap-
`pen after the behaviour. For example, when a base object makes a call to method
`then the method beforeSendMethod is invoked. By redefining beforeSendMethod
`behaviour to take place before the call is dispatched can be defined. An example
`is shown below. In this example the target of the call, the method itself and the
`arguments on the call stack are reified respectively as a Reference, Method and
`array of Value.
`
`import kava.*;
`public boolean beforeSendMethod(
`Reference target, Method method, Value[] arguments)
`
`{
`
`}
`
`System.out.println("invoking " + method.getName());
`return Constants.INVOKE_BASELEVEL;
`
`Here a tracing message is displayed - the name of the method being invoked.
`The metalevel then allows the base level behaviour to take place. This is indicated
`by returning Constants.INVOKE BASELEVEL from the method.
`Kava also supports extended introspection on the structure of the object.
`The following aspects of the structure can be determined and manipulated using
`Kava :
`
`– Binding between Metaobject and Object.
`– State of the Object.
`
`The implementor of the metaobject can choose to make the metalevel visible
`to the baselevel by implementing the getMeta method and returning a pointer
`to the metaobject. The default implementation should be to raise a runtime
`exception if the base level attempts to access the metalevel directly. In the case
`of implementing security using metaobject protocols we would not want the
`metalevel to be visible. However, if we were implementing distribution then we
`may want to access the metalevel in order to adjust parameters such as timeout.
`The implementor may also choose to allow the binding between the metaob-
`ject and object to be changed. Again the default implementation should be to
`raise a runtime exception. However, the implementor can define the method
`
`Blue Coat Systems - Exhibit 1008 Page 8
`
`

`
`setMeta to allow the binding to be changed from one metaobject to another
`metaobject.
`The Kava metaobject protocol also supports extended introspection. It allows
`access to and adjustment of base level state. This is under the control of the Java
`2 security model so a security administrator can allow or prevent reflective access
`to state.
`
`3.2 Binding Specification
`
`Kava uses a simple binding language to specify which metaobjects are bound
`to which base level objects or classes. This allows binding information to be
`removed from the metaobject implementation and reasoned about separately.
`This adds to the separation of concerns and promotes reuse. It is also more
`appropriate for situations where source code may not be available, for example
`with COTS components.
`A metaclass definition defines what aspects of the Java object model a meta-
`class redefines. Only those aspects redefined in the binding specification will be
`redefined at the metalevel irrespective of whether the metaclass implementation
`has defined methods for handling other aspects of the base level. This allows a
`fine granularity for the late binding between the meta and base level. For exam-
`ple, a tracing metaobject may be interested in all method invocations made by
`an object or only specific method invocations. The binding specification allows
`the method to be specified by name, or a wildcard to be used (any-method for
`any method, any-class for any class and any-desc for any parameter list) to
`indicate that all methods are of interest. An example of a binding between the
`MetaTrace class and the methods notify and setObserver of the class Test
`is given below. This means that each instance of Trace will be bound to an
`instance of MetaTrace.
`
`metaclass kava.MetaTrace
`{
`INTERCEPT SEND_METHOD( any-class, "notify" , any-desc );
`INTERCEPT SEND_METHOD( any-class, "setObserver" , any-desc );
`
`} c
`
`lass Test metaclass-is kava.MetaTrace;
`
`4 Bytecode Rewriting
`
`The Kava metaobject protocol is implemented using the technique of byte code
`rewriting. Byte code rewriting has become an established technique for extend-
`ing Java both syntactically and behaviourally. For example it has been used to
`support parametric types [3] and add resource consumption controls to classes
`[6]. Generic frameworks for transforming byte code such as JOIE [5] and Bi-
`nary Component Adaptation [10] have been developed to make coding byte code
`rewriting easier. However, as pointed out by the authors of JOIE, most of these
`
`Blue Coat Systems - Exhibit 1008 Page 9
`
`

`
`frameworks lack a high-level abstraction for describing the behavioural adapta-
`tions. This makes coding adaptations difficult as it requires a detailed knowledge
`of byte code instructions and of the structure of class files. Binary Component
`Adaptation does support a form of a higher-level abstraction in that it has the
`concept of deltaClasses that describe structural changes to a class file in terms of
`methods for renaming methods, mixin type methods, etc. However, the purpose
`of the framework is to support software evolution rather than behavioural adap-
`tation. This means that the focus is on adding, renaming or removing methods
`and manipulating the type hierarchy in order to adapt ill-fitting components to
`work together rather than describing behavioural adaptation.
`The Kava metaobject protocol provides a high-level abstraction for adapta-
`tion of component behaviour that specifies the change to behaviour in terms of
`the Java object model and is implemented using byte code rewriting. We exploit
`the JOIE framework to simplify the implementation of this metaobject protocol.
`The framework frees us from dealing with technical details such as maintaining
`relative addressing when new byte codes are inserted into a method, or determin-
`ing the number of arguments a method supports before it has been instantiated
`as part of a class.
`As byte code instructions and the structure of the class file preserve most of
`the semantics of the source code we can use byte code rewriting to implement
`metalevel interceptions for a wide range of aspects of the Java Object model
`such as caller and receiver method invocation, state access, object formalization,
`object initialisation and some aspects of exception handling. Like compile-time
`reflection we reflect upon the structure of the code in order to implement reflec-
`tion. However, we work at a level much closer to the Java machine than most
`compile-time approaches that deal with the higher-level language. Although this
`means we cannot extend the syntax of the higher-level language it does mean
`that we can implement some kinds of reflection more easily than in a traditional
`compile-time MOP. For example, in the application of OpenC++ version 2 to
`adding fault tolerance in the form of checkpointing CORBA applications [11]
`data flow analysis is performed on the source code to determine when the state
`of the object is updated. With Kava no such analysis would be necessary; all that
`would be required is to intercept the update of state of an object by changing
`the behaviour of the update field operation in the Java runtime object model.
`When an update was done a flag could be set indicating that the current state
`should be checkpointed.
`Also since we are often dealing with compiled classes we do not have ac-
`cess to the source code in order to annotate it. There is also an argument that
`source code annotations are not necessarily a good idea especially when different
`annotation schemes are used together.
`By transforming the class itself we address the problems introduced by the
`separation of base class and class wrapper (see earlier paper). Instead, standard
`byte code rewritings are used to wrap individual methods and even bytecode
`instructions. These micro-wrappers will switch control from the baselevel to
`metalevel when the methods or byte code instructions are executed at runtime.
`
`Blue Coat Systems - Exhibit 1008 Page 10
`
`

`
`The metalevel is programmed using standard Java classes. The metalevel allows
`the customisation of the Java object model at runtime. The scope of the cus-
`tomisation is be determined by which methods and byte code instructions are
`wrapped at load time, but the exact nature of the customisation is adjustable
`at runtime.
`Byte code rewriting can either be applied at loadtime through the use of an
`application level classloader [13] or prior to loadtime by directly rewriting class
`files.
`To provide a flavour of this approach we provide an example of the wrapping
`of access to a field of a base level class. Due to space constraints we present this
`at a high level using source code instead of byte code. Consider the following
`field access:
`
`myGreeting = "Hello " + name;
`
`At the byte code level this is rewritten to:
`
`import kava.*;
`
`Reference target = new Reference(this);
`Field field = newField("myGreeting");
`Value fieldValue = Value.newValue("Hello " + name);
`
`if (meta.beforePutField(target, field, fieldValue)
`== Constants.INVOKE_BASELEVEL)
`
`{
`
`} m
`
`helloWorld = (String)fieldValue.getObject();
`
`eta.afterPutField(target, field, fieldValue);
`
`In this example the first line of code specifies that the field belongs to this
`instance of the base class, the second line specifies the field being updated,
`and the third line specifies the value the field is being updated with. Then
`beforePutField method of the associated metaobject is invoked with param-
`eters representing the field ("helloWorld"), and the marshalled value. At the
`metalevel the value may be modified in order to adjust the final value that is
`stored in the field. Alternatively the update of field could be suppressed by re-
`turning a Constants.SUPPRESS BASE in which case the base level action does
`not take place. The last line calls the afterPutField method of the associated
`metaobject with the same parameters as the initial call to the metalevel.
`
`5 Application of Kava
`
`Kava has wide application potential and should prove well suited to the cus-
`tomising the behaviour of COTS applications that are built from dynamically
`
`Blue Coat Systems - Exhibit 1008 Page 11
`
`

`
`loaded components. It provides a high-level abstraction for implementing be-
`havioural adaptations that are expressed as bytecode rewritings. This means
`that it can be used to reimplement in a principled way behavioural adaptations
`that have already been implemented through byte code rewriting e.g. enforcing
`resource controls on applications, instrumentation of applications, visualization
`support etc. The advantage of using Kava would be that these adaptations could
`be combined as required since they have been built using a common abstraction.
`In this section we provide an example application of Kava : to prevent down-
`loaded applets from mounting a particular class of denial-of-service attack.
`In [16] examples of using bytecode rewriting techniques for protecting against
`malicious attacks are discussed. In particular the authors provide an example of
`how bytecode rewriting can be used to protect against denial-of-service caused
`by a window consuming attack.
`The basic idea is that an applet can crash the host system by creating more
`windows than the windowing system can handle. In order to protect against this
`attack the system should track the number of windows created and either block
`or throw an exception when a predetermined limit is exceeded. The class used
`to generate the top-level windows is the Java library class Frame.
`The solution provided in [16] is to prevent an applet from invoking the con-
`structor methods of the Frame class more than a predefined number of times.
`They achieve this by subclassing Frame to create Safe$Frame. Safe$Frame is
`implemented in such a way that it counts the number of top-level windows cre-
`ated and blocks further creation of windows if the predefined limit is exceeded.
`Then every application class downloaded with the applet is checked for refer-
`ences to Frame. When a reference is found then it is replaced by a reference to
`Safe$Frame. The bytecode rewriting is done within a proxy server that inter-
`cepts requests for applets.
`This approach has the advantage that it is transparent and can work with
`COTS browsers. The main drawback to the technique that it is difficult to gen-
`eralize to other classes. For example, another denial-of-service attack might rely
`upon the applet creating more threads than the system can handle. This would
`require the creation by hand of a Safe$Thread class that monitored and con-
`trolled the creation of Thread instances.
`Kava provides a higher level approach to applying such safety mechanisms.
`The high level approach is to describe a mechanism for limiting the creation of
`new instances of monitored classes such as Frame or Thread. Using Kava this is
`done by creating an implementation of a Metaobject that performs the resource
`monitoring. A simplified implementation is shown below:
`
`import kava.*;
`
`public class ResourceMonitor implements Metaobject
`{
`
`public void beforeCreation(Reference target, Value[] arguments)
`{
`
`Blue Coat Systems - Exhibit 1008 Page 12
`
`

`
`incrementUsage(target);
`if (exceededMaximum(target)
`{
`
`throw new RuntimeException("resource count exceeded by " +
`target.getClass());
`
`}
`
`} .
`
`..
`
`}
`
`The method beforeCreation redefines how new instances are created. First,
`it calls a method incrementUsage that increments a global count of the number
`of instances of the that class and its superclasses. We count superclasses as an
`instance of a subclass of a monitored class might be created. Then it calls a
`method exceededMaximum that checks if the maximum limit for the number
`of instances of any monitored class has been exceeded. If the limit has been
`exceeded then a runtime exception is thrown and the execution of the applet
`halts.
`The advantage of this approach over the original approach is more general
`and doesn’t require manual generation of new classes if a new class is to be
`monitored. In [24] we propose a even more general reflective security model for
`resource consumption control.
`
`6 Conclusions
`
`Ideally, a reflective extension for Java that is intended to be used to adapt the
`runtime behaviour of COTS components should not require access to source
`code, or modifications to the Java platform, and should provide strong non-
`bypassability. Unfortunately, existing reflective extensions that we have reviewed
`do not meet these requirements and provide the scope of control required.
`We have implemented a system called Kava that overcomes these problems
`by using bytecode rewriting in order to establish a causal connection between
`metaobjects and objects. It provides a higher level abstraction for specifying
`changes to the behaviour of objects than is provided by currently available byte-
`code rewriting toolkits. It addresses some reflective capabilities not handled by
`some extensions such as the ability to redefine how base level objects call other
`base level objects, and offers strong non-bypassability.
`To the best of our knowledge Kava was the first reflective Java extension
`to make use of bytecode rewriting in order to implement behavioural reflection.
`Subsequently there have been similar developments such as Javassist although
`these lack some of the capabilities of Kava and do not support strong non-
`bypassability.
`We are currently using the Kava prototype to implement a reflective security
`metalevel for Java applications. Current versions of Kava are available from
`http : //www.cs.ncl.ac.uk/people/i.s.welch/kava.
`
`Blue Coat Systems - Exhibit 1008 Page 13
`
`

`
`Acknowledgements
`
`This work has been supported by the UK Defence Evaluation Research Agency,
`grant number CSM/547/UA.
`
`References
`
`[1] Ancona M., Cazzola W. and Fernandez E. B. : Reflective Authorization Systems:
`Possibilities, Benefits and Drawbacks. In Jan Vitek and Christian Jensen, editors,
`Secure Internet Programming: Security Issues for Distributed and Mobile Objects,
`Lecture Notes in Computer Science 1606. Springer-Verlag, 1999.
`[2] Benantar M., Blakley B., and Nadain A. J. : Approach to Object Security in
`Distributed SOM. IBM Systems Journal, Vol35, No.2, (1996).
`[3] Agesen, O., Freund S., and Mitchell J. C.: Adding Type Parameterization. In
`Proceedings of OOPSLA 1997, Atlanta,Georgia (1997).
`[4] Chiba, S. : Load-time structural reflection in Java. To be published in proceedings
`of ECOOP2000 (2000).
`[5] Cohen, G. A., and Chase, J. S. : Automatic Program Transformation with JOIE.
`Proceedings of USENIX Annual Technical Symposium (1998).
`[6] Czaijkowski, G. and von Eicken, T. JRes: A Resource Accounting Interface for
`Java. Proceedings of OOPSLA 1998 (1998).
`[7] Golm, M. : Design and Implementation of a Meta Architecture for Java. MSc
`Thesis (1997). University of Erlangen.
`[8] Guimares, J. : Reflection for Statically Typed Languages. Proceedings of ECOOP
`1998 (1998).
`[9] IBM. Bean Extender Documentation, version 2.0 (1997).
`[10] Keller, R. and Holzle, U. : Binary Component Adaptation. Proceedings of ECOOP
`1998 (1998).
`[11] Killijian M-O. , Fabre J-C. , Ruiz-Garci