> > > 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? > > > Yuri is right. My firmware is self-contained Uefi firmware(a.k.a Bios in old name, http://www.uefi.org/, https://github.com/tianocore/edk2), and I believe you are using it to boot OS in your PC or Server everyday. In Uefi firmware, it doesn't use other project library, e.g. Glibc, but implement everything by itself. To enable Asan, I can accept to re-compile every code, no problem for me. And I believe many other "low-level" projects can accept to re-compile every code, including OS kernel, hypervisor, IoT firmware, etc.
I think the 'ABI' you mentioned is the "firmware interface" in my side. I care the "firmware interface" and don't hope Asan change the structure layout in interface, because I need keep the interface consistent with OS loader to boot OS, e.g. Linux/Windows. But don't worry, I think there are many ways to let Asan know whether a structure is a interface or not. A easy way could be the "interface list", just like current -fsanitize- *blacklist*, to let Asan know which structure (or header file) is not need to instrumented. Another way in Uefi firmware is to check the #pragma pack (1) on the structure definition, e.g. the header files in folder https://github.com/tianocore/edk2/tree/master/MdePkg/Include/IndustryStandard, and Uefi firmware force the interface structure padding as 0. -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
