From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 8755A3AA8021; Mon, 13 Nov 2023 09:47:40 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8755A3AA8021 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1699868860; bh=4auO1Fm1JIh65aMM+Oa7huvX/GQdiMKxkBouDbXx+zw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=ZhczkSeb+ABTmdeRJGcH0O41WOchl2SHUfqzvXvi9AiV06Tz553ECGaYI+JqDulS7 PICULnDJOpUZJXUrV7lTYPdmJJVKFBn+UxVXi94o3iNt3l6d40Zsjog6ruWKaJ6Q5i t1vO0/gNBV0rrCdmWvSMaGQkCtVjET7NuJFg6iNc= From: "rsandifo at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/112470] [11/12/13/14 regression] [AARCH64] stack-protector vulnerability fixing solution impact code size and performance Date: Mon, 13 Nov 2023 09:47:38 +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: 13.1.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: critical X-Bugzilla-Who: rsandifo at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 11.5 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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D112470 --- Comment #5 from Richard Sandiford --- Could you quantify the performance impact that you're seeing? Figures rela= tive to no protection and to unpatched -fstack-protector-strong would be useful. -fstack-protector-strong adds a large overhead to small functions like this [https://godbolt.org/z/x1v7hvsq1]. And the option explicitly asks for statically sized arrays to be =E2=80=9Cprotected=E2=80=9D. Users who only = want variable-length arrays to be protected would instead use -fstack-protector. So given that the function has the kind of array that the user wants to be protected, it seems safer to provide the same kind of protection as other targets do, in the same way, rather than try to do our own thing. We've already been bitten once by this. For example, on other targets, -fstack-protector-strong effectively protects against underflow as well as overflow, in the sense that underflow can't overwrite the function's saved registers. The proposed patch would change = that for AArch64: writing at negative indices would allow the saved registers to= be overwritten.=