Bug#1113864: marked as done (Replace -fcf-protection=full with -fcf-protection=return)

This is a multi-part message in MIME format...

------------=_1780833064-1484309-0
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

Your message dated Sun, 7 Jun 2026 13:48:53 +0200
with message-id <[email protected]>
and subject line Re: Bug#1113864: Replace -fcf-protection=3Dfull with -fcf-=
protection=3Dreturn
has caused the Debian Bug report #1113864,
regarding Replace -fcf-protection=3Dfull with -fcf-protection=3Dreturn
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)


--=20
1113864: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D1113864
Debian Bug Tracking System
Contact [email protected] with problems

------------=_1780833064-1484309-0
Content-Type: message/rfc822
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Received: (at submit) by bugs.debian.org; 3 Sep 2025 14:31:39 +0000
X-Spam-Checker-Version: SpamAssassin 4.0.1-bugs.debian.org_2005_01_02
	(2024-03-25) on buxtehude.debian.org
X-Spam-Level: 
X-Spam-Status: No, score=-15.2 required=4.0 tests=BAYES_00,
	BODY_INCLUDES_PACKAGE,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,
	DKIM_VALID_EF,HAS_PACKAGE,RCVD_IN_MSPIKE_H2,
	RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED,
	RCVD_IN_VALIDITY_SAFE_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham
	autolearn_force=no version=4.0.1-bugs.debian.org_2005_01_02
X-Spam-Bayes: score:0.0000 Tokens: new, 22; hammy, 149; neutral, 81; spammy,
	1. spammytokens:0.995-+--Today hammytokens:0.000-+--XDebbugsCc,
	0.000-+--X-Debbugs-Cc, 0.000-+--trixie, 0.000-+--grohne,
	0.000-+--Grohne
Return-path: <[email protected]>
Received: from 10.mo533.mail-out.ovh.net ([46.105.72.194]:54091)
	by buxtehude.debian.org with esmtps (TLS1.3:ECDHE_X25519__RSA_PSS_RSAE_SHA256__AES_256_GCM:256)
	(Exim 4.96)
	(envelope-from <[email protected]>)
	id 1utoWR-004pfW-1h
	for [email protected];
	Wed, 03 Sep 2025 14:31:39 +0000
Received: from director3.derp.mail-out.ovh.net (director3.derp.mail-out.ovh.net [152.228.215.222])
	by mo533.mail-out.ovh.net (Postfix) with ESMTPS id 4cH4cz0DVgz5wxN
	for <[email protected]>; Wed,  3 Sep 2025 14:24:51 +0000 (UTC)
Received: from director3.derp.mail-out.ovh.net (director3.derp.mail-out.ovh.net. [127.0.0.1])
        by director3.derp.mail-out.ovh.net (inspect_sender_mail_agent) with SMTP
        for <[email protected]>; Wed,  3 Sep 2025 14:24:50 +0000 (UTC)
Received: from mta3.priv.ovhmail-u1.ea.mail.ovh.net (unknown [10.109.249.235])
	by director3.derp.mail-out.ovh.net (Postfix) with ESMTPS id 4cH4cy5vvqz5wDF
	for <[email protected]>; Wed,  3 Sep 2025 14:24:50 +0000 (UTC)
Received: from orca.pet (unknown [10.1.6.5])
	by mta3.priv.ovhmail-u1.ea.mail.ovh.net (Postfix) with ESMTPSA id 8CD2C94334B
	for <[email protected]>; Wed,  3 Sep 2025 14:24:50 +0000 (UTC)
Authentication-Results:garm.ovh; auth=pass (GARM-106R0069670c74c-2a8f-49d9-bf68-2090c4197ada,
                    FA25AB0AA1A9BF3DCBEBCC83EEB30DB7881EF5C4) [email protected]
