From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id E9BD73858439; Sat, 30 Oct 2021 00:51:29 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E9BD73858439 From: "andrew.cooper3 at citrix dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/102953] Improvements to CET-IBT and ENDBR generation Date: Sat, 30 Oct 2021 00:51:29 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: andrew.cooper3 at citrix dot com X-Bugzilla-Status: WAITING X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: hjl.tools at gmail dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Oct 2021 00:51:30 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102953 --- Comment #20 from Andrew Cooper --- (In reply to H.J. Lu from comment #19) > (In reply to Andrew Cooper from comment #17) > > I think I've found a bug in the -fcf-check-attribute implementation. >=20 > Please try the v5 patch. Thanks. That does fix the issue. > BTW, do you have a testcase to show how > -fcf-check-attribute=3Dyes is used? So, this was something I was going to leave until I'd got CET-IBT working, = so as to have time to consider all parts before proposing improvements. I don't have a usecase for -fcf-check-attribute=3Dyes, because it is almost totally redundant with regular -fcf-protection in the first place. When you are are applying control flow checks, every function is either che= cked or not checked. But GCC currently has a 3-way model of {unknown, explicit = yes, explicit no} on which it builds its typechecking. Furthermore, -mmanual-endbr is a gross hack which by default leaves you wit= h a broken binary. If I were building this from scratch, I'd not have -mmanual-endbr or -fcf-check-attribute at all, because they're exposing complexity which ought not to exist. I get why the default for -fcf-protection=3Dbranch puts an ENDBR* instructi= on everywhere. It is the quick, easy and non-invasive way to make libraries compatible with CET, which is a net improvement, even if not ideal. The ideal way, and definitely future work, is for GCC to calculate the mini= mum set of required ENDBR*. At a guess, all non-local symbols (except those LTO can determine are not publicly visible), and any local symbols used by func= tion pointers. What I'm trying to do is a stopgap in the middle. No ENDBR*'s by default, = but have the compiler tell me where I've got function pointers to a non-ENDBR'd function, so when the result compiles, it stands a reasonable chance of functioning correctly. Personally, I'd suggest having these as sub-modes of -fcf-protection=3Dbran= ch, instead of exposing all the internals on the command line.=