Declaration of Mel DeSart
`
`I, Mel beSart, declare as follows:
`
`I am the Head of the University of Washington Engineering Library, located at Box
`1.
`352170, Seattle, Washington 98195. I have held the position as Head ofthe Engineering Library
`since I was hired in March, 2000. As Head, I have personal knowledge of the Engineering
`Library's normal business practic~s, and based on the training I received upon beginning my
`...
`employment and the Library's business, records, have· personal knowledge that the practices
`described herefn were in effect throughout the year 2000, including at the times relevant to the
`publication discussed in this Declaration. I am over the age of majority and make this declaration
`of my own personal knowledge.
`·
`
`In·the January 2000 time frame, the University of Washington Engineering Library
`2.
`would regularly receive periodicals into its collections. Upon receipt of a periodical issue, the
`staff member responsible for processing newly received periodical issues would stamp the
`publication with an "Engineering Periodicals" stamp, and, if the title was one chosen for display
`in the Engineering Library Display Periodicals area, an additional sticker and date. The Library's
`hormal business practice was to receive new items and make them available to the public within
`a. few days of when they were received, and certainly within one week.
`
`'
`
`According to the Library's business records and my personal knowledge of the Library's
`3.
`regular practices at the time, Operating Systems Review, Vol. 33, No.5, December 1999,
`containing the article "Design arid implementation of a distributed virtual machine for netw6rked
`computers" by Emin Gun Sirer, Robert Grimm, Arthur J. Gregory, and Brian N. Bershad, was
`received by th_e Universi_ty of Washington Libraries on January 31, 2000, and was then re(cid:173)
`directed to the Engineering Library. The date stamp added to the "Engineering Library Display
`Periodical Non-circulating until:" sticker affixed to the issue indicates the date the issue w&s to
`have been removed from the display periodical area, in this case March 8, 2000. Individual
`issues of periodical titles that were to be displayed in the Engineering Library Display Periodical
`area were displayed for one month. Therefore the issue would have be~n added to the display
`periodical area and made publicly available one month prior to the date stamped on the sticker,
`or February 8, 2000. A copy of the first few pages of the periodica_l is~ue as it is maintained in
`the Library's collection, plus the article in question, is attached as Exhibit A.
`
`I declare under penalty ofperjufy under the laws of the United States of America that this
`4.
`declaration is trtle, complete, and accurate to the best of my knowledge. I further acknowledge
`that willful false statements and the like are punishable by fine or imprisonment, or both (18
`U.S.C. § 1001).
`
`Execu~d at Sea!;!jfj!_on, on April IS, 2015.
`
`M(l~
`
`Head, University of Washington Engineering Library
`
`PALO ALTO NETWORKS Ex. 1036 Page 1
`
`

`
`
`
`EXHIBIT A
`
`PALO ALTO NETWORKS Ex. 1036 Page 2
`
`

`
`10.1G
`00:3
`
`06~1 ------------------------------------~
`T
`@PERATING
`SYSTEMS
`REVIEW
`
`A Publication of the
`Association for Computing Machinery
`Special Interest Group on Operating Systems
`
`ENGINEERING LIBRARY
`DISPLAY PERIODICAL
`Non-circulating until:
`
`MAR 0 8 ' 00
`
`December, 1999
`
`Volume 33,
`
`Number 5
`
`Proceedings of the
`
`17th ACM Symposium on
`Operating Systems Principles
`(SOSP'99)
`
`December 12-15, 1999
`Kiawah Island Resort, near Charleston, South Carolina
`
`I'ER IOOI\ALS
`
`I '
`\.J.
`
`\'
`'
`
`1 I)LOOO
`
`PALO ALTO NETWORKS Ex. 1036 Page 3
`
`

