Case 1:20-cv-00034-ADA Document 50-6 Filed 04/10/20 Page 1 of 15
`
`Exhibit 22
`
`

`

`Case 1:20-cv-00034-ADA Document 50-6 Filed 04/10/20 Page 2 of 15
`
`Transparently
`
`Agents:
`Interposition
`Interposing
`User Code at
`
`the System Interface
`
`Michael
`
`B. Jones
`
`Microsoft Research, Microsoft Corporation
`One Microsoft Way, Building
`9S/1047
`Redmond, WA 98052
`USA
`
`Abstract
`
`1. Introduction
`
`systems utilize a system
`operating
`contemporary
`Many
`system and its clients.
`call
`inter-ace between the operating
`[ncreasing
`numbers
`of systems are providing
`low-level
`mechanisms for
`intercepting
`and handling
`system calls in
`user code. Nonetheless,
`they typically
`provide
`no higher-
`level
`tools or abstractions
`for
`effectively
`utilizing
`these
`Using
`them has
`typically
`required
`mechanisms.
`reimplementation
`of a substantial
`portion
`of
`the system
`interface from scratch, making
`the use of such facilities
`unwieldy at best.
`increases
`that substantially
`This paper presents a toolkit
`clients
`and
`the ease of
`interposing
`user code between
`such code to
`instances of
`the system interface
`by allowing
`be written
`in terms of
`the high-level
`objects provided
`by
`this interface,
`rather
`than in terms of the intercepted system
`This
`toolkit
`helps
`enable
`new
`calls
`themselves.
`interposition
`agents to be written, many of which would not
`otherwise have been attempted.
`several
`This toolkit
`has also been used to construct
`agents including.”
`system call
`tracing
`tools,
`file reference
`tracing tools, and customizable jdesystem views. Examples
`of other
`agents
`that could
`be built
`include.”
`protected
`environments
`for
`running
`untrusted
`binaries,
`iogical
`devices
`implemented
`entirely
`in user space,
`transparent
`data compression
`andlor
`encryption
`agents,
`transactional
`software
`environments,
`and emulators for other operating
`system environments.
`
`of
`
`IS
`this material
`fee all or part
`without
`to copy
`Permission
`for
`ordlstnbuted
`the copies
`are not made
`granted
`provided
`that
`and the
`notice
`direct
`commercial
`advantage,
`the ACMcopyrlght
`is given
`mle
`the publicauon
`and Its date
`appear,
`and notice
`of
`that
`copying
`is by permission
`of
`the Association
`for Computing
`Machinery.
`To copy
`otherwise,
`or
`to republish,
`requires
`a fee
`and/or
`specific
`permission.
`SIG 0PS’93/12/93/N.
`C., USA
`@ 1993
`ACM 0-89791
`-632 -8/93 /0012
`
`. ..$1 .50
`
`1.1. Terminology
`an
`provide
`systems
`operating
`Many
`contempomry
`interface
`between
`user code and the operating
`system
`services based on special
`“system calls”.
`One can view
`the system interface as simply a special
`form of structured
`communication
`channel
`on which messages
`are sent,
`allowing
`such operations
`as interposing
`programs
`that
`record or modify
`the communications
`that
`take place on
`this channel.
`In this paper, such a program that both uses
`and provides
`the system interface will be referred to as a
`“system interface
`interposition
`agent”
`or simply
`as an
`“agent”
`for short.
`
`1.2. Overview
`increases
`that substantially
`This paper presents a toolkit
`clients
`and
`the ease of
`interposing
`user code between
`such code to
`instances of
`the system interface by allowing
`be written
`in terms of
`the high-level
`objects provided
`by
`this interface.
`rather
`than in terms of
`the intercepted system
`Providing
`an object-oriented
`toolkit
`calls
`themselves.
`exposing
`the multiple
`layers of abstraction
`present
`in the
`system interface
`provides
`a useful
`set of
`tools
`and
`interfaces at each level. Different
`agents can thus exploit
`the toolkit
`objects best suited to their
`individual
`needs.
`Consequently,
`substantial amounts of
`toolkit
`code are able
`to
`be
`reused
`when
`constructing
`different
`agents.
`Furthermore,
`having
`such a toolkit
`enables new system
`interface
`implementations
`to be written, many of which
`would not otherwise have been attempted.
`Just as interposition
`is successfully
`used today to extend
`operating system interfaces based on such communication-
`based
`facilities
`as pipes,
`sockets,
`and
`inter-process
`communication
`channels,
`interposition
`can
`also
`be
`successfully
`used to extend the system interface.
`In this
`way,
`the known
`benefits
`of
`interposition
`can also be
`extended to the domain of the system interface.
`
`1.3. Examples
`should
`figures
`The following
`system interface and interposition.
`
`help
`Figure
`
`the
`both
`clarify
`1-1 depicts uses
`
`80
`
`

`

`Case 1:20-cv-00034-ADA Document 50-6 Filed 04/10/20 Page 3 of 15
`
`In this view,
`interposition.
`the system interface without
`of
`the kernell
`provides all
`instances of
`the operating
`system
`interface.
`Figure
`1-2 depicts
`the ability
`to transparently
`interpose
`user code that both uses and implements
`the
`operating
`system interface
`between
`an
`unmodified
`application
`program and the operating
`system kernel.
`Figure
`1-3 depicts
`uses of
`the system interface
`with
`interposition.
`Here,
`both
`the kernel
`and interposition
`agents provide instances of
`the operating
`system interface.
`Figure 1-4 depicts more uses of
`the system interface with
`interposition.
`In this view agents,
`like the kernel, can share
`state and provide multiple
`instances of
`the operating system
`interface.
`
`I
`
`Operating System Kernel
`
`II
`
`Operating System /nterface
`
`J
`
`~openo,
`kilio,
`
`r-eado,
`_exi
`
`to,
`
`state,
`signals,
`
`forko,
`.
`
`.
`
`.
`
`)
`
`Figure
`
`1-1: Kernel provides instances of system interface
`
`I
`
`Application Program
`
`I
`
`Your code here!
`
`Operating System Kernel
`
`I
`I
`
`Operating System Interface
`
`J
`
`II
`I
`
`I
`
`Figure
`
`1-2 User code interposed at system interface
`
`1A. Motivation
`Today, agents are regularly written to be interposed on
`simple communication-based
`interfaces
`such as pipes and
`sockets. Similarly,
`the toolkit makes it possible to easily
`write agents to be interposed on the system interface.
`Interposition
`can be used to provide
`programming
`facilities
`that would
`otherwise
`not
`be available.
`
`In
`
`this paper to refer to the default
`is used throughout
`‘The term ““kernel”
`or lowest-level
`implementation
`of
`the operating system in qresti on. While
`this implementation
`is often run in processor kernel space, this need not be
`the case, as in the Mach 3.0 Unix Semer/Emulator
`[ 16].
`
`emacs
`
`Untrusted
`Binary
`
`csh
`
`Compress/
`Uncompress
`
`Restricted
`Environment
`
`.%%%%-zm
`
`
`
`>27,-,-WJ2X’2XZ!I 1+2’.f.2W,zz//Z7i
`
`Operating System Kernel
`
`Figure
`
`1-3: Kernel and agents provide
`instances of system interface
`
`HP-UX
`Compiler
`
`HP-UX
`Emulator
`
`make
`
`mail
`
`Implementing
`Agent
`Customized Filesystem View
`
`G2%2./f//////A_
`
`v////////2z///A
`
`V///%5%A.////A
`
`Operating System Kernel
`
`)
`
`I
`
`1
`
`I
`
`[
`
`I
`
`1
`
`I
`
`Figure
`
`1-4: Agents can share state and provide
`multiple instances of system interface
`
`of simultaneously
`it can allow for a multiplicity
`particular,
`implementations
`of
`the system call
`services,
`coexisting
`which
`in turn may utilize
`one another without
`requiring
`changes to existing
`client binaries and without modifying
`the underlying
`kernel
`to support each implementation.
`Alternate
`system call
`implementations
`can be used to
`provide
`a number
`of services not
`typically
`available
`on
`system call-based
`operating
`systems.
`Some
`examples
`include:
`Facilities:
`and Monitoring
`. System Call Tracing
`can be
`Debuggers
`and program trace
`facilities
`constructed that allow monitoring
`of a program’s
`use
`of system services in a easily customizable manner.
`. Emulation
`of Other Operating
`Systems:
`Alternate
`system call
`implementations
`can
`be
`used
`to
`concurrently
`run
`binaries
`from variant
`operating
`systems on the same platform.
`For
`instance,
`it could
`be used to run ULTRIX
`[13], HP-UX [10], or UNIX
`System V [3] binaries in a Mach/BSD environment.
`l Protected
`Environments
`for Running
`Untrusted
`Binaries:
`A
`wrapper
`environment
`can
`be
`constructed that allows untmsted, possibly malicious,
`binaries to be run within a restricted environment
`that
`monitors and emulates the actions they fake, possibly
`without
`actually
`performing
`them,
`and limits
`the
`resources
`they
`can use in such a way
`that
`the
`untrusted binaries are unaware of
`the restrictions.
`A
`
`81
`
`

`

`Case 1:20-cv-00034-ADA Document 50-6 Filed 04/10/20 Page 4 of 15
`
`schemes
`and emulating
`of monitoring
`wide variety
`resource
`automatic
`from
`simple
`are
`possible
`restriction
`environments
`to heuristic
`evaluations
`of
`the target program’s
`behavior,
`possibly
`including
`interactive
`decisions made by human beings during
`the protected execution.
`This is particulady
`timely in
`of
`today’s environments
`increased software
`sharing
`with the potential
`for viruses and Trojan horses.
`Environments:
`l Transactional
`Software
`an
`Applications
`can be constructed
`that provide
`state
`environment
`in which
`changes
`to persistent
`made by unmodified
`programs
`can be emulated and
`performed
`transactionally.
`For
`instance,
`a simple
`command
`could be constructed
`“run
`transaction”
`that
`runs
`arbitrm-y
`unmodified
`programs
`(e.g.,
`/bin
`/ csh)
`such that all persistent
`execution
`side
`effects (e.g.,
`filesystem writes) are remembered
`and
`appem within
`the transactional
`environment
`to have
`been performed
`normally,
`but where in actuality
`the
`user
`is presented with
`a “commit”
`or
`“abort”
`choice at the end of such a session.
`Indeed, one such
`transactional
`program invocation
`could occur within
`another,
`transparently
`providing
`nested transactions.
`l Alternate
`or Enhanced
`Semantics:
`Environments
`can be constructed that provide alternate or enhanced
`One
`such
`semantics
`for
`unmodified
`binaries.
`enhancement
`in which people have expressed interest
`is the ability
`to “mount”
`a search list of directories
`in the filesystem name space such that
`the union of
`their contents appears to reside in a single directory.
`This
`could
`be used in a software
`development
`environment
`to allow distinct
`source
`and object
`directories
`to appear as a single
`directory
`when
`running make.
`
`Systems
`with Existing
`1.5. Problems
`numbers of operating
`systems are providing
`Increasing
`low-level
`mechanisms
`for
`intercepting
`system calls.
`Having
`these
`low-level
`mechanisms
`makes
`writing
`interposition
`agents possible.
`For
`instance, Mach [1, 16]
`provides
`the interception
`facilities
`used for
`this work,
`( ) operations
`SunOS version 4 [44] provides new pt
`race
`System V.4 [4]
`used by
`the trace
`utility,
`and
`UNIX
`operations used by the truss utility,
`provides new /proc
`Nonetheless,
`they typically
`provide no higher-level
`tools or
`abstractions
`for
`effectively
`utilizing
`these mechanisms,
`making the use of such facilities
`unwieldy
`at best.
`Part
`of
`the
`difficulty
`with
`writing
`system call
`interposition
`agents in the past has been that no one set of
`interfaces is appropriate
`across a range of such agents other
`ihan the lowest
`level
`system call
`interception
`services.
`Different
`agents
`interact with
`different
`subsets of
`the
`operating
`system interface
`in widely
`different ways to do
`Building
`an
`agent
`often
`requires
`different
`things.
`implementation
`of a substantial
`portion
`of
`the system
`interface.
`Yet,
`only
`the bare minimum
`interception
`facilities
`have been available,
`providing
`only
`the lowest
`common
`denominator
`that
`is minimally
`necessary.
`
`been constructed
`each agent has typically
`Consequently,
`completely
`from scratch. No leverage was gained from the
`work done on other agents.
`
`Insight
`1.6. Key
`that enabled me to gain leverage on the
`The key insight
`system interface interposition
`agents for
`problem of writing
`the 4.3BSD [25]
`interface is as follows:
`while the 4.3BSD
`system interface
`contains
`a large
`number
`of different
`system calls,
`it contains
`a relatively
`small
`number
`of
`abstractions whose behavior
`is largely
`independent.
`(In
`4.3BSD,
`the primary
`system interface
`abstractions
`are
`pathnames,
`descriptors,
`processes, process groups,
`files,
`directories,
`symbolic
`links, pipes, sockets, signals, devices,
`users, groups, permissions,
`and time.)
`Furthermore, most
`calls manipulate only a few of
`these abstractions.
`that
`Thus,
`it should be possible
`to construct
`a toolkit
`presents these abstractions
`as objects in an object-oriented
`programming
`language.
`Such a toolkit would then be able
`to
`support
`the
`substantial
`commodities
`present
`in
`different
`agents through code reuse, while also supporting
`the
`diversity
`of
`different
`kinds
`of
`agents
`through
`inheritance.
`
`2. Research Overview
`
`2.1. Design Goals
`The four main goals of the toolkit were:
`applications
`1. Unmodified
`System:
`Unmodified
`should be able to be run under agents. Similarly,
`the underlying
`kernel should not require changes to
`support each different
`agent
`(although
`the kernel
`may have to be modified
`once in order
`to provide
`support
`for
`system call
`interception,
`etc. so that
`agents can be written at all).
`2. Completeness:
`Agents should be able to both use
`This
`and provide
`the entire
`system interface.
`includes
`not
`only
`the
`set
`of
`requests
`from
`applications
`to the system (i.e.,
`the system calls) but
`also the set of upcalls
`that
`the system can make
`upon the applications
`(i.e..
`the signals).
`3. Appropriate
`Code Size: The amount of new code
`necessary to implement
`an agent using the toolkit
`should only be proportional
`to the new functionality
`to be implemented
`by the agent — not
`to the size of
`the system interface.
`The toolkit
`should provide
`whatever
`boilerplate
`and tools
`are necessary
`to
`write
`agents
`at
`levels
`of
`abstraction
`that
`are
`appropriate
`for
`the agent
`functionality.
`rather
`than
`having to write each agent at
`the raw system call
`level.
`4. Performance:
`an application
`
`impact of running
`The performance
`under an agent should be negligible.
`
`the Toolkit
`of
`and Structure
`2.2. Design
`the Mach
`I have designed and built a toolkit
`on top of
`2.5 system call
`interception mechanism [1, 5, 16]
`that can
`be used to interpose user code on the 4.3BSD [25] system
`call
`interface.
`The toolkit
`currently
`runs on the Intel
`
`82
`
`

`

