From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 19A493858C2A for ; Tue, 12 Dec 2023 12:17:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 19A493858C2A Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 19A493858C2A Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702383425; cv=none; b=p4Us8giwQlnsFKG+VjXgVx+g3wV3wdPWGp8EgJYnjwZUi55xsRCCAl40e5xeCCuWDkKVRlXmmC95y37y7AyS+iUQSDDTgwxo04BUamcf5n5R/LFnwfnjvr53bD5K3nUJTFa69PRRy92CW9/mEMOFNCCYFdgYUF7nEywxG5pieLE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1702383425; c=relaxed/simple; bh=/P6tWQltPzHVk5cfH8goRg8MXXpAtlLK1l4dzmzU0gQ=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=ojPriWWjEVqvLVXmYlpOPni0rnyERISaJqCguwo7tlgvZqgSrfGgfTTuFN7V5JQRVdTtNB7ipFGnrAfuX1ge/9t3tPSXjmaE7YKR7sf9zzBuiwFQYg0UQiMGJ7hoP8Hpqwr/mj5yv6TgUq2lBPQNkFipmAljq3emOXUZ+9Aa/Kg= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1702383421; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=VCHiVunErQ6/9rfH0Ot+hEQDXa2FQ2u2aRhDdq0uyUs=; b=Zynk3d1pQGXeFSn+6ETFSsfkFPqFKImDi23DNYyEqMoTFXJr6SQSkcbSByqJiC6KabMfZt yZRddxHOYa2oZuPG2knRyHy0xhNWwdXR6crv+XpITFIQIey3J0G9bNXxAQlpgqlSlZ3eZG 90iAnmryF2nYyKT2UybiZ9mYb46xKZM= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-16-PGC2fMKmOWaGypMQvf-H3g-1; Tue, 12 Dec 2023 07:17:00 -0500 X-MC-Unique: PGC2fMKmOWaGypMQvf-H3g-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 0B47F185A783 for ; Tue, 12 Dec 2023 12:17:00 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.100]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7CD492166B31 for ; Tue, 12 Dec 2023 12:16:59 +0000 (UTC) From: Florian Weimer To: gcc@gcc.gnu.org Subject: -fcf-protection default on x86-64 (also for -fhardened) Date: Tue, 12 Dec 2023 13:16:57 +0100 Message-ID: <87fs07k43q.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-4.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,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: Currently, -fcf-protection defaults to both shadow stack and indirect branch tracking (IBT) on x86_64-linux-gnu, and -fhardened follows that. I think it should only enable shadow stack at this point. I'm not sure if this is a good idea because there will likely be no userspace support for IBT when GCC 14 releases, so these binaries will not be tested. They will carry markup that indicates compatibility with IBT, though. If there turns out to be a problem, we'd have to revision the markup and disable IBT for all existing binaries (because we don't know which ones have the toolchain fix applied). I think we can keep the shadow stack markup because there will be ways to test for compatibility fairly soon. The risk is also fairly reduced for shadow stack because there are no code generation changes in generic code, while for IBT every function that has their address taken needs a different prologue. As far as I understand it, there won't be any i386 GNU/Linux support for shadow stacks, so -fhardened shouldn't enable it on that target. Furthermore, ENDBR32 is incompatible with the i386 baseline ISA because it's a long NOP. Thanks, Florian