This is much harder than it sounds. I've made an attempt ~2 years ago and it almost, but not quite entirely, worked.... https://github.com/google/sanitizers/wiki/AddressSanitizerIntraObjectOverflow (Only for non POD objects in C++, so it won't directly apply to C at all)
And I totally agree that this is a large missing piece in asan. --kcc On Thu, Dec 1, 2016 at 9:31 PM, Yuri Gribov <[email protected]> wrote: > On Fri, Dec 2, 2016 at 7:22 AM, Yuri Gribov <[email protected]> wrote: > > On Fri, Dec 2, 2016 at 6:35 AM, Maxim Ostapenko <[email protected]> > wrote: > >> Hi, > >> > >> 02 Дек 2016 г. 7:30 пользователь "steven shi" <[email protected]> > >> написал: > >>> > >>> 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. 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. > > Also in C you don't get type information as easily as with C++'s new > operator. Structs are allocated as untyped memory buffers via malloc > and then casted to appropriate type. Compiler will have to figure out > that newly allocated char*-pointer is meant to point to struct (which > is not always possible e.g. if malloc happens in a different function > in separate translation unit). > > -I > > -- > 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 [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
