[DiSL-user] Taint Analysis with DiSL

[Alessio Gambi]

A quick follow up:

my code did not trigger because I misspelled the manifest attribute name (DiSL-Transformers).

The correct manifest attribute name is:
	DiSL-Transformer

Best

— Alessio

Alessio Gambi, Ph.D.
gambi at st.cs.uni-saarland.de



> On 19 Apr 2017, at 12:13, Alessio Gambi <gambi at st.cs.uni-saarland.de> wrote:
> 
> Hi DiSL-ers,
> 
> following Lubomir advice I implemented the  ch.usi.dag.disl.Transformer into a class, then specified its fully qualified
> name in the DiSL-Transformers attribute in the manifest of the instumentation jar [1].
> 
> However, I suspect that DiSL in not picking this up. I say I suspect because I do not how to verify that my Transformer is instantiated
> and used. I put a couple of System.out statements in the Transformer code but did not see them out the console, but I might be looking at the wrong console ;)
> 
> I invoke my test application (one of the examples provided in the DiSL distribution) using the disl.py script.
> 
> Note that I see the DiSL snippets being triggered…
> 
> Any advice  ?
> 
> Best
> 
> — Alessio
> 
> 
> [1] Manifest
> Manifest-Version: 1.0
> DiSL-Classes: de.unisaarland.instrumentation.disl.ConflictDetection
> DiSL-Transformers: de.unisaarland.instrumentation.RWDependencyClassFileTransformer
> 
> Alessio Gambi, Ph.D.
> gambi at st.cs.uni-saarland.de
> 
> 
> 
>> On 18 Apr 2017, at 16:07, Lubomír Bulej <lubomir.bulej at d3s.mff.cuni.cz> wrote:
>> 
>> Dear Alessio,
>> 
>> DiSL itself was not meant to modify classes in this way, but it would
>> certainly work if you give it classes that are already modified in this way.
>> 
>> 
>> If you want to do everything at load time, you can also give DiSL a
>> transformer class, and DiSL will use it to pre-transform class before starting
>> to instrument it.
>> 
>> You should implement the ch.usi.dag.disl.Transformer interface, and set the
>> DiSL-Transformers attribute in the manifest of the jar file with
>> instrumentation classes (the jar file with snippets which the DiSL server
>> uses) to the fully qualified class name of your transformer class.
>> 
>> We generally use exactly the pattern you describe, because you don't want to
>> do a lot of work in the snippets (they are inlined as bytecode) and it can
>> blow up the size of the methods significantly. So we usually call an analysis
>> method from the snippets and include the event data as parameters, possibly
>> with a bit of state stored in thread-local and synthetic local variables (the
>> synthetic locals allow embedding small amounts of state information in stack
>> frames).
>> 
>> Let me know if it helps...
>> 
>> 
>> Best regards,
>> Lubomir
>> 
>> 
>> On 18/04/17 15:14, Alessio Gambi wrote:
>>> Hi DiSL-ers
>>> 
>>> I was wondering if I can dynamically add private fields and getters/setters to classes using DiSL.
>>> 
>>> The reason for that is I want to implement a (special) taint analysis that stores taint information directly inside
>>> the objects and partially analyze them locally. In other terms, I do not like to implement the following pattern:
>>> 
>>> observe event -> publish the event to an event handler -> do the complete analysis inside the event handler
>>> 
>>> I already have the code which adds the fields to the classes… would DiSL work it I pass to it code which is
>>> already instrumented?
>>> 
>>> Any thoughts?
>>> 
>>> Best
>>> 
>>> — Alessio
>>> 
>>> 
>>> 
>>> Alessio Gambi, Ph.D.
>>> gambi at st.cs.uni-saarland.de
>>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://d3s.mff.cuni.cz/pipermail/disl-user/attachments/20170419/36ed7e33/attachment.html>