On Mon, Jun 12, 2017 at 9:23 AM, steven shi <shijunj...@gmail.com> wrote: > 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?
Cc Andrew (he's KAsan implementor so has more informed opinion). -- 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.
