cisco-open / llvm-crash-analyzer

llvm crash analysis
Apache License 2.0
41 stars 17 forks source link

[TA] Handle use of backup register values in calculateMemAddr #9

Closed niktesic closed 2 years ago

niktesic commented 2 years ago

In startTaint()/propagateTaint(), we extract Src/Dest operands from the current MachineInstr and create a corresponding TaintInfo objects. If TaintInfo represents a memory location, we invoke calculateMemAddr() to try to calculate ConcreteMemoryAddress for that particular memory location.

Computation of memory address includes addition of base register value and the offset. In some cases, when base register value is not available, we try to reconstruct it by using the equivalent location determined during RegisterEquivalence analysis. This patch handles use of backup (equivalent) locations with awareness of dereferenced and non-dereferenced locations (register locations).

Additionally, as it is done in startTaint, calculate ConcreteMemoryAddress for second source operand in propagateTaint as well. I don't see why this should not be calculated. For now, I've seen some CMP instruction that have two source operands.

niktesic commented 2 years ago

Reading a memory location which is not on the stack of crashing thread can return a stale value. Retracer paper does not talk about multi-threaded programs. Other than this general concern, your changes look good to me.

Thanks for the comment! I agree, we need to be aware of this.