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 harshitsharmajs@gmail.com 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