On Tue, 2023-08-08 at 09:33 -0400, Paul Koning via Gcc-patches wrote: > > > > On Aug 8, 2023, at 9:01 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. > > Indeed. But my answer would be that such things are not DoS issues. > DoS means that an external input, over which you have little control, > is impairing service. In the case of a compiler, if feeding it bad > source code X.c causes it to crash, the answer is "well, then don't > do that".
Agreed. I'm not sure how to "wordsmith" this, but it seems like the sources and options on the *host* are assumed to be trusted, and that the act of *compiling* source on the host requires trusting them, just like the act of executing the compiled code on the target does. Though users may be more familiar with sandboxing the target than the host. We should spell this out further for libgccjit: libgccjit allows for ahead-of-time and JIT compilation of sources - but it assumes that those sources (and the compilation options) are trusted. [Adding Andrea Corallo to the addressees] For example, Emacs is using libgccjit to do ahead-of-time compilation of Emacs bytecode. I'm assuming that Emacs is assuming that its bytecode is trusted, and that there isn't any attempt by Emacs to sandbox the Emacs Lisp being processed. However, consider a situation in which someone attempted to, say, embed libgccjit inside a web browser to generate machine code from JavaScript, where the JavaScript is potentially controlled by an attacker. I think we want to explicitly say that that if you're going to do that, you need to put some other layer of defense in, so that you're not blithely accepting the inputs to the compilation (sources and options) from a potentially hostile source, where a crafted input sources could potentially hit an ICE in the compiler and thus crash the web browser. Dave
