public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Siddhesh Poyarekar <siddhesh@gotplt.org>
To: Richard Biener <richard.guenther@gmail.com>,
	Ian Lance Taylor <iant@google.com>
Cc: Jakub Jelinek <jakub@redhat.com>,
	David Edelsohn <dje.gcc@gmail.com>,
	GCC Patches <gcc-patches@gcc.gnu.org>,
	Carlos O'Donell <carlos@redhat.com>
Subject: Re: [RFC] GCC Security policy
Date: Tue, 8 Aug 2023 10:06:57 -0400	[thread overview]
Message-ID: <ea16c3bd-8653-72d2-b7d4-8677f1a11f59@gotplt.org> (raw)
In-Reply-To: <CAFiYyc2eiOX-Tw4mRPWhw86kiHNXq0LoEAAU0N1gB7EhyO493Q@mail.gmail.com>

On 2023-08-08 10:04, Richard Biener wrote:
> On Tue, Aug 8, 2023 at 3:35 PM Ian Lance Taylor <iant@google.com> wrote:
>>
>> 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.
> 
> Well, if you run an arbitrary commandline from the internet you get
> what you deserve, running "echo "Hello World" | gcc -xc - -o /dev/sda"
> as root doesn't need plugins to shoot yourself in the foot.  You need to
> know what you're doing, otherwise you are basically executing an
> arbitrary shell script with whatever privileges you have.

I think it would be useful to mention caveats with plugins though, just 
like it would be useful to mention exceptions for libiberty and similar 
libraries that gcc builds.  It only helps makes things clearer in terms 
of what security coverage the project provides.

Thanks,
Sid

  reply	other threads:[~2023-08-08 14:07 UTC|newest]

Thread overview: 72+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-07 17:29 David Edelsohn
2023-08-08  8:16 ` Richard Biener
2023-08-08 12:33   ` Siddhesh Poyarekar
2023-08-08 12:52     ` Richard Biener
2023-08-08 13:01       ` Jakub Jelinek
2023-08-08 13:21         ` Richard Biener
2023-08-08 13:24         ` Michael Matz
2023-08-08 13:33         ` Paul Koning
2023-08-08 15:48           ` David Malcolm
2023-08-08 15:55             ` Siddhesh Poyarekar
2023-08-08 16:35               ` Paul Koning
2023-08-08 20:02             ` Joseph Myers
2023-08-08 13:34         ` Ian Lance Taylor
2023-08-08 14:04           ` Richard Biener
2023-08-08 14:06             ` Siddhesh Poyarekar [this message]
2023-08-08 14:14               ` David Edelsohn
2023-08-08 14:30                 ` Siddhesh Poyarekar
2023-08-08 14:37                   ` Jakub Jelinek
2023-08-08 14:40                     ` Siddhesh Poyarekar
2023-08-08 16:22                       ` Richard Earnshaw (lists)
2023-08-08 17:35                     ` Ian Lance Taylor
2023-08-08 17:46                       ` David Edelsohn
2023-08-08 19:39                         ` Carlos O'Donell
2023-08-09 13:25                           ` Richard Earnshaw (lists)
2023-08-09 17:32                   ` Siddhesh Poyarekar
2023-08-09 18:17                     ` David Edelsohn
2023-08-09 20:12                       ` Siddhesh Poyarekar
2023-08-10 18:28                     ` Richard Sandiford
2023-08-10 18:50                       ` Siddhesh Poyarekar
2023-08-11 14:36                         ` Siddhesh Poyarekar
2023-08-11 15:09                           ` Paul Koning
2023-08-11 15:20                             ` Siddhesh Poyarekar
2023-08-10 19:27                       ` Richard Biener
2023-08-11 15:12                     ` David Edelsohn
2023-08-11 15:22                       ` Siddhesh Poyarekar
2024-02-09 15:38       ` Martin Jambor
2024-02-09 15:55         ` Siddhesh Poyarekar
2024-02-09 17:14           ` Joseph Myers
2024-02-09 17:39             ` Siddhesh Poyarekar
2024-02-09 20:06               ` Joseph Myers
2024-02-12 13:32                 ` Siddhesh Poyarekar
2024-02-12 13:16           ` Martin Jambor
2024-02-12 13:35             ` Siddhesh Poyarekar
2024-02-12 15:00               ` Richard Biener
2024-02-13 12:34                 ` Siddhesh Poyarekar
2023-08-14 13:26 ` Siddhesh Poyarekar
2023-08-14 18:51   ` Richard Sandiford
2023-08-14 19:31     ` Siddhesh Poyarekar
2023-08-14 21:16       ` Alexander Monakov
2023-08-14 21:50         ` Siddhesh Poyarekar
2023-08-15  5:59           ` Alexander Monakov
2023-08-15 10:33             ` Siddhesh Poyarekar
2023-08-15 14:07               ` Alexander Monakov
2023-08-15 14:54                 ` Paul Koning
2023-08-15 19:13                 ` Siddhesh Poyarekar
2023-08-15 23:07                   ` Alexander Monakov
2023-08-15 23:45                     ` David Edelsohn
2023-08-16  0:37                       ` Alexander Monakov
2023-08-16  0:50                         ` Paul Koning
2023-08-16  7:53                           ` Alexander Monakov
2023-08-16 13:06                             ` Paul Koning
2023-08-16  9:05                     ` Toon Moene
2023-08-16 12:19                     ` Siddhesh Poyarekar
2023-08-16 15:06                       ` Alexander Monakov
2023-08-16 15:18                         ` Siddhesh Poyarekar
2023-08-16 16:02                           ` Alexander Monakov
2023-08-15 23:45   ` David Malcolm
2023-08-16  8:25     ` Alexander Monakov
2023-08-16 11:39       ` Siddhesh Poyarekar
2023-08-16 11:50         ` Alexander Monakov
2023-09-06 11:23 ` Siddhesh Poyarekar
2023-09-20  7:36 ` Arnaud Charlet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ea16c3bd-8653-72d2-b7d4-8677f1a11f59@gotplt.org \
    --to=siddhesh@gotplt.org \
    --cc=carlos@redhat.com \
    --cc=dje.gcc@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=iant@google.com \
    --cc=jakub@redhat.com \
    --cc=richard.guenther@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).