`
`Proceedings of the
`
`17th ACM Symposium on
`Operating Systems Principles
`(SOSP'99)
`
`December 12-15, 1999
`Kiawah Island Resort, near Charleston, South Carolina
`
`Sponsored by ACM SIGOPS
`(Association for Computing Machinery special interest group in operating systems).
`
`Supported by:
`
`COMPAQ
`
`Lucent Technologies 0
`
`Be4\Ubsii'Y'cJwtioN
`
`COMPAQ Research
`
`Lucent Bell Laboratories
`
`Mercury Computer Systems
`
`rJ;;;- HEWLETT "
`~/:.. PACKARD
`I Expanding Possibilities J
`Hewlett-Packard
`Laboratories
`
`----
`----
`-----_ _ . . - ·-
`- ------------
`- -- ---
`
`IBM Research
`
`1&Search
`
`Microsoft Research
`
`PALO ALTO NETWORKS Ex. 1036 Page 4
`
`

`
`The Association for Computing Machinery, Inc.
`1515 Broadway
`New York, New York 10036
`
`Copyright© 1999 by the Association for Computing Machinery, Inc. (ACM). Permission to make digital
`or hard copies of portions of this work for personal or classroom use is granted without fee provided that
`the copies are not made or distributed for profit or commercial advantage and that copies bear this notice
`and the full citation on the first page. Copyrights for components of this work owned by others than ACM
`must be honored. Abstracting with credit is permitted.
`
`To copy otherwise, to republish , to post on servers or to redistribute to lists, requires prior specific
`permission and/or a fee. Request permission to republish from: Publications Dept. ACM, Inc. Fax +1-212-
`869-0481 or E-mail permissions@acm.org.
`
`For other copying of articles that carry a code at the bottom of the first or last page, copying is permitted
`provided that the per-copy fee indicated in the code is paid through the Copyright Clearance Center, 222
`Rosewood Drive, Danvers, MA 01923.
`'•
`
`ACM ISBN: 1-58113-140-2
`
`Additional copies may be ordered prepaid from:
`
`ACM Order Department
`P.O. BOX 11405
`Church Street Station
`New York, NY 10286-1405
`
`Phone:
`
`Fax:
`E-mail:
`
`+ 1-800-342-6626 (U.S.A. and Canada)
`+ 1-212-626-0500 (all other countries)
`+ 1-212-944-1318
`acmhelp@acm.org
`
`ACM Order Number: 534990
`
`Printed in the U.S.A.
`
`11
`
`PALO ALTO NETWORKS Ex. 1036 Page 5
`
`

`
`Design and implementation of a distributed virtual
`machine for networked computers
`
`Emin Gun Sirer, Robert Grimm, Arthu r J. Gregory, Brian N. Bershad
`
`University of Washington
`Department of Computer Science and Engineering
`
`{egs, rgrimm, artjg, bershad}@cs.washington.edu
`
`Abstract
`This paper describes the motivation, architecture and
`performance of a distributed virtual machine (DVM) for
`networked computers. DVMs rely on a distributed service
`architecture to meet the manageability, security and
`uniformity requirements of large, heterogeneous clusters of
`networked computers. In a DVM, system services, such as
`verification,
`security
`enforcement,
`compilation and
`optimization, are factored out of clients and located on
`powerful network servers. This partitioning of system
`functionality reduces resource requirements on network
`clients, improves site security through physical isolation
`and
`increases
`the manageability of a
`large and
`heterogeneous network without sacrificing performance.
`Our DVM implements the Java virtual machine, runs on
`x86 and DEC Alpha processors and supports existing Java(cid:173)
`enabled clients.
`
`1. Introduction
`Virtual machines (VMs) have the potential to play an
`tomorrow's networked computing
`important
`role
`in
`environments. Current trends indicate that future networks
`will likely be characterized by mobile code [Thorn 97],
`large numbers of networked hosts per domain [ISC 99] and
`large numbers of devices per user that span different
`hardware architectures and operating systems [Hennessy
`99, Weiser 93]. A new class of virtual machines,
`exemplified by systems such as Java and Inferno [Lindholm
`& Yellin 96, Dorward et al. 97], has recently emerged to
`meet the needs of such an environment. These modern
`virtual machines are compelling because they provide a
`
`Permission to make digital or hard copies of all or part of this
`work for personal or classroom use is granted without fee
`provided that copies are not made or distributed for profit or
`commercial advantage, and that copies bear this notice and the
`full citation on the first page. To copy otherwise, to republish. to
`post on servers or to redistribute to lists, requires prior specific
`permission and/or a fee.
`SOSP-17 12/1999 Kiawah Island, SC
`© 1999 ACM 1-58113-140-2/99/0012 ... $5 .00
`
`platform-independent binary format, a strong type-safety
`guarantee that facilitates the safe execution of untrusted
`code and an extensive set of programming interfaces that
`subsume those of a general-purpose operating system. The
`ability to dynamically load apd safely execute untrusted
`code has already made
`the Java virtual machine a
`ubiquitous component in extensible systems ranging from
`web browsers and servers to database engines and office
`applications. The platform independence of modern virtual
`machines makes it feasible to run the same applications on
`a wide range of computing devices, including embedded
`systems, handheld organizers,
`conventional desktop
`platforms and high-end enterprise servers. In addition, a
`single execution platform offers the potential for unified
`management services, thereby enabling a small staff of
`system administrators to effectively administer thousands or
`even hundreds of thousands of devices.
`While modern virtual machines offer a promising
`future, the present is somewhat grim. For example, the Java
`virtual machine, despite
`its commercial success and
`ubiquity, exhibits major shortcomings. First, even though
`the Java virtual machine was explicitly designed for
`handheld devices and embedded systems, it has not been
`widely adopted
`in
`this domain due
`to
`its excessive
`processing and memory requirements [Webb 99]. Second, it
`is the exception, rather than the rule, to find a secure and
`reliable Java virtual machine [Dean et al. 97] . And third,
`rather
`than simplifying system administration, modern
`virtual machines, like Java, have created a substantial
`management problem [McGraw & Felten 96], leading many
`organizations to simply ban virtual machines altogether
`[CERT 96].
`We assert that these symptoms are the result of a much
`larger problem that is inherent in the design of modern
`virtual machines. Specifically, state of the art modern
`virtual machines rely on the monolithic architecture of their
`ancestors [Goldberg 73, Popek & Goldberg 74, IBMVM
`86, UCI 96]. All service components in a monolithic VM,
`such as verification, security management, compilation and
`optimization, reside locally on the host intended to run the
`
`202
`
`PALO ALTO NETWORKS Ex. 1036 Page 6
`
`

`
`VM applications. Such a monolithic service architecture
`exhibits four shortcomings:
`l. Manageability: Since each modern virtual machine
`is a completely independent entity, there is no
`central point of control
`in an organization.
`Transparent and comprehensive methods
`for
`distributing security upgrades, capturing audit trails
`and pruning a network of rogue applications are
`difficult to implement.
`2. Performance: Modern virtual machine services,
`such as authentication, just-in-time compilation and
`verification, have
`substantial processing and
`memory requirements. Consequently, monolithic
`systems are not suitable for hosts, such as
`embedded devices, which lack the resources to
`support a complete virtual machine.
`3. Security: The trusted computing base (TCB) of
`modern VMs
`is not small, well-defined, or
`physically isolated from application code. A large
`TCB with ill-defined boundaries makes it difficult
`to construct and certify secure systems [Saltzer &
`Shroeder 75]. The lack of separation between
`virtual machine components means that a flaw in
`any component of the virtual machine can place the
`entire machine at risk [McGraw & Felten 99].
`Further, co-location of VM services has resulted in
`non-modular systems that can exhibit complex
`for
`interactions, as observed
`inter-component
`monolithic operating systems [Accetta et al. 86,
`Bershad et al. 95, Engler et al. 95].
`are
`4. Scalability: Monolithic virtual machines
`difficult to port across the diverse architectures and
`platforms found in a typical network [Seltzer 98].
`In addition, they have had problems scaling over
`the different usage requirements encountered in
`organizations [Rayside et al. 98].
`The goal of our research is to develop a virtual machine
`system that addresses the manageability, performance,
`requirements of networked
`secunty and
`scalability
`computing. In addition, such a system should preserve
`compatibility with the wide base of existing monolithic
`virtual machines in order to facilitate deployment. To this
`end, we focus on implementation techniques that preserve
`the external interfaces [Lindholm & Yellin 96] and platform
`APis [Gosling & Yellin 96] of existing virtual machines.
`the problems of monolithic virtual
`We address
`machines with a novel distributed virtual machine
`architecture based on service factoring and distribution. A
`distributed service architecture factors virtual machine
`services into logical components, moves these services out
`of clients and distributes them throughout the network. We
`have designed and
`implemented a distributed virtual
`machine for Java based on this architecture. Our DVM
`
`includes a Java runtime, a verifier, an optimizer, a
`performance monitoring service and a security manager. It
`differs from existing systems in that these services are
`factored
`into well-defined components and centralized
`where necessary.
`The rest of the paper is structured as follows. The next
`section describes our architecture and provides an overview
`of our system. Section 3 describes the implementation of
`conventional
`virtual machine
`services
`under
`our
`architecture. Section 4 presents an evaluation of the
`architecture and Section 5 shows how a new optimization
`service can be accommodated under this architecture.
`Section 6 discusses related work; Section 7 concludes.
`2. Architecture overview
`The principal insight behind our work is that centralized
`services simplify service management by reducing the
`number and geographic distribution of the interfaces that
`must be accessed in order to manage the services. As
`illustrated by the widespread deployment of firewalls in the
`last decade [Mogul 89, Cheswick & Bellowin 94], it is far
`easier to manage a single, well-placed host in the network
`to manage every client. Analogously, we break
`than
`monolithic virtual machines up into their logical service
`components and factor these components out of clients into
`network servers.
`for a virtual machine
`The service architecture
`determines where, when and how services are performed.
`The location (i.e. where), the invocation time (i.e. when),
`(i.e. how) of services are
`and
`the
`implementation
`constrained by the manageability, integrity and performance
`requirements of the overall system, and intrinsically involve
`engineering
`tradeoffs. Monolithic
`virtual machines
`represent a particular design point where all services are
`located on the clients and most service functionality,
`including on the fly compilation and security checking, is
`performed during the run-time of applications. While this
`paper shows the advantages of locating services within the
`network, changing the location of services without regard
`for
`their
`implementation can
`significantly decrease
`performance as well. For instance, a simple approach to
`service distribution, where services are decomposed along
`existing interfaces and moved, intact, to remote hosts, is
`likely to be prohibitively expensive due to the cost of
`remote communication over potentially slow links and the
`frequency of inter-component interactions in monolithic
`virtual machines. We describe an alternative design where
`service
`functionality
`is
`factored out of clients by
`partitioning services into static and dynamic components
`and present an
`implementation strategy
`that achieves
`performance comparable to monolithic virtual machines.
`In our distributed virtual machine, services reside on
`centralized servers and perform most of their functionality
`statically, before the application is executed. Static service
`
`203
`
`PALO ALTO NETWORKS Ex. 1036 Page 7
`
`

`
`Static Service Components
`
`Perimeter Services
`
`Execution SIICs
`
`Verifier
`
`Management SIICS
`Client
`Security
`Internet ~
`Enforcement Manager
`
`Compiler
`
`Optimizer
`
`Auditer
`
`Profiler
`
`Dynamic Service
`Components
`
`Network
`Management
`Server
`Security
`Server
`Library
`Manager
`
`0_
`
`Administration
`Console
`
`Figure 1. The organization of static and dynamic service components in a distributed virtual machine.
`
`components, such as a verifier, compiler, auditor, profiler,
`and optimizer, examine
`the
`instruction
`segment of
`applications prior to execution to ensure that the application
`exhibits the desired service properties. For example, a
`verifier may check the code for type-safety, a security
`service may examine the statically determinable arguments
`to system calls, and an optimizer may check code structure
`for good performance along a particular path .
`The dynamic service components provide service
`functionality during the execution of applications. They
`complement static service components by providing the
`services that inherently need to be executed at application
`run-time in the context of a specific client. For example, a
`security service may check user-supplied arguments to
`system calls, a profiler may collect run time statistics, and
`an auditing service may generate audit events based on the
`execution of the application.
`The glue that ties the static and dynamic service
`components together
`is binary rewriting. When static
`service components encounter data-dependent operations
`that cannot be performed statically, they insert calls to the
`corresponding dynamic service components. For example,
`our static verification service checks applications for
`conformance against the Java VM specification. Where
`static checking cannot completely ascertain the safety of the
`program, the static verifier modifies the application so that
`it performs the requisite checks during its execution. The
`
`resulting application is consequently self-verifying because
`the checks embedded by the static service component are an
`integral part of the application code.
`Figure 1 illustrates our distributed virtual machine
`architecture. Static service , components produce self(cid:173)
`servicing applications, which require minimal functi(mality
`on the clients. Dynamic service components provide service
`functionality to clients during run-time as necessary. The
`static services in our architecture are arranged in a virtual
`pipeline that operates on application code, as shown in
`Figure 2.
`A distributed service architecture allows the bulk of VM
`service functionality
`to be placed where
`it
`is most
`convenient. A natural service placement strategy is to
`structure the static service components as a transparent
`network proxy, running on a physically secure host. Placed
`at a network trust boundary, like a firewall, such a proxy
`can transparently perform code transformations on all code
`that
`is
`introduced
`into an organization.
`In
`some
`environments, the integrity of the transformed applications
`cannot be guaranteed between the server and the clients, or
`users may introduce code into the network that has not been
`processed by the static services. In such environments,
`digital signatures attached by the static service components
`can ensure that the checks are inseparable from applications
`[Rivest et al. 78, Rivest 92], and clients can be instructed to
`redirect
`incorrectly signed or unsigned code
`to
`the
`
`performance
`
`on program
`behavior
`
`r-check
`signatures
`'-execute
`program
`
`static
`rules
`annotate
`for
`dynamic
`checks
`Figure 2. The flow of code through a pipeline of static service components in a distributed virtual machine. The ordering of
`services in this pipeline may be modified to suit organizational or functional requirements. Further, the client runtime may
`communicate with the static service components for client-specific services.
`
`to native
`format
`
`204
`
`PALO ALTO NETWORKS Ex. 1036 Page 8
`
`

`
`centralized services [Spyglass 98].
`introduces a modest amount of new
`A DVM
`functionality into the existing trusted computing base of an
`organization. A DVM client needs to trust that the static
`and dynamic service components it relies on for safety,
`including the proxy and binary rewriter, are implemented
`correctly. In addition, any service authentication scheme
`used in the clients, which may include a digital signature
`checker and a key manager, form part of the trusted
`computing base under our design. However, we believe the
`actual impact of these additions to the TCB to be small.
`Monolithic clients already
`trust all of
`the service
`components that form a traditional VM and often already
`have provisions for cryptographic protocols and digital
`signature checking to support their target applications
`[Gong 99]. Overall, a modest increase in the TCB enables
`DVM clients
`to migrate
`the
`trusted components
`to
`physically secure, professionally managed and administered
`is critical
`to addressing
`the operational
`hosts, which
`problems that have plagued monolithic VMs.
`several
`in
`is
`unique
`Our
`service
`architecture
`fundamental ways. First,
`the centralized services are
`mandatory for all clients in an organization. For example,
`security checks injected into incoming code are inseparable
`from applications at the time of their execution and are thus
`binding throughout the network. Second, there is a single
`logical point of control for all virtual machines within an
`organization. In the case of the security service, policies are
`specified
`and
`controlled
`from
`a
`single
`location;
`consequently, policy changes do not require the cooperation
`of unprivileged users. And third, using binary rewriting as a
`service implementation mechanism preserves compatibility
`with existing monolithic virtual machines. A monolithic
`virtual machine may subject the rewritten code to redundant
`checks or services, but it can take advantage of the added
`functionality without any modifications.
`While a distributed service architecture addresses the
`problems faced by monolithic virtual machines, it may also
`pOSt\ new challenges. Centralization can lead to a bottleneck
`in performance or result in a single point of failure within
`the network. These problems can be addressed by
`replicated or recoverable server implementations. The next
`section shows how the separation between static and
`dynamic service components can be used to delegate state(cid:173)
`requiring functionality to clients. Section 4 shows that this
`implementation strategy does not pose a bottleneck for
`medium sized networks even in the worst possible case and
`can easily be replicated to accommodate large numbers of
`hosts.
`3. Services
`We have implemented the architecture described in the
`previous section to support a network of Java virtual
`machines
`(JVMs).
`In
`this section, we describe
`the
`
`implementation of conventional virtual machine services
`under our architecture and show
`that
`the distributed
`implementation
`of
`these
`services
`addresses
`the
`shortcomings of monolithic VMs outlined in the first
`section. Our services are derived from
`the Java VM
`specification, which broadly defines a type-safe, object(cid:173)
`based execution environment. Typical
`implementations
`consist of a verifier, which checks object code for type(cid:173)
`safety, an interpreter and a set of runtime libraries. In some
`implementations, the interpreter is augmented with a just(cid:173)
`in-time compiler to improve performance. The following
`sections describe the design and implementation of the
`services we have built to supplant those found in traditional
`Java virtual machines.
`rely on a common proxy
`All of our services
`infrastructure that houses the static service components.
`The proxy transparently intercepts code requests from
`JVM bytecodes and generates
`the
`clients, parses
`instrumented program in the appropriate binary format. An
`internal filtering API allows the logically separate services
`described in this section to be composed on the proxy host.
`Parsing and code generation are performed only once for all
`static services, while structuring the services as independent
`code-transformation filters enables them to be stacked
`according to site-specific requirements [Heidemann &
`Popek 94, O'Malley & Peterson 92]. The proxy uses a
`cache to avoid rewriting code shared between clients and
`generates an audit trail for the remote administration
`console. The code for the dynamic service components
`resides on the central proxy and is distributed to clients on
`demand.
`While the implementation details of our virtual machine
`services differ significantly, there are three common themes
`among all of them:
`• Location: Factoring VM services out of clients and
`locating them on servers improves manageability by
`reducing replicated state, aids integrity by isolating
`services from potentially malicious code and simplifies
`service development and deployment.
`• Service Structure: Partitioning services into static and
`dynamic components can enhance performance by
`amortizing the costly parts of a service across all hosts
`in the local network.
`Implementation Technique: Binary rewriting is used to
`implement services
`transparently. Binary rewriting
`services can be designed to incur a relatively small
`performance overhead while
`retaining backward(cid:173)
`compatibility with existing clients.
`3.1 Verification
`A comprehensive set of safety constraints allows a virtual
`machine to integrate potentially malicious code into a
`privileged base system [Stata & Abadi 98, Freund &
`
`•
`
`205
`
`PALO ALTO NETWORKS Ex. 1036 Page 9
`
`

`
`Mitchell 98]. Indeed, Java's appeal for network computing
`stems principally from its strong safety guarantees, which
`are enforced by the Java verifier.
`The task of verifying Java bytecode has been a
`challenge for monolithic virtual machines. First, since the
`Java specification is not formal in its description of the
`safety axioms,
`there are differences between verifier
`implementations. Verifiers from different vendors differ on
`underspecified issues such as constraints on the uses of
`uninitialized objects, subroutine calls, and cross-validation
`of redundant data
`in class files. Second, monolithic
`implementations tie the verifier to the rest of the VM,
`thereby prohibiting users from using stronger verifiers
`where necessary. Furthermore, monolithic verifiers make it
`difficult to propagate security patches to all deployed
`clients in a timely manner. As a case in point, 15% of all
`accesses to our web site originate from out-of-date browsers
`with well-known security holes for which many patches
`have been issued. Finally, the memory and processing
`render monolithic VMs
`requirements of verification
`unsuitable for resource limited clients, such as smart cards
`and embedded hosts [Cohen 97]. Some monolithic virtual
`machines for embedded and resource-limited systems have
`abandoned verification altogether for a restricted extension
`model based on trust [HP 99].
`We address
`these
`shortcomings by decoupling
`the rest of the VM, migrating
`its
`verification from
`functionality out of clients into a network verification
`service and centralizing the administration of this service.
`Moving verification out of clients poses some challenges,
`however, because parts of the verification process require
`access to client namespaces and have traditionally required
`close coupling with the client JVM. Specifically, Java
`verification consists of four separate phases. The first three
`operate on a single class file in isolation, respectively
`making sure that the class file is internally consistent, that
`
`the code in the class file respects instruction integrity and
`that the code is type-safe. The fourth phase checks the
`interfaces that a class imports against the exported type
`in
`its namespace, making sure
`that
`the
`signatures
`assumptions that the class makes about other classes hold
`during linking.
`three phases of
`the first
`In our
`implementation,
`verification are performed statically in a network server,
`while the link-time checks are performed by a small
`dynamic component on the client. This partitioning of
`functionality eliminates unnecessary communication and
`simplifies service implementation. During the processing of
`the first three phases, the verification service collects all of
`the assumptions that a class makes about its environment
`and computes the scope of these assumptions. For example,
`fundamental assumptions, such as inheritance relationships,
`affect the validity of the entire class, whereas a field
`reference affects only the ipstructions that rely on the
`reference. Having determined ~these assumptions and their
`scope, the verification service modifies the code to perform
`the corresponding checks at runtime by invoking a simple
`service component (Figure 3). Since most safety axioms
`have been checked by this time, the functionality in the
`dynamic component is limited to a descriptor lookup and
`string comparison. This lazy scheme for deferring link
`phase checks ensures that the classes that make up an
`application are not fetched from a remote, potentially slow,
`server unless they are required for execution.
`The distributed verification service propagates any
`errors to the client by forwarding a replacement class that
`raises a verification exception during its initialization.
`Hence, verification errors are reflected to clients through
`the regular Java exception mechanisms. Since the Java VM
`specification intentionally leaves the time and manner of
`verification undefined except to say that the checks should
`be performed before any affected code is executed, our
`
`class Hello {
`static boolean mainChecked = false; II Inserted by the verifier
`public static void main()
`II Begin automatically generated code
`{
`if( __ mainChecked == false)
`RTVerifier. CheckField ("java .lang. System", "out",
`"java.io.OutputStream");
`RTVerifier. CheckMethod ("java. io. OutputStream", "println ",
`"(Ljava l langi String) V");
`
`__ mainChecked = true;
`
`I I End automatically generated code
`}
`System.out.println("hello world");
`
`Figure 3. The hello world example after it has been processed by our distributed verification service. The vast majority of safety axioms
`are checked statically. Remaining checks are deferred to execution time, as shown in italics. The first check ensures that the Sys tern
`class exports a field named "out" of type OutputStream, and the second check verifies that the class OutputStream
`implements a method, "println," to print a string. The rewriting occurs at the bytecode level, though the example shows equivalent
`Java source code for clarity.
`
`206
`
`PALO ALTO NETWORKS Ex. 1036 Page 10
`
`

`
`approach conforms to the specification.
`While this approach to verification does not make the
`central task of verification any easier, it addresses the
`operational problems that have plagued monolithic clients.
`First, it allows a network of VMs to share the same verifier,
`thereby ensuring that code accepted for execution within
`that administrative domain is at least as strong as the
`constraints imposed by the central verifier. Transparent
`binary rewriting ensures that even existing monolithic VMs
`benefit from the assurance provided by the central verifier,
`though they will subject the code to redundant local
`verification. Second, an isolated verification service with
`clear interfaces is easier to check for correctness using
`automatic testing techniques [Sirer & Bershad 99]. Third,
`distributed virtual machine clients can be made smaller and
`cheaper because they do not have to support a verifier.
`Finally, in response to security flaws, only one software
`component needs to be updated per administrative domain,
`in contrast to having to patch every single network client,
`which often requires the assistance of users.
`3.2 Security
`The overall aim of any security service is to enforce a
`specific
`security
`policy
`across
`hosts within
`an
`administrative domain. Such a service should meet the
`following three goals to be comprehensive, easy to manage
`and versatile. First,
`it should uniformly enforce an
`organization's security policy across all nodes. Second, it
`should provide a single point of control for specifying
`organization-wide policies. And, third, it should allow an
`administrator
`to
`impose checks
`in any code deemed
`important for security.
`Our architecture satisfies these goals by