On Tue, Aug 8, 2023 at 6:02 AM Jakub Jelinek via Gcc-patches <gcc-patches@gcc.gnu.org> 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.
I wonder if a security policy should say something about the -fplugin option. I agree that an ICE is not a security issue, but I wonder how many people are aware that a poorly chosen command line option can direct the compiler to run arbitrary code. For that matter the same is true of setting the GCC_EXEC_PREFIX environment variable, and no doubt several other environment variables. My point is not that we should change these, but that a security policy should draw attention to the fact that there are cases in which the compiler will unexpectedly run other programs. Ian
