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.

Reply via email to