пятница, 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.
