From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) by sourceware.org (Postfix) with ESMTPS id 010123858C54 for ; Tue, 8 Aug 2023 14:14:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 010123858C54 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-991c786369cso787753966b.1 for ; Tue, 08 Aug 2023 07:14:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691504053; x=1692108853; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=06tFKNPHFe6on5U4ecyC+7bau+1yVXmCsi9MWMj7ENk=; b=Xrq4VW96icFdWwVF5zDP+LOvNzVeNyEZdUWtpdI9Hfw0fA05Ikvfl+Fp7xCjATR6GA CZQ6tHZOzY1g34hYWnqu4cElc9LtZjcxBu9cltnI/0ckY/u6UdKOXUHv0Jj6zxmH6IVt qC31OH8Z+2KI2MRKJi1LKgFt+8PCam41G0wx66+DJJKgLv8Ll7A0AC1Yn6kZjar+AtkR nmZpMMoAiYNI/ZXN2l2qriEVdBIaUy83iBIgpirkBEs8PjBUCC+6/3l/wfcfwTR6gmmE eFulylR6ZuZyU7KR/HzUcdjz31ho0T5ZswHj8pCoCbMsZ0RZfHXlFTE8zkmRDbMQ7fxQ 5dUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691504053; x=1692108853; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=06tFKNPHFe6on5U4ecyC+7bau+1yVXmCsi9MWMj7ENk=; b=CCCmE+3adAiV3iUHYoasrMOPKtcNMEtf9Dro8GOnONim4IsdTn6HLavaNf4bV3H9co V+ZKVEuoHxdozLGCiwgL0rjxn7Zm78PEzaU/vfkg2uTXlDQ9kL0BR2bZMVVgKeKV4Jpg fXcNuh8TUZm+uox31y55B/HUBbByYrTYEJ0VuvFqustqFWfpvsySRSAUkpAWMZF8mFX2 caXGet+BZQDWMDsi9K/7m2sLx6tMi3NxVtDFcLnuauXxee/qx8LCB0ihm+TAY/PKZN4X FPO4z+DsvjfYPR10q8yaY4iFLLupQ+GpkvqOPbUqGOHx1ps+NaOGg342snXMtLKHHtfx AUng== X-Gm-Message-State: AOJu0YwFRrTx3yROzgmwcS3iukdgJZcjM1RAh+lsKq4NIh14XiUQeKiN aA2fqQvl6QJ/hD5dM7n8ru+493VG9N11ESN8wQc= X-Google-Smtp-Source: AGHT+IFiPxjRAYMSOWvRZ1jO86X6Ykl+7ZFmV+hpWDERMA039Iyd2VSAzod1wkn33dcR7mNkW0PK5CqT/Rh5qxfm6W4= X-Received: by 2002:a17:907:77d0:b0:994:5577:aeed with SMTP id kz16-20020a17090777d000b009945577aeedmr9749792ejc.5.1691504053322; Tue, 08 Aug 2023 07:14:13 -0700 (PDT) MIME-Version: 1.0 References: <5dab0019-a28e-f6b1-c822-9217d4d2f59f@gotplt.org> In-Reply-To: From: David Edelsohn Date: Tue, 8 Aug 2023 10:14:01 -0400 Message-ID: Subject: Re: [RFC] GCC Security policy To: Siddhesh Poyarekar Cc: Richard Biener , Ian Lance Taylor , Jakub Jelinek , GCC Patches , "Carlos O'Donell" Content-Type: multipart/alternative; boundary="0000000000003c0c36060269faf7" X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --0000000000003c0c36060269faf7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Aug 8, 2023 at 10:07=E2=80=AFAM Siddhesh Poyarekar wrote: > On 2023-08-08 10:04, Richard Biener wrote: > > On Tue, Aug 8, 2023 at 3:35=E2=80=AFPM Ian Lance Taylor wrote: > >> > >> On Tue, Aug 8, 2023 at 6:02=E2=80=AFAM Jakub Jelinek via Gcc-patches > >> 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 sta= ck > >>> 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. > I have added a line to the Note section in the proposed text: GCC and its tools provide features and options that can run arbitrary user code (e.g., -fplugin). I believe that the security implication already is addressed because the program is not tricked into a direct compromise of security. Do you have a suggestion for the language to address libgcc, libstdc++, etc. and libiberty, libbacktrace, etc.? Thanks, David --0000000000003c0c36060269faf7--