Asan/Ubsan for further testing

[Shawn C]

Hi,

coreboot have two types of sanitizers already: Ubsan and Asan. This is good starting point. I found a few catches by simply enabling CONFIG_COVERAGE, CONFIG_UBSAN and CONFIG_ASAN:
https://ticket.coreboot.org/issues/288

The developer seems haven't enable them in the testing process yet. It would be better if we add those debug features by default during the development which could possibly kill more bugs in the coreboot and the sanitizers themselves. Any ideas?

regards
Shawn C

[Harshit Sharma]

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
https://doc.coreboot.org/technotes/asan.html 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

On Mon, Jan 4, 2021 at 9:30 PM Shawn C  wrote:
> Hi,
>
> coreboot have two types of sanitizers already: Ubsan and Asan. This is
> good starting point. I found a few catches by simply enabling
> CONFIG_COVERAGE, CONFIG_UBSAN and CONFIG_ASAN:
> https://ticket.coreboot.org/issues/288
>
> The developer seems haven't enable them in the testing process yet. It
> would be better if we add those debug features by default during the
> development which could possibly kill more bugs in the coreboot and the
> sanitizers themselves. Any ideas?
>
> regards
> Shawn C
>
> coreboot mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[DuPLomb]

Hey Harshit,
I think you sent this mail to me by accident.
Kind Regards,
Lombard

Am Tue, 5 Jan 2021 08:11:17
-0800 schrieb Harshit Sharma :
> 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
> https://doc.coreboot.org/technotes/asan.html 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
>
> On Mon, Jan 4, 2021 at 9:30 PM Shawn C 
> wrote:
> > Hi,
> >
> > coreboot have two types of sanitizers already: Ubsan and Asan. This
> > is good starting point. I found a few catches by simply enabling
> > CONFIG_COVERAGE, CONFIG_UBSAN and CONFIG_ASAN:
> > https://ticket.coreboot.org/issues/288
> >
> > The developer seems haven't enable them in the testing process yet.
> > It would be better if we add those debug features by default during
> > the development which could possibly kill more bugs in the coreboot
> > and the sanitizers themselves. Any ideas?
> >
> > regards
> > Shawn C
> >
> > coreboot mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]

[Shawn C]

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  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