`Case 1:20-cv-00034-ADA Document 50-6 Filed 04/10/20 Page 5 of 15
`
`in C++
`is implemented
`The toolldt
`386/486 and the VAX.
`of C and assembly
`language
`as
`with
`small
`amounts
`necessary.
`Multi-threaded
`hybrid
`4,3BSD/Mach
`2.5
`programs are not currently
`supported.
`As a consequence of using the Mach 2.5 system call
`interception mechanism, which
`redirects
`system calls
`to
`handler
`routines
`in the same address space,
`interposition
`agents reside in the same address spaces as their
`client
`processes. The lowest
`layers of the toolkit hides this Mach-
`specific
`choice,
`allowing
`agents to be constructed
`that
`could be located either
`in the same or different
`addresses
`spaces as their clients.
`in an object-oriented manner,
`This toolkit
`is structured
`in terms of several different
`allowing
`agents to be written
`inheritance.
`Abstractions
`layers of objects by utilizing
`layers
`currently
`include
`the
`exposed at different
`toolkit
`pathnames,
`directories,
`file
`filesystem
`name
`space,
`descriptors and the associated descriptor name space, open
`objects referenced
`by descriptors,
`and signals, as well as
`(These
`abstractions
`are
`the system calls
`themselves.
`discussed further
`in Section 2.3.)
`Support
`for additional
`abstractions
`can be incrementally
`added as needed by
`writing
`new toolkit
`objects
`that
`represent
`the
`new
`abstractions
`and by using derived versions of
`the existing
`toolkit
`objects that
`reference the new abstractions
`through
`Indeed,
`the
`current
`toolkit
`was
`the
`new objects.
`constructed
`via exactly
`this kind of stepwise refinement,
`with
`useful
`toolkit
`objects being produced
`at each step.
`The structure of
`the toolkit
`permits agents to be written in
`terms
`of whatever
`system interface
`abstractions
`are
`appropriate
`to the tasks they perform.
`Just as derived
`objects are used to introduce
`new toolkit
`functionality,
`interposition
`agents
`change
`the behavior
`of particular
`system abstractions
`by
`using
`agent-specific
`derived
`versions
`of
`the
`toolkit
`objects
`representing
`those
`abstractions.
`different
`agents need to affect
`interposition
`Different
`of
`the system call
`interface
`in substantially
`components
`different ways and at different
`levels of abstraction.
`For
`instance, a system call monitoring/profding
`agent needs to
`manipulate
`the system calls themselves, whereas an agent
`providing
`alternate
`user
`filesystem
`views
`needs
`to
`manipulate
`higher-level
`objects
`such as pathnames
`and
`The agent writer
`decides what
`possibly
`file descriptors.
`layers of
`toolkit
`objects are appropriate
`to the particular
`Default
`task and includes
`only
`those toolkit
`objects.
`implementations
`of
`the included objects provide the normal
`behavior
`of
`the abstractions
`they represent.
`This allows
`derived agent-specific
`versions of
`toolkit
`objects to inherit
`while
`adding
`new
`behavior
`in
`the
`this
`behavior,
`implementations
`of
`the derived objects.
`I believe that
`the
`failure to provide such multi-layer
`interfaces by past system
`call
`interception mechanisms
`has made them less useful
`than they might otherwise have been.
`
`Layers
`2.3. Toolkit
`classes
`the primary
`Figure
`2-1 presents a diagmm of
`Indented
`toolklt.
`currently
`provided with the interposition
`Arrows
`classes are subclasses
`of
`the classes above.
`indicate
`the use of one class by another. Many of
`these
`classes are explained in more detail
`in this section.
`
`numeric_syscall
`
`bsd_numeric_syscall
`
`symbol
`
`ic_syscall
`
`desc_symbol
`
`ic_syscall
`
`/
`
`path_
`
`symbol
`
`ic_syscall
`
`/
`descriptor_
`
`I open_descript
`
`descriptor
`
`set
`
`\
`pathname_set
`
`or_set
`
`t
`
`pathname
`
`open_descriptor
`
`open_object
`
`directory
`
`Figure 2-1: Primary interposition
`
`toolkit
`
`classes
`
`perform such functions
`the toolkit
`layers of
`The lowest
`interception,
`incoming
`as agent
`invocation,
`system call
`signal handling,
`performing
`system calls on behalf of
`the
`agent, and delivering
`signals to applications
`running under
`agent code. Unlike
`the higher
`levels of
`the toolkit,
`these
`layers are sometimes highly operating
`system specific and
`also contain machine specific
`code. These layers hide the
`mechanisms
`used to intercept
`system calls and signals,
`those that are used to call down from an agent
`to the next
`level system interface,
`and those that are used to send a
`signal
`from an agent up to the application
`program.
`These
`layers also hide such details as whether
`the agent resides in
`the same address
`space as the application
`program or
`whether
`it resides in a separate address space, These layers
`are referred to as the boilerplate
`layers.
`These layers are
`not normally
`used directly by interposition
`agents.
`is
`The lowest
`(or zeroth)
`layer of
`the toolkit which
`the
`directly
`used by any
`interposition
`agents presents
`system interface as a single entry point accepting vectors of
`It provides
`the ability
`to
`untyped
`numeric
`arguments.
`register
`for specific numeric
`system calls to be intercepted
`and for
`incoming
`signal handlers
`to be registered.
`This
`layer is referred to as the numeric system call
`layer.
`
`%3
`
`

