search

gopalshankar / address-sanitizer

Automatically exported from code.google.com/p/address-sanitizer
0 stars 0 forks source link

CoverSan mode #291

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
Using ASan shadow memory it should be possible to collect approximate "Data 
Coverage" of a program. Data coverage is similar to code coverage, but instead 
of tracking which areas of code were used when the program runs, it tracks 
which parts of the data as written in the program in the program were used.

I am not aware of any in-depth research to make data coverage practical for 
imperative languages. One motivating example is state coverage for a state 
machine.

Here is another motivating example I just found:
http://pjcj.net/yapc/yapc-eu-2002-testing_and_code_coverage/paper.html#data_cove
rage

Doing coverage properly may be problematic (what does it mean that the data is 
actually "used"?), but we can approximate it by modifying the ASan shadow state 
every time the data is accessed.

We could use this technique in Chrome to find out which parts of data and bss 
are unused. This should help us remove some bloat. If we could make the 
compiler and linker always emit PIC calls via GOT, then by looking at relro 
coverage we have poor-man's function-level code coverage.

Original issue reported on code.google.com by pa...@google.com on 11 Apr 2014 at 11:05

GoogleCodeExporter commented 9 years ago 
BTW we're already modifying the shadow in TSan, so it's a lot easier to make a 
TSan-based POC implementation.

Original comment by ramosian.glider@gmail.com on 11 Apr 2014 at 11:10

GoogleCodeExporter commented 9 years ago 
just to make sure I understand: this is only relevant for global variables (and 
constants?). Not for heap or stack data. Right?

Could you please provide a test and desired output?

Original comment by konstant...@gmail.com on 11 Apr 2014 at 11:13

GoogleCodeExporter commented 9 years ago 
> just to make sure I understand: this is only relevant for global variables 
(and constants?).

Yes. Also potentially function pointers (via relro) and vtables.

> Could you please provide a test and desired output?

This idea is in a very raw state right now, I did not work out as many details 
as I'd like. A test could be chrome.apk + a set of URLs to load. Desired output 
is the list of offsets in .rodata, .data.rel.ro.local, .data.rel.ro, .data, 
.bss and such.

Original comment by pa...@google.com on 11 Apr 2014 at 11:26