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
<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/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 <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.

Reply via email to