`

`Case 1:20-cv-00034-ADA Document 50-6 Filed 04/10/20 Page 6 of 15
`
`Example interfaces provided by the numeric system call
`layer are as follows:
`
`numeric_
`
`syscail
`
`{
`
`ciass
`public:
`virtual
`int
`virtual
`virtual
`code,
`void
`void
`high)
`
`(int
`*regs);
`
`syscall
`void
`init(char
`signal_handler(int
`sigcontext
`
`int
`rv[2],
`void
`void
`struct
`register_interest
`register_interest_range
`;
`
`(inc
`
`number,
`
`int
`
`args[l
`
`,
`
`‘agentargv[]
`
`);
`
`sig,
`
`int
`
`*context!;
`rLUMber)
`(int
`
`;
`low,
`
`int
`
`};
`
`the numeric system calllayer,by
`just
`Forinstance,using
`the numeric_
`syscall
`class
`using a derived version of
`method,
`an agent
`with
`an agent-specific
`syscallo
`writer
`could
`trivially
`write
`an agent
`that printed
`the
`arguments ofa chosen set of system calls as uninterpreted
`numeric vahres. As another example, one range of system
`call numbers
`could be remapped
`to calls on a different
`rangeatthis
`level.
`intended for direct use by
`the toolkit
`The first
`layer of
`most
`interposition
`agents presents the system interfaces
`a
`set of system call methods on a system interface
`object.
`When this layer
`is used by an agent, application
`system
`calls are mapped
`into
`invocations
`on the system call
`methods of
`this object.
`(This mapping is itself done by a
`version
`the
`toolkh-supplied
`derived
`of
`object.)
`This layerisreferred
`toas
`numeric_syscall
`the symbolic system call
`layer.
`Example
`interfaces
`provided
`layer are as follows:
`
`by the symbolic
`
`system
`
`call
`
`symbol
`
`ic_syscall
`
`{
`
`int
`
`getpn
`“pn);
`
`public
`init
`void
`virtual
`PATH_SYMBOLIC_BASE
`
`around the
`isstnrctured
`the toolkit
`The second layer of
`primary
`abstractions provided
`by the system call
`interface.
`In 4.3BSD,
`these include
`pathnames,
`file
`descriptors,
`processes, and process groups.
`This
`layer presents the
`system interface assets of methods on objects representing
`these abstractions.
`Toolkit
`objects
`currently
`provided
`at
`filesystem
`name
`space
`level
`are
`the
`this
`(pathname_set),
`resolved pathnarnes (pathname),
`the
`file descriptor
`name space (descriptor_set),
`active
`file
`descriptors
`(descriptor),
`and reference
`counted
`Such
`operations
`as
`open
`objects
`(open_object).
`filesystem
`name
`space transformations
`and filesystem
`usage monitoring
`are done at this level.
`pathname
`on
`For
`example,
`agents
`can
`interpose
`classes:
`two
`of
`operations
`by using
`derived
`versions
`pathname_set
`and pathname.
`Thepathname_set
`class provides operations
`that affect
`the set of pathnames,
`The
`i.e.,
`those
`that
`create
`or
`remove
`pathnames.
`pathname
`class provides
`operations
`on the
`objects
`referenced by the pathnames.
`Example
`interfaces
`provided
`class are as follows:
`class
`pathname_set
`protected:
`virtual
`pathname
`:
`
`by the pathname_set
`
`: public
`
`descriptor_
`
`set
`
`{
`
`(char
`
`*path,
`
`int
`
`flags,
`
`(char
`
`*agent
`*path_sym);
`
`argv[l
`
`,
`
`class
`
`knowledge
`*path,
`
`of
`
`pathnames
`flags,
`
`int
`
`int
`
`class
`public:
`virtual
`virtual
`
`void
`void
`
`init(char
`init_childo;
`
`‘agentargv[
`
`1 ) ;
`
`with
`calls
`open(char
`rv[2]);
`link(char
`
`System
`j/
`int
`virtual
`int
`mc]de,
`int
`virtual
`rv[2]);
`int
`rv[2));
`int
`*path,
`unlink(char
`int
`virtual
`... entries for other 4.3BSD system calls asing pathnames
`
`*path,
`
`char
`
`‘newpath,
`
`...
`
`status,
`
`int
`
`};
`
`int
`
`sys_exit(int
`
`virtual
`rv[2]);
`sys_fork(int
`int
`virtual
`sys_read(int
`int
`virtual
`rv[2]);
`int
`cnt,
`. . entries forallother4.3BSD
`
`rv[21)
`fd,
`
`;
`
`void
`
`‘buf,
`
`int
`
`rytemcalls.
`
`..
`
`interfaces
`
`provided
`
`by the pathname
`
`class
`
`virtual
`‘args,
`*regs)
`virtual
`code,
`
`int
`int
`
`;
`void
`struct
`
`unknown_syscall
`rv[2],
`struct
`
`number,
`(int
`emul_regs
`
`int
`
`signal_handler(int
`sigcontext
`
`*context);
`
`sig,
`
`int
`
`};
`system calls by using
`Agents can interpose on individual
`a derived
`version
`of
`the symbolic_syscall
`object
`with agent-specific methods
`corresponding
`to the system
`calls to be intercepted.
`For
`instance,
`the timex
`agent,
`which is described in Section 3.3.1, changes the apparent
`time of day by using a derived
`symbolic_syscall
`object with anew gettimeofday
`() method.
`Likewise,
`agent, described
`in Section
`3.3.2, prints
`the
`the trace
`arguments
`to each executed
`system call
`in a human-
`readable from individual
`system call methods in a derived
`llobject.
`symbolic_sysca
`
`Example
`areas follows:
`class
`pathname
`public:
`virtuai
`rv[2j
`virtual
`rv[2]);
`unlink(lnt
`int
`virtual
`... entries forother4.3BSD
`pathnames...
`
`{
`
`flags,
`open(int
`int
`, OPEN_OBJECT_CLASS
`int
`link(pathname
`
`int
`**oo)
`‘newpn,
`
`mode,
`;
`
`int
`
`int
`
`) ;
`rv12j
`system calls referencing
`
`objecls
`
`via
`
`};
`
`classes is the
`these interrelated
`The key to both of
`string and
`getpno
`operation, which looksupapathname
`object.
`The
`resolves
`to a reference
`to a pathname
`it
`et
`system
`default
`implementation
`ofallthepathname_s
`strings
`to
`call methods
`simply
`resolves
`their pathname
`pathname
`objects using getpn
`() and then invokes the
`corresponding
`pathname
`method on the resulting
`object.
`The
`pathname
`method
`is
`responsible
`for
`actually
`performing
`therequested
`operation onthe objectreferenced
`bythepalhname.
`
`

`

`Case 1:20-cv-00034-ADA Document 50-6 Filed 04/10/20 Page 7 of 15
`
`to encapsulate pathname
`( ) operation
`With the getpn
`lookup,
`it
`is possible for agents to supply derived versions
`of
`the pathname_set
`object with
`a new getpn
`( )
`implementation
`that modifies
`the
`treatment
`of
`all
`For
`pathnames.
`instance,
`this can be used to logically
`rearrange the pathname space, as was done by the union
`agent
`(described in Section 3.3.3).
`Likewise,
`it provides a
`central point
`for name reference
`data collection,
`as was
`agent
`(described
`in Section
`done by the df
`s_t
`race
`3.5.3).
`layers focuses on secondary objects
`toolkit
`A third set of
`provided
`by the system call
`interface, which are normally
`accessed via primary
`objects.
`Such objects include files,
`directories,
`symbolic
`links,
`devices,
`pipes, and sockets.
`These layers present
`the system interface as sets of methods
`on objects, with specialized operations for particular
`classes
`of objects.
`The only toolkit
`object currently
`provided
`at
`object.
`this
`level
`is
`the open
`directory
`directory
`Operations that are specific to these secondary objects such
`as directory
`content
`transformations
`are done at this level.
`For
`example,
`agents
`can
`interpose
`on
`directory
`operations
`by using derived versions of
`the directory
`the
`class. The directory
`class is itself a derived version of
`j e c t class (one of
`the second layer classes for
`open_ob
`file descriptor operations),
`since directory
`operations are a
`special case of operations
`that can be performed
`on file
`descriptors.
`interfaces provided
`Example
`are as follows:
`C:aSS
`directory
`pu~lic:
`virtual
`struct
`next_
`
`by the directory
`
`class
`
`: public
`
`OPEN__OBJECT_CLASS
`
`(
`
`int
`direct
`direntry
`
`direntry
`next_
`*direntry;
`( )
`
`( ) ;
`II
`
`Set
`
`by
`
`public:
`virtual
`rv
`virtual
`int
`virtual
`cnt,
`
`int
`
`read
`
`(void
`
`‘buf,
`
`int
`
`cnt,
`
`int
`
`[2]);
`
`rv
`
`int
`[2]);
`int
`long
`
`lseek(off_t
`
`offset,
`
`int
`
`whence,
`
`getdirentries
`‘basep,
`
`int
`
`(vc]id
`rv[2]
`
`) ;
`
`*buf,
`
`int
`
`1;
`pathname
`( ) method encapsulated
`Just as the get
`pn
`encapsulates
`resolution,
`the next_direntry
`( ) method
`the iteration
`of
`individual
`directory
`entries
`implicit
`in
`reading the contents of a directory.
`This allows the union
`the
`agent (described in Section 3.3.3)
`to make it appear that
`in a
`full contents of a set of directories
`is actually present
`single directory
`by providing
`a new next_di
`( )
`rent
`ry
`function
`that
`iterates over
`the contents of each member
`directory.
`(And yes, that
`iteration itself
`is accomplished
`via
`implementations.)
`the underlying
`next_dirent
`ry
`
`Agents
`to Build
`the Toolkit
`2.4. Using
`I also used it
`to implement
`the toolkit,
`As I built
`agenta. These agents provide:
`interposition
`o System Call
`and Resource
`Usage Monitoring:
`This demonstrates
`the ability
`to intercept
`the full
`system catl
`interface.
`
`several
`
`85
`
`This
`Views:
`Filesystem
`Configurable
`l User
`to transparently
`assign new
`demonsmates the ability
`interpretations
`to filesystem pathnames.
`l File Reference
`Tracing
`Toots
`that are compatible
`with existing
`tools [30] originally
`implemented
`for
`this
`use by the Coda [38, 23]
`filesystem project:
`provides
`a basis
`for
`comparing
`a best available
`equivalent
`implementation
`to a facility
`provided
`by
`an agent.
`
`3. Results
`
`3.1. Goal: Unmodified
`
`System
`
`Applications
`3.1.1. Unmodified
`Agents
`interface
`system
`the
`constructed
`using
`4.3BSD
`interposition
`tootkit
`can load and run unmodified
`binaries. No recompilation
`or relinking
`is necessary. Thus,
`agents can be used for all progmm binaries — not
`just
`those for which sources or object
`files are available.
`Applications
`do not have to be adapted to or modified
`for particular
`agents.
`Indeed,
`the presence of agents should
`be transparent
`to applications.2
`
`Kernel
`3.1.2. Unmodified
`interface
`system
`the
`using
`Agents
`constructed
`any agent-specific
`interposition
`toolkit
`do not
`require
`kernel motilcations.
`Instead,
`they use general system call
`handling facilities
`that are provided
`by the kernel
`in order
`to implement
`all agent-specific
`system call behavior.
`Also,
`a general agent
`loader program is used to invoke arbitrwy
`agents, which
`are compiled
`separately
`from the agent
`loader.
`a
`contains
`this work
`used for
`2.5 kernel
`The Mach
`that
`allows
`primitive,
`( ) ,
`task_
`set_emulation
`for execution in user
`4.3BSD system calls to be redirected
`Another
`primitive,
`space.
`htg_unix_syscall
`( ) ,
`permits calls to be made on the underlying
`4.3BSD system
`call
`implementation
`even though
`those calls are being
`redirected.
`
`Completeness
`3.2. Goal:
`interface
`system
`the
`using
`constructed
`Agents
`the entire
`toolkit
`can both use and provide
`interposition
`This
`includes
`not only
`the
`4.3BSD system interface.
`system calls, but also the signals. Thus, both the downward
`path (from applications
`to agents and from agents to the
`underlying
`system implementation)
`and the upward
`path
`(from the underlying
`implementation
`to agents and from
`agents to applications)
`are fully supported.
`Completeness gives two desirable results:
`1. All programs
`can potentially
`be run under agents.
`By contrast,
`if completeness
`did not hold,
`there
`would have been two classes of programs:
`those
`
`is intent on determining
`that
`‘Of course, an application
`if only by probing memory
`under an agent probably
`can,
`precise performance measurements.
`
`is running
`it
`if
`or performing
`
`

`

`Case 1:20-cv-00034-ADA Document 50-6 Filed 04/10/20 Page 8 of 15
`
`: sys_gettimeofciay
`
`(tp,
`
`{
`
`int
`ret
`
`if
`
`ret;
`=
`sytiolic_syscall
`tzp,
`rv);
`(ret
`>= O && tp)
`tp->tv_sec
`+=
`offset;
`
`:
`
`ret;
`
`} r
`
`eturn
`
`{
`
`J T
`
`agent
`the t imex
`he new code necessary to construct
`of
`the
`using the toolkit
`consists only of
`the implementation
`new functionality.
`Inheritance
`from toolkit
`objects is used
`to obtain implementations
`of all system interface behaviors
`that remain unchanged.
`
`3.3.2. Size of the Trace Agent
`client
`of
`execution
`the
`agent
`traces
`The trace
`processes,
`printing
`each system call made and signal
`received.
`Like
`the t imex
`agent,
`it
`is built
`upon the
`symbolic
`system call and lower
`levels of
`the toolkit, which
`contain 2467 statements.
`However,
`the code specific
`to
`this agent
`is much larger, containing
`1348 statements.
`The
`reason for this is simple:
`unlike the t imex
`agent,
`the new
`work of
`the trace
`agent
`is proportional
`to the size of
`the
`Derived
`versions of each of
`the
`entire system interface.
`114 4.3BSD system calls plus the signat handler are needed
`to print each call name and arguments,
`since each call has a
`different
`name and typically
`takes different
`parameters.
`Even so, the new code contains less than 12 statements per
`system call, 10 of which typically
`are of
`the form:
`virtual
`int
`sys_read(int
`fd,
`void
`*buf,
`cnt,
`rv
`int
`[2]);
`(linefiom
`TRACE_SYMBOL
`
`I C_ CLASS class declaration)
`
`int
`
`TRACE_ SYMBOL IC_CLASS:
`void
`*buf,
`int
`cnt,
`
`: sys_read(
`int
`rv
`[2]
`
`)
`
`int
`
`fd,
`
`int
`
`{
`
`register
`print_
`fprintf
`fd,
`fflush
`ret
`
`.
`
`buf,
`print_
`fprintf
`fd,
`print_
`return
`
`int
`
`ret;
`( ) ;
`“read(%d,
`cnt)
`;
`
`start
`(f,
`buf,
`;
`(f)
`TRAcE_SYMBOLI
`cnt,
`rv)
`;
`start
`( ) ;
`(f,
`“ . . .
`buf,
`cnt)
`retx(
`ret,
`ret;
`
`;
`
`Ox%x,
`
`Ox%x)
`
`. .
`
`.
`
`l\II”,
`
`C_BASE:
`
`: sys_read
`
`( fd,
`
`read(%d,
`
`Ox%x,
`
`Ox%x)
`
`-~”,
`
`rv)
`
`;
`
`}
`the new code necessary to
`agent,
`As with the t imex
`consists only
`the trace agent using the toolkit
`construct
`of
`the implementation
`of the new functionality.
`Inheritance
`from toolkit objects is used to obtain implementations
`of all
`system interface behaviors that remain unchanged.
`
`3.3.3. Size of the Union Agent
`union directories, which
`agent
`implements
`The union
`provide
`the ability
`to view the contents of
`lists of actual
`directories
`as if
`their
`contents were merged
`into single
`“union”
`directories.
`It
`is built
`using toolkit
`objects for
`pathnames,
`directories,
`and descriptors,
`as welt
`as the
`
`that agents
`features
`set of
`that used a restricted
`could
`handle,
`and those that used features
`that
`agents could not handle.
`The interposition
`toolkit
`avoids these problems.
`the
`all aspects of
`2. Agents
`can potentially modify
`to
`Agents
`are not
`restricted
`system interface.
`For
`modifying
`only subsets of
`the system behavior.
`instance,
`it would
`have been easy to envision
`similar
`systems in which agents could modify
`the
`behavior of system calls, but not
`incoming
`signals.
`
`Code Size
`Appropriate
`3.3. Goal:
`three different
`Table 3-1 lists the source code sizes of
`agents, broken down into statements of
`toolkit
`code used,
`and statements of agent specific code. 3 These agents were
`chosen to provide a cross section of different
`interposition
`agents, ranging from the very simple to the fairly
`complex
`and using different
`portions
`of
`the interposition
`toolkit.
`Each of these agents is discussed in turn.
`
`~ Name
`I tirnex
`
`~trace
`I union
`
`Statements
`
`Statements
`
`Statements
`
`2467
`
`246’7
`
`3977
`
`35
`
`1348
`
`166
`
`2502 I
`
`3815 I
`
`4143 I
`
`Table 3-1: Sizes of agents, measured in semicolons
`
`3.3.1. Size of the Timex Agent
`It
`time of day.
`agent changes the apparent
`The t imex
`is built upon the symbolic
`system call and lower
`levels of
`the toolkit
`(see Section 2.3). The toolkit
`code used for
`this
`agent contains 2467 statements.
`The code specific
`to this
`agent
`consists
`of only
`two
`routines:
`a new derived
`( ) system call and
`implementation
`of
`the get
`t
`imeo
`f day
`an initialization
`routine to accept
`the desired effective
`time
`of day from the command line. This code contains only 35
`statements.
`The core of the t imex
`class
`timex_symbo
`symbol
`ic_syscall
`
`is as follows:
`: public
`
`agent
`lic_syscall
`{
`
`public:
`virtual
`virtual
`*tp,
`
`void
`int
`struct
`
`(char
`init
`sys_gettimeofday
`timezone
`
`