X-OVh-ClientIp:79.117.41.176
Message-ID: <[email protected]>
Date: Wed, 3 Sep 2025 16:24:50 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: es-ES
To: [email protected]
From: Marcos Del Sol Vives <[email protected]>
Subject: Replace -fcf-protection=full with -fcf-protection=return
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Ovh-Tracer-Id: 5742652475047761424
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: 0
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggdeffeekucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucenucfjughrpefkffggfgfvhffutgfgsehtjeertddtvdejnecuhfhrohhmpeforghrtghoshcuffgvlhcuufholhcugghivhgvshcuoehmrghrtghoshesohhrtggrrdhpvghtqeenucggtffrrghtthgvrhhnpeffvdeljeetffeftdelfeejgfffheefheekjedtgeetjeevledvheeggfeitdetvdenucffohhmrghinhepuggvsghirghnrdhorhhgpdhkvghrnhgvlhdrohhrghenucfkphepuddvjedrtddrtddruddpjeelrdduudejrdeguddrudejieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepihhnvghtpeduvdejrddtrddtrddupdhmrghilhhfrhhomhepmhgrrhgtohhssehorhgtrgdrphgvthdpnhgspghrtghpthhtohepuddprhgtphhtthhopehsuhgsmhhithessghughhsrdguvggsihgrnhdrohhrghdpoffvtefjohhsthepmhhoheeffegmpdhmohguvgepshhmthhpohhuth
DKIM-Signature: a=rsa-sha256; bh=d/PtMMpumSjohwQwXVkZt+M2fmwdhRDQUNvrXTQ7Ns4=;
 c=relaxed/relaxed; d=orca.pet; h=From; s=ovhmo-selector-1; t=1756909491;
 v=1;
 b=UCXDeOT0eEW1rYgMQrQmSSLaMpjSOltZ3zdqfEPGiiHw398HzwWmKBPyzDKEB2LT/vFzobs6
 iCSjh7e63SFLldhUFRy7QiU+4Q0IZwtRGZSUrsN/IlAJsC8EVx7VLfvy/dt2fIvoj6GWPfusxiE
 T1akcoQbxI2egfK35N5t5ic1BRZ9xxjHh/m+m0qBehaJczsRDOxsy9emWIYXc+nw3uQH48uJlEQ
 2TnT3jKfgTpnHQ6iNAjoGGncqoSfWWwnjrpEBDVnxdY/y7ipOR0uNOo4OA4q2DPxwBiNFaorEqK
 YD8r1pnDvTDmqp4d+0lLYuPR9DGisK1SZPJD4S/m72cqg==
X-Greylist: delayed 403 seconds by postgrey-1.37 at buxtehude; Wed, 03 Sep 2025 14:31:39 UTC
Delivered-To: [email protected]

Package: dpkg-dev
Version: 1.22.21
Priority: wishlist
X-Debbugs-Cc: [email protected]

Hello everyone.

I have been instructed by Helmut Grohne from the technical commitee
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1113774#126)
to open a bug here to ask for a change in the current hardening defaults
of Debian for sid and future stable releases.

Currently, on amd64 and i386 as of Trixie, packages are being built by
default with -fcf-protection=full. This results in shadow stacks and IBT
(branch tracking) being enabled on binaries.

The issue is that, right now, user-mode applications running in the Linux
kernel in 64-bit mode only support shadow stacks. IBT protection is only
supported in the kernel, thus compiling user-mode applications with IBT
enabled results simply in an increased code size (due to generated ENDBR
landing instructions), all while offering no security improvements.

