EEL 6938

Mutable agents

EEL 6938 Engineering Applications of Autonomous Agents

Lotzi Bölöni

EEL 6938

Self-modifying programs

• Every programmer learns at his first assembly language class that program code can be changed by simply writing to it.

• But then he also learns that self-modifying programs are a big no-no.

• Still…• As early as 1975, the Microsoft Basic

interpreter for Altair contained self-modifying code, introduced to overcome resource limitations (only 4K of space available for the interpreter).

• And many other unknown instances from early systems.

EEL 6938

Self-modifying programs today

• Current programming techniques frequently rely on self modifying applications, without making too much fuss about it.

• Just-in-time compilers (Java, SQL etc.) compile and optimize system independent code to the particularities of the system.

• Persistency systems: some of them rely on modifying source code or object code.

• Aspect oriented programming. Code weavers– AspectJ

• Debuggers and profilers. Code instrumentation for obtaining better quality traces, find memory leaks.

• Code obfuscators: rewrite the code without changing its execution characteristics such that they prevent reverse engineering of the code.

EEL 6938

More self modifying programs

• Automatic downloads, updates• Skins, themes• Plug-ins:

– Audio and video decoders and encoders– Processing plug-ins (e.g. Photoshop)

• Self editing documents– E.g. Word documents with macros which generate the

document through user interaction.

EEL 6938

The dark side of the self-modifying programs

• Viruses– Modify applications by attaching themselves to the

source code. – They are capable of self-replication– The application will execute the virus code – in addition

to the regular code.– Frequently viruses compress the application code such

