Just curious, why did you chose to break ABI rather than reuse natural padding? As for complexity - was it caused by user code relying on implementation details (e.g. exact struct layout) or something else?
On Fri, Dec 2, 2016 at 8:18 AM, Konstantin Serebryany <[email protected]> wrote: > 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. -- 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.
