Re: Can gcc itself be tested with ubsan? If so, how?
On Tue, Sep 28, 2021 at 2:48 AM Toon Moene wrote: > > On 9/28/21 8:35 AM, Erick Ochoa via Gcc wrote: > > >> Can ubsan be used on the compiler itself? > > I regularly build the compiler(s) natively with ubsan enabled, see for > instance: > > https://gcc.gnu.org/pipermail/gcc-testresults/2021-September/719448.html > > The configure line tells you how to do it (towards the end of the mail): > > configure flags: --prefix=/home/toon/compilers/install/gcc --with-gnu-as > --with-gnu-ld --enable-languages=all,ada --disable-multilib > --disable-nls --with-build-config=bootstrap-ubsan --enable-checking=all > To elaborate on that, to see what the --with-build-config=bootstrap-ubsan configure flag does, you can check the file config/bootstrap-ubsan.mk > (the enable-checking part is not relevant, and can be omitted). > > Kind regards, > > -- > Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 > Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Security actions to mitigate future vulnerabilities
During my fuzzing test with libfuzzer I found out that GCC is not part of OSS-Fuzz project. Would be cool to discuss here a bit more about fuzzing GCC codebase in order to mitigate some future vulnerabilities that may appear. I can volunteer myself to add the necessary steps to fuzz GCC on the OSS Fuzz side, but I would like to get some status on: - Does GCC build system support at least AFL or libfuzzer? - Is there any infrastructure to automatically test this? - How to test GCC with fuzzing, if possible -- Sincerely, Luís Ferreira @ lsferreira.net signature.asc Description: This is a digitally signed message part
Re: Security actions to mitigate future vulnerabilities
On Tue, 28 Sept 2021 at 17:23, Luís Ferreira wrote: > > During my fuzzing test with libfuzzer I found out that GCC is not part > of OSS-Fuzz project. Would be cool to discuss here a bit more about > fuzzing GCC codebase in order to mitigate some future vulnerabilities > that may appear. I can volunteer myself to add the necessary steps to > fuzz GCC on the OSS Fuzz side, but I would like to get some status on: > > - Does GCC build system support at least AFL or libfuzzer? > - Is there any infrastructure to automatically test this? > - How to test GCC with fuzzing, if possible I'd like the libstdc++ and code to get fuzzed, and maybe std::filesystem::path construction. I've discussed it with people before, but none of us got around to setting it up.
Re: Security actions to mitigate future vulnerabilities
On Tue, 2021-09-28 at 17:59 +0100, Jonathan Wakely wrote: > On Tue, 28 Sept 2021 at 17:23, Luís Ferreira > wrote: > > > > During my fuzzing test with libfuzzer I found out that GCC is not > > part > > of OSS-Fuzz project. Would be cool to discuss here a bit more about > > fuzzing GCC codebase in order to mitigate some future > > vulnerabilities > > that may appear. I can volunteer myself to add the necessary steps > > to > > fuzz GCC on the OSS Fuzz side, but I would like to get some status > > on: > > > > - Does GCC build system support at least AFL or libfuzzer? > > - Is there any infrastructure to automatically test this? > > - How to test GCC with fuzzing, if possible > > I'd like the libstdc++ and code to get fuzzed, and > maybe std::filesystem::path construction. I've discussed it with > people before, but none of us got around to setting it up. My idea would be to start with libiberty mangling, since it is what I'm tackling right now. this can be further expaneded to libstdc++, if needed. Adding the infrastructure for that to automatically fuzz GCC components easily, would be desired as a first step, IMO. -- Sincerely, Luís Ferreira @ lsferreira.net signature.asc Description: This is a digitally signed message part
Re: Security actions to mitigate future vulnerabilities
On Tue, 28 Sept 2021 at 18:15, Luís Ferreira wrote: > > On Tue, 2021-09-28 at 17:59 +0100, Jonathan Wakely wrote: > > On Tue, 28 Sept 2021 at 17:23, Luís Ferreira > > wrote: > > > > > > During my fuzzing test with libfuzzer I found out that GCC is not > > > part > > > of OSS-Fuzz project. Would be cool to discuss here a bit more about > > > fuzzing GCC codebase in order to mitigate some future > > > vulnerabilities > > > that may appear. I can volunteer myself to add the necessary steps > > > to > > > fuzz GCC on the OSS Fuzz side, but I would like to get some status > > > on: > > > > > > - Does GCC build system support at least AFL or libfuzzer? > > > - Is there any infrastructure to automatically test this? > > > - How to test GCC with fuzzing, if possible > > > > I'd like the libstdc++ and code to get fuzzed, and > > maybe std::filesystem::path construction. I've discussed it with > > people before, but none of us got around to setting it up. > > My idea would be to start with libiberty mangling, since it is what I'm > tackling right now. this can be further expaneded to libstdc++, if > needed. Adding the infrastructure for that to automatically fuzz GCC > components easily, would be desired as a first step, IMO. Loads and loads of people seem to fuzz the demangler, judging by the number of bugs that get reported against it with reproducers that obviously come from a fizzer. It might be more useful to fuzz somethign else that everybody isn't already doing.
Re: Security actions to mitigate future vulnerabilities
On Tue, 2021-09-28 at 19:18 +0100, Jonathan Wakely wrote: > On Tue, 28 Sept 2021 at 18:15, Luís Ferreira > wrote: > > > > On Tue, 2021-09-28 at 17:59 +0100, Jonathan Wakely wrote: > > > On Tue, 28 Sept 2021 at 17:23, Luís Ferreira > > > > > > wrote: > > > > > > > > During my fuzzing test with libfuzzer I found out that GCC is not > > > > part > > > > of OSS-Fuzz project. Would be cool to discuss here a bit more > > > > about > > > > fuzzing GCC codebase in order to mitigate some future > > > > vulnerabilities > > > > that may appear. I can volunteer myself to add the necessary > > > > steps > > > > to > > > > fuzz GCC on the OSS Fuzz side, but I would like to get some > > > > status > > > > on: > > > > > > > > - Does GCC build system support at least AFL or libfuzzer? > > > > - Is there any infrastructure to automatically test this? > > > > - How to test GCC with fuzzing, if possible > > > > > > I'd like the libstdc++ and code to get fuzzed, > > > and > > > maybe std::filesystem::path construction. I've discussed it with > > > people before, but none of us got around to setting it up. > > > > My idea would be to start with libiberty mangling, since it is what > > I'm > > tackling right now. this can be further expaneded to libstdc++, if > > needed. Adding the infrastructure for that to automatically fuzz GCC > > components easily, would be desired as a first step, IMO. > > Loads and loads of people seem to fuzz the demangler, judging by the > number of bugs that get reported against it with reproducers that > obviously come from a fizzer. > > It might be more useful to fuzz somethign else that everybody isn't > already doing. The problem right now is that those fuzzing tests need to be done by hand. With the support of fuzzing + sanitization on the build system and with OSS Fuzz this is done continuously by Google clusters. I also see your point about prioritizing more critical things first. -- Sincerely, Luís Ferreira @ lsferreira.net signature.asc Description: This is a digitally signed message part
