On Thu, Dec 1, 2016 at 10:31 PM, Yuri Gribov <tetra2...@gmail.com> wrote:
> Just curious, why did you chose to break ABI rather than reuse natural > padding? natural padding is usually zero. And asan needs objects to be aligned by 8 and then have redzones. > As for complexity - was it caused by user code relying on > implementation details (e.g. exact struct layout) or something else? > Mostly that. Like taking sizeof of a non-POD type and expecting it to be equal to something. But I've also got lost in clang complexities. (C++ is much more complex than a compiler IR, and so Clang is much more complex than LLVM) > > On Fri, Dec 2, 2016 at 8:18 AM, Konstantin Serebryany > <konstantin.s.serebry...@gmail.com> 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/AddressSanitizerIntraObjectOve > rflow > > (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 <tetra2...@gmail.com> wrote: > >> > >> 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. > > > > > > -- > > 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. > > -- > 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. > -- 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.
