From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bird.elm.relay.mailchannels.net (bird.elm.relay.mailchannels.net [23.83.212.17]) by sourceware.org (Postfix) with ESMTPS id 24B253858C1F for ; Mon, 14 Aug 2023 13:26:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 24B253858C1F 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 3894E901F9C; Mon, 14 Aug 2023 13:26:05 +0000 (UTC) Received: from pdx1-sub0-mail-a279.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id C13AF902388; Mon, 14 Aug 2023 13:26:04 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1692019564; a=rsa-sha256; cv=none; b=4sdiLbacbIkOsGqYDcvMLqgWJjHLWgFZu/wFxwyngT7T4tXerIbfISN7PKaBpEZalrczc2 uWSAdhtdI8LqUKex3XBrQAA5t3mUrqE+9UKjm2AQ+ofym2/3Qf+ccuD8mQaegIj42S1Xcy aDisBhcZ0gN4SgmS1ix9vVQblM3+upn4IAOuLDeRXwARZCskahhOYJ2awcdtWLsFI/mvRr q/6kyJrt7FSvqs9MdrSyQYGAlqe32nSdSb6E1mAv++AFwsdINmG+Qry4PxcbGZtOKiaIf2 Rh7o7XnwiMZFzHrepq0s6ntvYHCv1gCMHCBIc+al34OJMhFNC2HWU9WuTkB/0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1692019564; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc: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=I4TbuGTJ9dnLvi0RqZ+dQo6LNlNM/UkA5ZZmFVc0Z44=; b=web/T2dBrtyG4qLa0BF0UOlDUpcJP23x4B2Q3PHbiyicIhKY14wqlVfXuKYf+L37rWwAfa C0w5MQcWzaWjNVleztj/vehZrkjKXzD3GvgSAylzQA2j9hnfvaETvaIfz2/otOHmlzAFww uD0s9IxK6RsroBX1Wn5D55bfLIZ5cdFOhoPz9saDAZ6T9P6hOTFO0dnj+CSnMH2tRuGKZg 6knbBecrADuHz4upM+KHYTFiTmxthngmwtScFljVG/sbeNisi/laxT/bEydqrij7yTxWy6 Zk51EJzm4oBtwWE/jmBEkqLt1NCR1rPF9XT+xf1mmbW0fPANxBvcYMJjuU5xzQ== ARC-Authentication-Results: i=1; rspamd-849d547c58-z6wt4; 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-Slimy-Reign: 04ce2f014f694022_1692019565030_3709336005 X-MC-Loop-Signature: 1692019565030:2712857252 X-MC-Ingress-Time: 1692019565030 Received: from pdx1-sub0-mail-a279.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.103.49.134 (trex/6.9.1); Mon, 14 Aug 2023 13:26:05 +0000 Received: from [192.168.0.182] (bras-vprn-toroon4834w-lp130-02-142-113-138-184.dsl.bell.ca [142.113.138.184]) (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-a279.dreamhost.com (Postfix) with ESMTPSA id 4RPZsm2ZKrzDZ; Mon, 14 Aug 2023 06:26:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gotplt.org; s=dreamhost; t=1692019564; bh=I4TbuGTJ9dnLvi0RqZ+dQo6LNlNM/UkA5ZZmFVc0Z44=; h=Date:Subject:To:Cc:From:Content-Type:Content-Transfer-Encoding; b=cV1slN2pFLJIZU5jRUD3n+tNO052EW9nZZOQ6eIoAUb2C08+m7qRB2aOxm+uyqNTR jsSju7H7fNT4KU86P7FcS3bhoTESb10WXIUki93znwJ1kBvBcLYU2jImAorCGDjFkh wgByZoHA7jFQrj0zj8w020ErCQSzJhM7cnbq6oNldkm+jQAV4+hnxgbQGVtQDt3+2X ZOhJ2C9v3IFGOhVK9EFCgpWElbl9/lEsmLPJvdtPvoYDks/qqePW6xVTLjecdgngCF nzT5LoAnb9ouLoTowYmNoD82vAOF7+EPopZfUeMBr4jPCW8rk6HBRmNbkqB5EkQld+ z5fivLs2Z/lwA== Message-ID: <97b01db2-d1bf-9859-f75e-452e677ffe63@gotplt.org> Date: Mon, 14 Aug 2023 09:26:03 -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 , GCC Patches Cc: Carlos O'Donell References: 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.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_ASCII_DIVIDERS,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,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: Hi, Here's the updated draft of the top part of the security policy with all of the recommendations incorporated. Thanks, 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 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. However if you find an issue in these libraries independent of their use in GCC, you should reach out to their upstream projects to report them. 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. As a result, the only case for a potential security issue in the compiler is when it generates vulnerable application code for trusted input source code that is conforming to the relevant programming standard or extensions documented as supported by GCC and the algorithm expressed in the source code does not have the vulnerability. The output application code could be considered vulnerable if it produces an actual vulnerability in the target application, specifically in the following cases: - The application dereferences an invalid memory location despite the application sources being valid. - The application reads from or writes to a valid but incorrect memory location, resulting in an information integrity issue or an information leak. - The application ends up running in an infinite loop or with severe degradation in performance despite the input sources having no such issue, resulting in a Denial of Service. Note that correct but non-performant code is not a security issue candidate, this only applies to incorrect code that may result in performance degradation severe enough to amount to a denial of service. - The application crashes due to the generated incorrect code, resulting in a Denial of Service. Language runtime libraries -------------------------- GCC also builds and distributes libraries that are intended to be used widely to implement runtime support for various programming languages. These include the following: * libada * libatomic * libbacktrace * libcc1 * libcody * libcpp * libdecnumber * libffi * libgcc * libgfortran * libgm2 * libgo * libgomp * libiberty * libitm * libobjc * libphobos * libquadmath * libsanitizer * libssp * libstdc++ These libraries are intended to be used in arbitrary contexts and as a result, bugs in these libraries may be evaluated for security impact. However, some of these libraries, e.g. libgo, libphobos, etc. are not maintained in the GCC project, due to which the GCC project may not be the correct point of contact for them. You are encouraged to look at README files within those library directories to locate the canonical security contact point for those projects and include them in the report. Once the issue is fixed in the upstream project, the fix will be synced into GCC in a future release. Most security vulnerabilities in these runtime libraries arise when an application uses functionality in a specific way. As a result, not all bugs qualify as security relevant. The following guidelines can help with the decision: - Buffer overflows and integer overflows should be treated as security issues if it is conceivable that the data triggering them can come from an untrusted source. - Bugs that cause memory corruption which is likely exploitable should be treated as security bugs. - Information disclosure can be security bugs, especially if exposure through applications can be determined. - Memory leaks and races are security bugs if they cause service breakage. - Stack overflow through unbounded alloca calls or variable-length arrays are security bugs if it is conceivable that the data triggering the overflow could come from an untrusted source. - Stack overflow through deep recursion and other crashes are security bugs if they cause service breakage. - Bugs that cripple the whole system (so that it doesn't even boot or does not run most applications) are not security bugs because they will not be exploitable in practice, due to general system instability. Diagnostic libraries -------------------- The sanitizer library bundled in GCC is intended to be used in diagnostic cases and not intended for use in sensitive environments. As a result, bugs in the sanitizer will not be considered security sensitive. GCC plugins ----------- It should be noted that GCC may execute arbitrary code loaded by a user through the GCC plugin mechanism or through system preloading mechanism. Such custom code should be vetted by the user for safety as bugs exposed through such code will not be considered security issues. Security hardening implemented in GCC ------------------------------------- GCC implements a number of security features that reduce the impact of security issues in applications, such as -fstack-protector, -fstack-clash-protection, _FORTIFY_SOURCE and so on. A failure in these features functioning perfectly in all situations is not a security issue in itself since they're dependent on heuristics and may not always have full coverage for protection.