> On Aug 8, 2023, at 11:55 AM, Siddhesh Poyarekar <siddh...@gotplt.org> wrote:
>
> 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.
I agree somewhat. But only somewhat, because the compiler's job is not to
crash even if presented with bad inputs. An ICE is a bug, which of course
we've always accepted. But as several have agreed, it's not a DoS bug,
therefore not a security bug.
The scenario of the web browser is a valid one, and I would use it to
illustrate a general point, which is redundancy in safety measures. If inputs
come from possibly hostile sources, it's sound practice to have multiple layers
of protection. The consuming software should be robust so it doesn't fail when
subjected to bad inputs. But additional layers of protection in case there is
a defect in the first layer are valuable, and sandboxing or the like (chroot,
for example) can provide that additional defense. This isn't really a GCC
issue but rather a general principle of prudence.
paul
