On 2023-08-08 11:48, David Malcolm wrote:
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.
+1, this is precisely the kind of thing the security policy should warn
against and suggest using sandboxing for. The compiler (or libgccjit)
isn't really in a position to defend such uses, ICE or otherwise.
Thanks,
Sid
