Re: How to enable GCC Asan dynamic shadow address?

Hi Yuri, > > > Note that this flag only allows you to set fixed offset (in contrast, > > dynamic offset allows the selection to be done at runtime). This may > > or may not be enough for your case. > It is not perfect but really works for me. I have enabled gcc Kasan on my Uefi firmware

Re: How to enable GCC Asan dynamic shadow address?

Hi Yuri, I'm trying to use the Kasan -fasan-shadow-offset option to work around the Asan fixed shadow offset issue in gcc. I see you enabled it with this patch https://patchwork.ozlabs.org/patch/402873/. If it works, I will replace the Asan with

Re: How to enable GCC Asan dynamic shadow address?

Hi Max, Thanks in advance. My firmware users use gcc much more than clang, so I appreciate if you could give priority to the gcc dynamic shadow feature. Thanks Steven -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from

Re: How to enable GCC Asan dynamic shadow address?

Clang does works, at least for X64, and I have depended on it to enable the LLVM Asan in my Uefi firmware. I can see the related patch is here: https://reviews.llvm.org/D23354. Although this patch say it is for Windows 64bits, but I think this patch is architecture independent, isn't it? The

How to enable GCC Asan dynamic shadow address?

he dynamic shadow address in the module entry as "__asan_shadow_memory_dynamic_address = DynamicShadowAddress". What's the equivalent build option in gcc? Thank you help! Steven Shi -- You received this message because you are subscribed to the Google Groups "address-sanitizer&qu

Re: Proposal to add support for structure inner elements in Asan

> This is much harder than it sounds. > I understand although I'm not compiler guy. But it is worthy and it will make Asan really cover most of memory access in practice. > I've made an attempt ~2 years ago and it almost, but not quite entirely, > worked > >

Proposal to add support for structure inner elements in Asan

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

Re: About Asan ASAN_MEMORY_ACCESS_CALLBACK_BODY macro

OK, I think I understand now. The (s8) is the key. It force cast the 0xf9 value to a signed negative char which is less than 3. Thank you anyway! -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop

Re: About Asan ASAN_MEMORY_ACCESS_CALLBACK_BODY macro

Dmitry, thank you response. I'd like to use a example to invite you help me clarify this magic more clearly. Thank your patience. Below simple code has a global variable buffer overflow in line 6, and the Asan can correctly detect and report it. In this case, Asan use __asan_report_store4

About Asan ASAN_MEMORY_ACCESS_CALLBACK_BODY macro

Hello, I'm porting the Asan RT lib to my firmware, and I meet a issue to block my shadow memory checking work correctly. I have to update the Asan core logic macro to let it works in my side, and I hope some expert could help me understand below code correctly. LLVM Asan use below macro to

who calls asan.module_ctor to do the asan module init?

LLVM asan cannot support my firmware? Any suggestion is welcomed. Thanks Steven Shi -- 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

Re: Does LLVM Asan with -fsanitize=kernel-address support check glabal and stack buffer issues?

Yes. It works after I rebuild with CMAKE_BUILD_TYPE=Debug. And the build folder size increase from 1.7GB to 30GB... O_O. Thank you! -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails

Re: Does LLVM Asan with -fsanitize=kernel-address support check glabal and stack buffer issues?

Hi Vyukov, Do you mean directly add "-mllvm -debug" flags in clang build option? It doesn't work for me. E.g. I build below global buffer overflow example with "-mllvm -debug" flags, the clang build fail with "Unknown command". Please advise.

Does LLVM Asan with -fsanitize=kernel-address support check glabal and stack buffer issues?

Hello, I like to use the -fsanitize=kernel-address option, and I believe it better fit my firmware scenario rather than -fsanitize=address. I but after take a look at the current LLVM Asan implementation, I have some concerns that kernel-address might disable the global and stack