From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from buffalo.birch.relay.mailchannels.net (buffalo.birch.relay.mailchannels.net [23.83.209.24]) by sourceware.org (Postfix) with ESMTPS id 2375D3858D20 for ; Tue, 8 Aug 2023 15:55:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2375D3858D20 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 AA9186C21F5; Tue, 8 Aug 2023 15:55:30 +0000 (UTC) Received: from pdx1-sub0-mail-a310.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 0A9D56C1C10; Tue, 8 Aug 2023 15:55:30 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1691510130; a=rsa-sha256; cv=none; b=9Ck7eOfhBKvUNt8hcKq041gjk9uWESuc0B9gJNpcVfsMz8DiuUH/yJd1RrVCWiPvp5H2Ar yD8DtwmI4WjuRgrbp65dWzu0IV4ZJr8w5Ni9bCKi8tqv+9MldWmfadv2Xc1JL+E3+/OrAp lwN+JfkpPHCAHSRTNfmJBe0U5ymxKsPv6WbNNSonG6ftMDHzgL7mBEykR9JzUAk0obk9ax mbao7UXrWSOreOSKfcvqWZcJmO9FCYV/ONYDFYBZ+GNwfvhRLihz0/eWa1sZ8WrSEaDOAi SZZxLKJd+s+uh2vi4HMwfDFn4aBAvRT/O+noWNsTK5rldshuhxV2cKCAw+hK7w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1691510130; 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=axTtYJNpfzSC7CfsWVSSp4R+3Ey3U6mb45NVRT0Yu28=; b=Sm6Q6UBwdV97Eqm91MAaIfu0M2FQN5UnIkR36V5PQKCk5e5aGPz4ZexWHHujArjrp0VCwC WOKVqwV4XTlBF+LeLkr4kguR7eOYdU92HDB5DRfpZYwVg6e83GOYSlbsTUVofaZKnUJ0Ya dbWINrZxup29ybeeTdxntYwz7FjUSs1PXDBqaFprrQv+h8ii8VDhpdfQB9w49zplzxaHvL ueRzgV80qQp0ZgJrjridkOcG+mZjk67u2j3VlLSEgIZxkNJ72B2x15jz8t8n2gjmPrS/go bLpNhe9bn/ygT/QvJ0ElBfdmYPU2EAA+E17PwRDXD+dy67llgmYbvBgZO4SYcA== ARC-Authentication-Results: i=1; rspamd-849d547c58-6mnq2; 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-Reign-Spill: 2b7f2b4c2e1d1d51_1691510130382_3431080031 X-MC-Loop-Signature: 1691510130382:2438887691 X-MC-Ingress-Time: 1691510130381 Received: from pdx1-sub0-mail-a310.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.107.249.188 (trex/6.9.1); Tue, 08 Aug 2023 15:55:30 +0000 Received: from [192.168.2.12] (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)) (No client certificate requested) (Authenticated sender: siddhesh@gotplt.org) by pdx1-sub0-mail-a310.dreamhost.com (Postfix) with ESMTPSA id 4RKySx0nWCzmf; Tue, 8 Aug 2023 08:55:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gotplt.org; s=dreamhost; t=1691510129; bh=axTtYJNpfzSC7CfsWVSSp4R+3Ey3U6mb45NVRT0Yu28=; h=Date:Subject:To:Cc:From:Content-Type:Content-Transfer-Encoding; b=enZrZOn+Vj9O9XbxMvZiaPF/U6OQKRkPb377Kh47BXDjkQEnb77TNkN3KEqW89262 fB9sLgc/3jwJvZYCLLCVGrjTFHpt3r6w2Xvfn7mtvnY6Jd5NfcSSl6VVBzzo80pE8U hbP0hY78AphclC0DpUuj702VAdo62mF+PV1/b8dIZdmb2mJYbUDmCdPDaKawMnhk7l 9/QpRulnhsNLRu0Ig3kzpRmBoDIm2q3oalsvFGsu3MzPsxcu206+RXk2BfnHucNB95 3/CDvXnKHFQz3uc7mmakDAd+djhfZJSnNALI8eGXcpfOFDgmjG88C5Cg0HXx4PtqCr MoWlTvU7zSIJQ== Message-ID: <2136b422-ae4c-423f-3fe1-3d964c6bd586@gotplt.org> Date: Tue, 8 Aug 2023 11:55:27 -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 Malcolm , Paul Koning , Jakub Jelinek , Andrea Corallo Cc: Richard Biener , David Edelsohn , GCC Patches , Carlos O'Donell References: <5dab0019-a28e-f6b1-c822-9217d4d2f59f@gotplt.org> <9390F610-3E72-4D54-9DE2-432BC7C65A1E@comcast.net> <941e119f796c33febe717603eea2265fc9909278.camel@redhat.com> From: Siddhesh Poyarekar In-Reply-To: <941e119f796c33febe717603eea2265fc9909278.camel@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3032.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,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: 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 >>> 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. Thanks, Sid