|Dealing with load/store instructions on static tainted flow analysis firstname.lastname@example.org (Gabriel Quadros) (2011-06-06)|
|Re: Dealing with load/store instructions on static tainted flow analys email@example.com (glen herrmannsfeldt) (2011-06-07)|
|Re: Dealing with load/store instructions on static tainted flow analys firstname.lastname@example.org (2011-06-08)|
|Re: Dealing with load/store instructions on static tainted flow analys email@example.com (George Neuner) (2011-06-09)|
|Re: Dealing with load/store instructions on static tainted flow analys firstname.lastname@example.org (Martin Ward) (2011-06-12)|
|Date:||08 Jun 2011 07:53:14 GMT|
|Posted-Date:||11 Jun 2011 13:51:24 EDT|
Gabriel Quadros <email@example.com> wrote:
> So, the problem is that it is hard to know that c != b and i != j.
> Once information flows into memory, the safest thing to do is to flag
> the whole memory as a SOURCE. Of course, that is very conservative. I
> was wondering if you guys could recommend me some strategies and
> techniques to be more precise. In particular, if you could point me
> some paper that does it, that would be great.
Something that may be of use.
You can create a hash value for address expressions and memory
accesses using a simple hash scheme.
Each constant in an expression is represented by itself.
Each variable is assigned a random number.
All operations + * / and performed modulo p (a nice big prime; there are
better choices if you're working with mixed integer and real expressions
e.g. if you want i**2 and exp(i*pi) to hash to -1 (i.e. p-1)).
Assignments copy the hash from one variable to another.
A pointer access can be modeled by generating a PRN using the hash
of the address as the seed.
If 2 hash values are different there is a strong probability the 2
expressions are not identical.
Of course, put this under an optimisation and give warnings in the manual. :)
Return to the
Search the comp.compilers archives again.