On Tue, Aug 8, 2023 at 3:01 PM Jakub Jelinek <ja...@redhat.com> wrote: > > On Tue, Aug 08, 2023 at 02:52:57PM +0200, Richard Biener via Gcc-patches > wrote: > > There's probably external tools to do this, not sure if we should replicate > > things in the driver for this. > > > > But sure, I think the driver is the proper point to address any of such > > issues - iff we want to address them at all. Maybe a nice little > > google summer-of-code project ;) > > What I'd really like to avoid is having all compiler bugs (primarily ICEs) > considered to be security bugs (e.g. DoS category), it would be terrible to > release every week a new compiler because of the "security" issues. > Running compiler on untrusted sources can trigger ICEs (which we want to fix > but there will always be some), or run into some compile time and/or compile > memory issue (we have various quadratic or worse spots), compiler stack > limits (deeply nested stuff e.g. during parsing but other areas as well). > So, people running fuzzers and reporting issues is great, but if they'd get > a CVE assigned for each ice-on-invalid-code, ice-on-valid-code, > each compile-time-hog and each memory-hog, that wouldn't be useful. > Runtime libraries or security issues in the code we generate for valid > sources are of course a different thing.
We can only hope they get "confused" by our nice reporting of segfaults ... Richard. > Jakub >