that they maintain the same size.– Recent years, eclipsed by macro viruses (typically

relying on security problems in the Visual Basic implementations in Microsoft Outlook and Word.

– Some viruses are capable of mutation, to thwart anti-virus programs based on virus signatures.

• Computer worms– Similar to viruses, they self-replicate, but they are also

self-contained (they don’t need to be attached to programs to run).

EEL 6938

More on the dark side

• Trojan horses– Malicious programs, installing themselves into operating

systems.– Sometimes they are used by remote users to get control

of the computers.

• Buffer overflow security attacks– Are relying on the fact that unchecked C buffers can

overflow into the executable code of the programs (or into adjacent data areas).

• Spy-ware– Spyware is computer software that aids in gathering

information about a person or organization without their knowledge.

– The most common use is to relay it to advertisers – It has been used by law enforcement to collect evidence

against criminal suspects.– Frequently installed by viruses, trojans, or as a side-effect

of the installation of programs (e.g. Comet Cursor, was installed as a side effect of installation of RealPlayer 8.0)

EEL 6938

Preliminary conclusion

• Our computing environment is, for good or bad, full with self-modifying programs.

• We need to study, understand and use them.

• Security implications are very complex.• Software engineering techniques needs to

be adapted.• The identity of the programs / agents

become questionable – especially when the mutation is coupled with mobility.

EEL 6938

Classifying mutable programs

EEL 6938

Weak mutability

• Weak mutability is the technique to extend the functionality of the application using coarse grain external components.

• The application still keeps its essential characteristics and functionality.

• This is the currently most accepted form of mutability in applications. – Examples include: Java applets, ActiveX controls, data

format plugins, active plugins, skins and themes, applets and embedded applications, automatic upgrades etc.

• In many cases, weak mutability also implies the existence of well defined extension API’s (e.g. plugin API’s).

• Still, weak mutability can sometimes radically change the behaviour of the program: e.g. transform a web browser into a calculator.

EEL 6938

Strong mutability

• In case of strong mutability, applications are able to change their behavior in a radical manner.

• Strong mutability can be implemented at any level of granularity.

• At the machine-code level, typical examples are viruses and anti-virus programs.

• Source code level: example: aspect oriented programming– An example of this approach is the current approach

taken by the JBoss Enterprise JavaBean team.

• Component level: runtime assembly and modification of programs (e.g. Bond)

• Of course, in the current world of just in time compilers and runtime recompilations, the distinctions tend to be blurry.

EEL 6938

Applications of mutability(scenarios)

EEL 6938

Reconfiguration for migration

• Mobile agents need to maintain their identity through the migration process. – Perform (preferably) the same task.– At the possible maximum performance.

• So what happens when we have agents migrating between hosts with high heterogeneity:– For example, from a Unix server to a cellphone?

• Performance is a multidimensional issue, with many complex relationships:– Memory vs. processing speed– Bandwidth vs. latency

• We can shoot for the lowest common denominator, but this limits the performance of the agent.

• Solution: reconfigure at the time of migration.

EEL 6938

Reconfiguration for optimal performance

• Similar to the case of migration: programs need to be configured, changed to achieve optimal performance on the system.

• Example: SmartApps system (L.Rauchwerger, Texas A&M University)

EEL 6938

SmartApps• Run-time systems are too general. Little or no information

flows from the application to the run-time system to allow the latter to fully tailor its services to the application.

• The overriding philosophy of SMARTAPPS is “measure, compare, and adapt if beneficial." That is, the application will continually monitor its performance and the available resources to determine if, and by how much, the application could improve its performance by restructuring. Then, if the potential performance benefit outweighs the projected overhead costs, the application will restructure itself and the underlying system accordingly.

• The adaptation can occur at various levels including selection of an algorithmic approach suitable for the current problem, run-time parallelization and other related compiler optimizations, tuning reconfigurable OS services (e.g. scheduling policy), and system configuration (e.g., selecting which computational resources to use). The SMARTAPPS framework provides performance monitoring and modeling components, as well as mechanisms for performing the actual restructuring, to integrate these levels of adaptation.

EEL 6938

Discovery agents

• Used in network discovery, software installation, grid environments etc.– Yes, in spying, too.

• At the moment when a discovery agent migrates to the remote host, it does not know its resources, characteristics, etc.

• One solution:– Send the most lightweight agent possible.– As the resources are discovered, step by step “build up”

the agent on the remote system.

EEL 6938

Randomly mutating agents

• While randomly mutating agents are possible, their applications are limited.

• It is difficult to make them follow their original agenda.

• Limited random mutation, however, can lead to interesting possibilities:– Genetic algorithms and evolutionary programming– Tabu search

• Problems: – Compiled code does not make a good chromosome (in

the genetic algorithms sense). Crossover and mutation in compiled code usually lead to gibberish.

– The agents fitness in a multiagent system is a complex parameter depending on the other agents. It is very difficult to set up good training runs.

EEL 6938

Controlled mutation

• For most mutable agents, the “mutation” is controlled.– Mutation is not a really good word here. – In Bond 2, we proposed the term “agent surgery”

• Agent surgery:– A set of changes on an agent, performed under the

control of an external entity or of the agent itself, in order to achieve and agent with a changed goal or different (usually better) performance characteristics.

EEL 6938

Agent surgery in Bond

• Agent surgery in Bond are essentially operations performed on the multi-agent plane.

• Surgical operations are performed by “surgical blueprint scripts”.

• The agent (usually) does not have to be stopped.

EEL 6938

Problems in agent surgery

• When do we need to perform a surgical operation on the agent?

• What kind of operation do we need to perform?

• What kind of guarantees can we offer about the agent after the surgical operation?

• How can the surgical operation be embedded in the specification?

EEL 6938

Primitive operations

• Agent surgery operations are assembled of a set of “primitive operations”.

• Adding / removing planes• Adding / removing states• Adding / removing transitions.

EEL 6938

Invariants

• Invariants are properties of agents which are maintained across surgical operations.

• Our analysis technique will be to prove invariants for primitive operations, and then prove invariants for larger surgical operations by decomposing them into primitive operations.

• Example of invariants:– Being successful.– Achieving some subset of the agenda.– Having the agenda achievable.

EEL 6938

Successful and failed runs

• We will distinguish between SUCCESS, FAILURE and other transitions in the multiplane state machine– We assume SUCCESS means that local goal of the strategy was

achieved– We assume that FAILURE means that the local goal failed (but

the agenda may be still achievable, for instance, by retrying)– Other transitions mean “choices” or “decisions”.

• A run of the agent is an ordered series of events and actions– At a courser granularity level, we can see the run as a series of

states and transitions.

• A successful run is a run without a FAILURE transition.

• A failed run involves at least one FAILURE transition or an exit code for which there was no transition in the state machine.

EEL 6938

Relationship between failed/successful runs and

the agenda• The relationship is not immediate• A run might be successful without achieving

the agenda.• For instance:

– A strategy perform an exit code for which there is no transition

– It reaches a state where there are no outbound transitions etc.

• A run with some failed transitions can still achieve the agenda (for example, through retries)

• Still, we can use some additional conditions to more closely tie runs to agenda achieving.

EEL 6938

Reasoning about agent surgery

• Property 1:– Adding a new state to the agent does not change the behaviour

of the agent.

• Property 2:– Adding a new transition to the agent does not change the

behaviour of the agent in successful runs. – It might turn some failed runs into successful runs.

• Property 3:– If we add a new plane to an agent and the output set of the

strategies in the new plane is disjoint from the input set of the existing strategies, for all cases where the agent achieved its agenda in its original state will achieve it in its modified state as well (maintains the achievability of the agenda)

• Corrolary 3.1– Adding a plane with a single dummy strategy maintains the

achievability of the agenda.

EEL 6938

Reasoning about agent surgery (cont’d)

• Property 4:– Removing FAILURE transitions does not affect successful

runs.

• Property 5:– Removing states unreachable from the current state of

the agent, or removing transitions going to and from these states does not affect the behaviour of the agent.

• Property 6:– Removing states which are reachable only through

failure transitions does not affect successful runs.

EEL 6938

Applications of agent surgery

• Step by step build up of agents.• Modifying agents to achieve a larger

agenda.• Garbage collection on agents.

– By removing unreachable states, transitions, and “stuck” planes.

• Splitting agents– For task distribution.

• Merging agents• Adapting agents to platforms and

conditions:– User interfaces – Changing algorithms– Changing operating patterns.