пятница, 2 декабря 2016 г., 8:22:55 UTC+3 пользователь Yuri Gribov написал:
> On Fri, Dec 2, 2016 at 6:35 AM, Maxim Ostapenko <chef...@gmail.com 
> <javascript:>> wrote: 
> > Hi, 
> > 
> > 02 Дек 2016 г. 7:30 пользователь "steven shi" <shiju...@gmail.com 
> <javascript:>> 
> > написал: 
> >> 
> >> Hello, 
> >> With the experts' help in this community, I've enabled the Asan for 
> global 
> >> and stack buffer in my bare-mental platform firmware, thanks a lot. 
> >> But I find the current Asan doesn't support to protect the structure 
> inner 
> >> elements, E.g. the global_array[11] in below code. Unfortunately, most 
> of 
> >> important data are defined through structure in my firmware, and if the 
> Asan 
> >> doesn't support to protect structure inner elements, most of my data 
> memory 
> >> access will not be protected by Asan. So, could we let Asan support 
> >> structure inner elements? 
> >> 
> >> Well, I understand it is not safe to just instrument red-zone between 
> >> structure inner elements like current Asan does on global variable.  We 
> also 
> >> need to handle the sizeof(), offsetof() macro, the alignment pragma, 
> and 
> >> maybe others. Could we extend Asan scope beyond IR to Clang front-end 
> to do 
> >> some source-to-source conversion to handle these issue? E.g. for no 
> >> alignment enforced structure,  replace the structure inner elements 
> with 
> >> red-zone instrumented version, and let the sizeof() be-aware of the 
> size 
> >> change. Is it possible? 
> > 
> > Won't this break separate sanitization? E.g. if I have libfoo.so that 
> has 
> > struct Foo as part of its ABI and I want to test it with ASan, I'll need 
> to 
> > recompile not only libfoo.so, but all dependent libraries too to make 
> sure 
> > they caught up the changed layout of struct Foo. This sounds like a bad 
> idea 
> > for me. 
> > Or maybe I've just missed something? 
> I think Steven's code is self-contained so he does not care.

I might be wrong, but the major of part users would care about ABI changes.

> Also note 
> that you can get away without breaking ABI but just poisoning natural 
> padding in structures. I guess the main problem with sanitizing 
> structs is that they are often passed to "low-level" 
> memcmp/memcpy/memset/etc. functions which would result in spurious 
> errors. 

We can try to extend FORTIFY to allow ASan print nice reports as discussed 
in http://www.sourceware.org/ml/libc-alpha/2016-09/msg00080.html, but this 
will work only for users using recent enough Glibc.

You received this message because you are subscribed to the Google Groups 
"address-sanitizer" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to address-sanitizer+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to