From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from butterfly.birch.relay.mailchannels.net (butterfly.birch.relay.mailchannels.net [23.83.209.27]) by sourceware.org (Postfix) with ESMTPS id 2DF563858C78 for ; Thu, 10 Aug 2023 18:51:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2DF563858C78 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gotplt.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id C602E760C66; Thu, 10 Aug 2023 18:50:59 +0000 (UTC) Received: from pdx1-sub0-mail-a257.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 5B56076118D; Thu, 10 Aug 2023 18:50:59 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1691693459; a=rsa-sha256; cv=none; b=8XRGutOsI/0dbHYUKxbnh2uCRbVWkhnBRzXQIceniWlDiNQQ0wq10Gn4RiXqhZMOsElbnO liatcIKvfqLt9POj+A6wO+O1Yu1RIHkPmMTCs5AEqcUhI968x8jBgKI+f7Aq95Oq8YN9UD xok9LbuTQgPNc8hzIU6oH6Fc+GCyjgHncVkg6Sg4huDYAFo3GyjVPw4TS071qwyyl/t3XW jIZRsHAIYqfaqkNEAGkbWtcbJoAs605V58fNjFCcOQ0N6yo0lYemmwCzLlG95m6T+cyeqD /6DLrI03x0v3gFcNHQ6JK22ltUcvR4BNpVV1EV3QIFKOQinWrtpIL2RE5/BYxQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1691693459; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=0eWFI2pYnejiVzQQHHRTc6q21YpQtT0fIrcOlN09rjk=; b=ihuw1mWf3LmQi3qV78Xgn1BaGGoMkGnGRtc8iqei5XLEhn/B6Ke71KJBTl+s7Yr+inYvLb naBNHGCSSFwxiQjMuyKgGu5xyftNkJzFDx8reEeIJMeSnWTuvBj4RcVrhrbztCzIJgKBq3 faJYZlyKczzMwP1VSSD/r8rU+ua/Yq1MZqEZsLNyFSZBYAoAwsEQLoamKrRw9O0+9cOgRM txVKFdK6RcCm0mCrS95nyK5du/66vTsh/E3FRqCRdoIrSDMvUHts597zTJuO+y5zjn9V9n CwXQRPDESokhyTucWlR1pWSt7l4YALkP43Cg4M0AhCoaz2s0NtKWN8R7hcgc/w== ARC-Authentication-Results: i=1; rspamd-749bd77c9c-xz725; auth=pass smtp.auth=dreamhost smtp.mailfrom=siddhesh@gotplt.org X-Sender-Id: dreamhost|x-authsender|siddhesh@gotplt.org X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|siddhesh@gotplt.org X-MailChannels-Auth-Id: dreamhost X-Chief-Desert: 4bd13aa81020c547_1691693459666_382667333 X-MC-Loop-Signature: 1691693459666:2858272202 X-MC-Ingress-Time: 1691693459666 Received: from pdx1-sub0-mail-a257.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.103.250.6 (trex/6.9.1); Thu, 10 Aug 2023 18:50:59 +0000 Received: from [192.168.224.119] (unknown [24.114.68.74]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by pdx1-sub0-mail-a257.dreamhost.com (Postfix) with ESMTPSA id 4RMGGT1KKSzh7; Thu, 10 Aug 2023 11:50:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gotplt.org; s=dreamhost; t=1691693459; bh=0eWFI2pYnejiVzQQHHRTc6q21YpQtT0fIrcOlN09rjk=; h=Date:Subject:To:From:Content-Type:Content-Transfer-Encoding; b=TPd0XO8ipz4QqWttQN+n1P/cBTklAKx+ngygDKMTt2JKgPdRtpKeBBRVMNQSYG7Xp n1R0C7TRQLEfZjpChlJCgD2SpaB+2ULquajz+1sgf3Q85+cFJLwm/1ofe89a+7hpPj QI1YfcpfnqyCeqaHoF8l8NUph5oZwx9yq21FXdUiKKUkBlSKnzssczOf6kuNGI1ed5 pu0rhubHknlGNNbihOH7WOKdYXwkvdQWySjxvrkU7eHLkz2DZaAEL2Yrilf9dPZpSI 0b27TKqJXAs/xmM5nYgv04gTZPJvZGaQ8lwiUsJEsG9diU+tWe/N1bLhsvykEAykRs J+C2ilShQbUOQ== Message-ID: <2dbb0178-ad06-ca40-1d77-675e0eb58a61@gotplt.org> Date: Thu, 10 Aug 2023 14:50:54 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.12.0 Subject: Re: [RFC] GCC Security policy Content-Language: en-US To: David Edelsohn , Richard Biener , Ian Lance Taylor , Jakub Jelinek , GCC Patches , Carlos O'Donell , richard.sandiford@arm.com References: <5dab0019-a28e-f6b1-c822-9217d4d2f59f@gotplt.org> <7d5145fa-85b8-5228-75ed-2ce1010c2aaf@gotplt.org> From: Siddhesh Poyarekar In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3030.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_MANYTO,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,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: On 2023-08-10 14:28, Richard Sandiford wrote: > Siddhesh Poyarekar writes: >> On 2023-08-08 10:30, Siddhesh Poyarekar wrote: >>>> Do you have a suggestion for the language to address libgcc, >>>> libstdc++, etc. and libiberty, libbacktrace, etc.? >>> >>> I'll work on this a bit and share a draft. >> >> Hi David, >> >> Here's what I came up with for different parts of GCC, including the >> runtime libraries. Over time we may find that specific parts of runtime >> libraries simply cannot be used safely in some contexts and flag that. >> >> Sid >> >> """ >> What is a GCC security bug? >> =========================== >> >> A security bug is one that threatens the security of a system or >> network, or might compromise the security of data stored on it. >> In the context of GCC there are multiple ways in which this might >> happen and they're detailed below. >> >> Compiler drivers, programs, libgccjit and support libraries >> ----------------------------------------------------------- >> >> The compiler driver processes source code, invokes other programs >> such as the assembler and linker and generates the output result, >> which may be assembly code or machine code. It is necessary that >> all source code inputs to the compiler are trusted, since it is >> impossible for the driver to validate input source code beyond >> conformance to a programming language standard. >> >> The GCC JIT implementation, libgccjit, is intended to be plugged >> into applications to translate input source code in the application >> context. Limitations that apply to the compiler >> driver, apply here too in terms of sanitizing inputs, so it is >> recommended that inputs are either sanitized by an external program >> to allow only trusted, safe execution in the context of the >> application or the JIT execution context is appropriately sandboxed >> to contain the effects of any bugs in the JIT or its generated code >> to the sandboxed environment. >> >> Support libraries such as libiberty, libcc1 libvtv and libcpp have >> been developed separately to share code with other tools such as >> binutils and gdb. These libraries again have similar challenges to >> compiler drivers. While they are expected to be robust against >> arbitrary input, they should only be used with trusted inputs. >> >> Libraries such as zlib and libffi that bundled into GCC to build it >> will be treated the same as the compiler drivers and programs as far >> as security coverage is concerned. >> >> As a result, the only case for a potential security issue in all >> these cases is when it ends up generating vulnerable output for >> valid input source code. > > I think this leaves open the interpretation "every wrong code bug > is potentially a security bug". I suppose that's true in a trite sense, > but not in a useful sense. As others said earlier in the thread, > whether a wrong code bug in GCC leads to a security bug in the object > code is too application-dependent to be a useful classification for GCC. > > I think we should explicitly say that we don't generally consider wrong > code bugs to be security bugs. Leaving it implicit is bound to lead > to misunderstanding. I see what you mean, but the context-dependence of a bug is something GCC will have to deal with, similar to how libraries have to deal with bugs. But I agree this probably needs some more expansion. Let me try and come up with something more detailed for that last paragraph. > There's another case that I think should be highlighted explicitly: > GCC provides various security-hardening features. I think any failure > of those feature to act as documented is poentially a security bug. > Failure to follow reasonable expectations (even if not documented) > might sometimes be a security bug too. Missed hardening in general does not put systems at immediate risk, so they're not considered CVE-worthy. In fact when bugs are evaluated for security risk at a source level (e.g. when NIST does it), hardening does not come into the picture at all. It's only at product levels that hardening features are accounted for, e.g. where -fstack-protector would reduce the seriousness of a stack buffer overflow and even there one must do an analysis to see if the generated code actually mitigated the overflow using the stack protector canary. Thanks, Sid