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 today :) Thank you! I found I only need -fasan-shadow-offset for the fake stack red-zone in fact. You know, my firmware is self-contained, and I implement all the instrumentation library myself. So, no problem for the global variable and heap buffer shadow memory mapping. Only the stack instrumentation implementations are offered by compiler directly, which use the fixed offset for the shadow memory. If I disable the stack buffer protection, I can use both Asan and Kasan actually. Now, I have to set the -fasan-shadow-offset with Kasan in build time to enable the stack buffer protection. It is not perfect, but can work at least.
BTW, since my Uefi firmware (a.k.a bios) use the same Kasan as Linux kernel, I'm thinking whether it make sense if we enable the Kasan for the whole Linux booting process. I could reserve a fixed range physical memory as shadow memory according to config (dynamic is also ok for me, and I can pass this info through Uefi interface to Linux). The Linux boot loader and other kernel necessary modules can rebuild against the fixed shadow memory. This way can let the Kasan work through the all the flow from memory HW is ready to OS boot up. Does it make sense? Thanks Steven -- 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.
