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


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