Hi Harshit, I really appreciate your work on ASan. It's very helpful for killing bugs. Deferenceing the shadow_addr is supposed to return either 0 or unsigned random number and it's basically what you'll expect if you compile an userspace program with GCC-v7.3/v8.3/v9.3 as I mentioned in the previous bug report. But the Ubsan compliant in coreboot( e.g: memory_is_poisoned_16()) act differently. Neither "return *shadow_addr != 0 ? true : false" or "return *shadow_addr ? 1 : 0" won't silence Ubsan. Any ideas?
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Tuesday, January 5, 2021 4:11 PM, Harshit Sharma <[email protected]> wrote: > Hi Shawn, > > I am glad that you found these sanitizers useful. Presently, Ubsan is > available in ramstage on all platforms whereas ASan is only available on x86 > platforms. You can refer to this page to learn more about ASan in coreboot. > > Regarding the type mismatch in memory_is_poisoned_16(), I don't see any > problem with the current implementation. Dereferencing shadow_addr returns > either 0 or unsigned chars FA, F1, F2, etc depending upon the type of memory > bug found. However, if we just want to silence Ubsan here, I think we change > it to something like return *shadow_addr != 0 ? true : false. I would like to > hear others' opinions on this. > > Best, > Harshit > _______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
