From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bumble.birch.relay.mailchannels.net (bumble.birch.relay.mailchannels.net [23.83.209.25]) by sourceware.org (Postfix) with ESMTPS id AEB5B3858D3C for ; Mon, 4 Dec 2023 16:26:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AEB5B3858D3C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=gotplt.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gotplt.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org AEB5B3858D3C Authentication-Results: server2.sourceware.org; arc=pass smtp.remote-ip=23.83.209.25 ARC-Seal: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1701707217; cv=pass; b=c96aU7UEfTHZvkcRU9bJYhBkAA0FBZadKPCKB1VIOyreRk87TFvB8IOiFTjYDl9LzfHgHUGIhV+aZGb3UONWzjAQQ8gBnDoPmYoeecqQ52gO4WAk/P4yoY2MJcY5PuhgUYPo6BQ25lsH9n4sCh6ovKmtp/Jd1UG2zCulxwakq4o= ARC-Message-Signature: i=2; a=rsa-sha256; d=sourceware.org; s=key; t=1701707217; c=relaxed/simple; bh=HHRd1lOMVJ9ktXlCJCH0QSI1XjFwxpdB8aBwiyhPA70=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=H67uRIiWG7xgrsGGDoj5oLmhFLE3M2kWblEbO+rKGHLmclrvett1yi91f8JkE/CMFMSOcLRq7YF2zltmOzZH4rbDmoOz4aF1FJUa370adkhIMxi/j3vIFdRKNfG5x02xwknS5pV/qjx3lY8BHLB+YleoMg5F74WTx6teQHiPDp4= ARC-Authentication-Results: i=2; server2.sourceware.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 21485901EA5; Mon, 4 Dec 2023 16:26:52 +0000 (UTC) Received: from pdx1-sub0-mail-a202.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id AB454901EEB; Mon, 4 Dec 2023 16:26:51 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1701707211; a=rsa-sha256; cv=none; b=vViAJwZbC15YXpQ2iMtIYqtwGHcT9G/R7gG2IyT0qNZ59OgDY6nLVr9dKdtm+ENl+TDFRY +2TZ4KTu7v7q8Ls4CSDZSHrjWfujxjDi8PHaH5uiZmLbL0FAi264dtJMZYDRFSFvAoqO4e H5Cuw1mj8+loR3JxInpGqahPIeP0sRCkR+4qMWz+VKlU7FDMeO1o/OHON7QMvxTeAuXv0h qCS48s2Ndbri8GE+654fM9WIS28g+oQWuN5X2pS6hMvkaXa40iWec4cJMy48w1HiH9JfmM gquNZZr+KwqDhtGgi8DYEbXCGo1fX+lm5otDSergo1Cetl7z08zLQWbJbn4iaQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1701707211; 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=VQMdeu4GESsZOl6YfYcL0U/QbzY0QD8KLQt2xl+X3tA=; b=TBVeSdZzZjJkhtM6SW4w1LV7bD/zT0n0UgU6RBiAFHChQ7E/RoRy/CZJKNUsQPjiUu+QJd 9uOMHadCnlApehElHSHJE7KEjrBNXqyJsrZXyg7JF+so2EpQoBTMdPS4sAnPVwD0H0kDlK MOT2odWefzUVxa6w/yAwE5+MNlLqZhqm8IuoeQJypCapgGM8iCgHYKHIoX6u7tEtNRbYOg 9M0w9bR4XsoSJQE7XbYXiCiNY6EguOGw+RHU6Va0cnsothQ1kusF3DU+VukAMvSrvk+MzZ sYACH+VG/SmALm01timaR/zsVK84qDeeySGHa3B+J291wVLFQpQ+LdaYMM8ArA== ARC-Authentication-Results: i=1; rspamd-696ff67dc8-b7gc8; 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-Cooing-Bored: 1ce7795a4aaf29f9_1701707211837_3939030728 X-MC-Loop-Signature: 1701707211837:4015219182 X-MC-Ingress-Time: 1701707211836 Received: from pdx1-sub0-mail-a202.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.118.12.6 (trex/6.9.2); Mon, 04 Dec 2023 16:26:51 +0000 Received: from [192.168.2.12] (bras-vprn-toroon4834w-lp130-02-142-113-138-136.dsl.bell.ca [142.113.138.136]) (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-a202.dreamhost.com (Postfix) with ESMTPSA id 4SkTZg1Rsrzf1; Mon, 4 Dec 2023 08:26:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gotplt.org; s=dreamhost; t=1701707211; bh=VQMdeu4GESsZOl6YfYcL0U/QbzY0QD8KLQt2xl+X3tA=; h=Date:Subject:To:Cc:From:Content-Type:Content-Transfer-Encoding; b=Rx3V0TGlJGcEtNmelj+n0sQgeua068USsIslNNVHgQlFM8YVIqYJiuuCilCdrZWDe bf2eDWOMek0wHoPFRxokK9eo8Gpn8NoNE6e5/2wJNhuCvpTkHar1dTu6PWhZ1YOAyt AMc4fJks+OW3DHjt1+BOEMQ4N22Vx0DI3k/p7yQNuTpvX4V2j7qdag6gKtycDeviiN 18YDXC0rcQHCnD4q4a7l4H/jrK2MKe4NiPkEWHs1g/OvJQpwXpk/5GnFidYT6czor6 V2rJJCMPnynahX8gSAUyK0ls97toKje2vmnlQITVPFClFR9EpAddlCLc4NWwNVQ5gz zIM6yhW3sMM4Q== Message-ID: Date: Mon, 4 Dec 2023 11:26:49 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] gcc: Disallow trampolines when -fhardened Content-Language: en-US To: Martin Uecker , polacek@redhat.com Cc: gcc-patches@gcc.gnu.org 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.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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-12-02 04:42, Martin Uecker wrote: > >> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? >> >> -- >8 -- >> It came up that a good hardening strategy is to disable trampolines >> which may require executable stack. Therefore the following patch >> adds -Werror=trampolines to -fhardened. > > This would add a warning about specific code (where it is then > unclear whether rewriting it is feasible or even an improvement), > which seems different to all the other flags -fhardening has > now. It's actually -Werror=trampolines, not just -Wtrampolines; the aim is to hard fail on producing trampolines and consequently, an executable stack. In general the goal of -fhardened is to produce hardened code and the nested function trampolines do the exact reverse of that, so -Werror=trampolines seems to align perfectly with that goal, doesn't it? > GCC now has an option to allocate trampolines on the heap, > which would seem to be a better fit. On the other hand, > it does not work with longjmp which may be a limitation. For hardened code in C, I think we really should look to step away from nested functions instead of adding ways to continue supporting it. There's probably a larger conversation to be had about the utility of nested functions in general for C (and whether this GCC extension should be deprecated altogether in future), but I feel like the -fhardened subset gives us the opportunity to enforce at least a safe subset for now, possibly extending it in future. Thanks, Sid