This is stated in the kernel documentation
(https://docs.kernel.org/next/x86/shstk.html):

> Today in the 64-bit kernel, only userspace shadow stack and kernel IBT
> are supported.

32-bit applications (either in native 32-bit mode or running under a 64-bit
kernel) do not support neither shadow stacks nor IBT.

I have provided in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1113774#96
a very simple program alongside compilation instructions that proves this
being the case.

By changing the default from -fcf-protection=full to -fcf-protection=return
(which only enables shadow stacks), the users would still experience the
exact same protection as they have right now, while generating smaller
binaries.

------------=_1780833064-1484309-0
Content-Type: message/rfc822
Content-Disposition: inline
Content-Transfer-Encoding: 7bit

Received: (at 1113864-done) by bugs.debian.org; 7 Jun 2026 11:49:02 +0000
X-Spam-Checker-Version: SpamAssassin 4.0.1-bugs.debian.org_2005_01_02
	(2024-03-25) on buxtehude.debian.org
X-Spam-Level: 
X-Spam-Status: No, score=-110.5 required=4.0 tests=ALL_TRUSTED,BAYES_00,
	DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FROMDEVELOPER,
	HAS_BUG_NUMBER,SPF_HELO_NONE,SPF_NONE,USER_IN_DKIM_WELCOMELIST
	autolearn=ham autolearn_force=no
	version=4.0.1-bugs.debian.org_2005_01_02
X-Spam-Bayes: score:0.0000 Tokens: new, 62; hammy, 150; neutral, 141; spammy,
	0. spammytokens: hammytokens:0.000-+--Hx-spam-relays-external:36ff,
	0.000-+--H*r:36ff, 0.000-+--H*RT:sk:master., 0.000-+--H*RT:36ff,
	0.000-+--H*RT:fe40
Return-path: <[email protected]>
Received: from master.debian.org ([2001:41b8:202:deb:216:36ff:fe40:4001]:49960)
	by buxtehude.debian.org with esmtps (TLS1.3:ECDHE_SECP256R1__RSA_PSS_RSAE_SHA256__AES_256_GCM:256)
	(Exim 4.96)
	(envelope-from <[email protected]>)
	id 1wWBzy-006DtY-1h
	for [email protected];
	Sun, 07 Jun 2026 11:49:02 +0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debian.org;
	s=smtpauto.master; h=In-Reply-To:Content-Transfer-Encoding:Content-Type:
	MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To:
	Content-ID:Content-Description;
	bh=w6BPdJ5QwmAp3UcrwTObCqqzo5nNYVO7lIuEWFBZjSg=; b=x4mv82alwabwge3qPvfPw+Tij9
	sfzjbAz9WJ0Hb5x3Vxt0QNgGJZhcn5AlYfMQOYbOZqNc3z2L2jO4Sn2b7A5KyPcQZAeGwBnoc72Ax
	p+Ph0+0pBEG8SMGSXjT0IrT3ktUskKZvi4qkeeYC2faMzHTH9BI9nZG6lgUuaULavd8ha7NuMSZaI
	itMhg6XUSppR2NIKzpkd1vgJe5c7u8nIW1H2m4EqWKUEA9fu0mwgSS03a0SPgnjqNzFpKd2b1GrYG
	NiMKJVOJ1HeQdhHN7aexEA1hFLm4u8t3i+PZwDi9Zt2ARi8g+8dd/C41MPQ5beZ7LFFYnqqF7Gkj5
	aYcdwLCg==;
Received: from guillem by master.debian.org with local (Exim 4.96)
	(envelope-from <[email protected]>)
	id 1wWBzq-00D3Y4-2s;
	Sun, 07 Jun 2026 11:48:54 +0000
Date: Sun, 7 Jun 2026 13:48:53 +0200
From: Guillem Jover <[email protected]>
To: [email protected]
Cc: Marcos Del Sol Vives <[email protected]>
Subject: Re: Bug#1113864: Replace -fcf-protection=full with
 -fcf-protection=return
Message-ID: <[email protected]>
References: <[email protected]>
 <[email protected]>
 <[email protected]>
 <[email protected]>
 <[email protected]>
 <[email protected]>
 <[email protected]>
 <CAMe9rOoV5B3H-3fPFAmZk-Q1-GAL7T4iDrqMMQSGJhTN2J_oNw@mail.gmail.com>
 <[email protected]>
 <[email protected]>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <[email protected]>

Hi!

On Wed, 2025-09-17 at 00:08:12 +0200, Guillem Jover wrote:
> On Tue, 2025-09-16 at 10:20:43 -0700, H.J. Lu wrote:
> > On Tue, Sep 16, 2025 at 9:26 AM Edgecombe, Rick P wrote:
> > > On Tue, 2025-09-16 at 09:50 +0200, Guillem Jover wrote:
> > > > > I'm not aware of any current public activities to enable userspace
> > > > > IBT.  I haven't see any recent attempt to define a userspace/kernel ABI,
> > > > > or to test (and port where necessary) userspace.
> > > >
> > > > Thanks. So, do any of you (Florian, Rick, Yu-cheng, H.J., or perhaps
> > > > other people who have been working on this elsewhere) think we should
> > > > switch to -fcf-protection=return (from -fcf-protection)? Or are there
> > > > plans to add the userland IBT support in Linux in the near future?
> > > > Otherwise it indeed seems like a bit of a waste for now?
> > >
> > > I'd still like to do it, but it's fair to say it's not imminent. This seems
> > > like a reasonable course of action.
> 
> Ah, thanks! It was really not clear whether these efforts had died off,
> or were just on pause. But if there's intention to implement it, even
> if it might take a couple of years, then I think leaving the
> -fct-protection option as is might be fine, as long as the current ABI
> is not going to change (see below).
> 
> > With ENDBR64 in place, dynamic user space binaries will get IBT enhancement
> > automatically via a glibc update when user space IBT is enabled in Linux kernel.
> 
> Right, that was my initial thinking as well [M], but that would depend
> on whether the implementation will still rely on endbr64 being in all
> function prologues or whether it might end up with something like what
> Florian proposed in <https://groups.google.com/g/x86-64-abi/c/iQWEW-iW8DQ>.
> Because at that point we'd need to rebuild everything anyway.
> 
>   [M] <https://lists.debian.org/debian-devel/2025/09/msg00109.html>

So as mentioned on that debian-devel thread, it seems there is still
interest from upstream, and having the instruction in place means we
could just gain full support for it whenever a Linux and glibc grow
support for it. Either completely getting rid of it, or changing the
ABI (as has been proposed in the past), would both require a mass rebuild
at which point I think it makes more sense to leave things as-is for
now and reconsider what to do in the future.

The code in dpkg now also contains a note to that effect to not forget
about this. And meanwhile we fixed the release-notes to avoid stating
incorrect information about the current support.

So with all the above, I'm just going to close this now.

Thanks,
Guillem
------------=_1780833064-1484309-0--