On Fri, Dec 2, 2016 at 7:22 AM, Yuri Gribov <tetra2...@gmail.com> wrote: > On Fri, Dec 2, 2016 at 6:35 AM, Maxim Ostapenko <chefm...@gmail.com> wrote: >> Hi, >> >> 02 Дек 2016 г. 7:30 пользователь "steven shi" <shijunj...@gmail.com> >> написал: >>> >>> 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 address-sanitizer+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
