From: Richard Earnshaw <Richard.Earnshaw@foss.arm.com>
To: Tejas Belagod <Tejas.Belagod@arm.com>,
Richard Earnshaw <Richard.Earnshaw@arm.com>,
"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: Re: [Patch 3/8, Arm, GCC] Add option -mbranch-protection. [Was RE: [Patch 2/7, Arm, GCC] Add option -mbranch-protection.]
Date: Fri, 3 Dec 2021 15:55:06 +0000 [thread overview]
Message-ID: <1dd1310a-5a30-7631-2261-f9721b38a22e@foss.arm.com> (raw)
In-Reply-To: <PAXPR08MB7075770D11A8F2AAB4CE9F1EEA869@PAXPR08MB7075.eurprd08.prod.outlook.com>
On 28/10/2021 12:42, Tejas Belagod via Gcc-patches wrote:
>
>
>> -----Original Message-----
>> From: Richard Earnshaw <Richard.Earnshaw@arm.com>
>> Sent: Monday, October 11, 2021 1:58 PM
>> To: Tejas Belagod <Tejas.Belagod@arm.com>; gcc-patches@gcc.gnu.org
>> Subject: Re: [Patch 2/7, Arm, GCC] Add option -mbranch-protection.
>>
>> On 08/10/2021 13:17, Tejas Belagod via Gcc-patches wrote:
>>> Hi,
>>>
>>> Add -mbranch-protection option and its associated parsing routines.
>>> This option enables the code-generation of pointer signing and
>>> authentication instructions in function prologues and epilogues.
>>>
>>> Tested on arm-none-eabi. OK for trunk?
>>>
>>> 2021-10-04 Tejas Belagod <tbelagod@arm.com>
>>>
>>> gcc/ChangeLog:
>>>
>>> * common/config/arm/arm-common.c
>>> (arm_print_hit_for_pacbti_option): New.
>>> (arm_progress_next_token): New.
>>> (arm_parse_pac_ret_clause): New routine for parsing the
>>> pac-ret clause for -mbranch-protection.
>>> (arm_parse_pacbti_option): New routine to parse all the options
>>> to -mbranch-protection.
>>> * config/arm/arm-protos.h (arm_parse_pacbti_option): Export.
>>> * config/arm/arm.c (arm_configure)build_target): Handle option
>>> to -mbranch-protection.
>>> * config/arm/arm.opt (mbranch-protection). New.
>>> (arm_enable_pacbti): New.
>>>
>>
>> You're missing documentation for invoke.texi.
>>
>> Also, how does this differ from the exising option in aarch64? Can the code
>> from that be adapted to be made common to both targets rather than doing
>> a new implementation?
>>
>> Finally, there are far to many manifest constants in this patch, they need
>> replacing with enums or #defines as appropriate if we cannot share the
>> aarch64 code.
>
> Thanks for the reviews.
>
> Add -mbranch-protection option. This option enables the code-generation of
> pointer signing and authentication instructions in function prologues and
> epilogues.
>
> 2021-10-25 Tejas Belagod <tbelagod@arm.com>
>
> gcc/ChangeLog:
>
> * config/arm/arm.c (arm_configure_build_target): Parse and validate
> -mbranch-protection option and initialize appropriate data structures.
> * config/arm/arm.opt: New option -mbranch-protection.
.../arm.opt (-mbranch-protection) : New option.
> * doc/invoke.texi: Document -mbranch-protection.
.../invoke.texi (Arm Options): Document it.
>
> Tested the following configurations, OK for trunk?
>
> -mthumb/-march=armv8.1-m.main+pacbti/-mfloat-abi=soft
> -marm/-march=armv7-a/-mfpu=vfpv3-d16/-mfloat-abi=softfp
> mcmodel=small and tiny
> aarch64-none-linux-gnu native test and bootstrap
>
+@item
-mbranch-protection=@var{none}|@var{standard}|@var{pac-ret}[+@var{leaf}][+@var{bti}]|@var{bti}[+@var{pac-ret}[+@var{leaf}]]
+@opindex mbranch-protection
+Select the branch protection features to use.
+@samp{none} is the default and turns off all types of branch protection.
+@samp{standard} turns on all types of branch protection features. If a
feature
+has additional tuning options, then @samp{standard} sets it to its standard
+level.
+@samp{pac-ret[+@var{leaf}]} turns on return address signing to its standard
+level: signing functions that save the return address to memory (non-leaf
+functions will practically always do this). The optional argument
@samp{leaf}
+can be used to extend the signing to include leaf functions.
+@samp{bti} turns on branch target identification mechanism.
This doesn't really use the right documentation style. Closer would be:
===============
@item
-mbranch-protection=@var{none}|@var{standard}|@var{pac-ret}[+@var{leaf}][+@var{bti}]|@var{bti}[+@var{pac-ret}[+@var{leaf}]]
@opindex mbranch-protection
Enable branch protection features (armv8.1-m.main only).
@samp{none} generate code without branch protection or return address
signing.
@samp{standard[+@var{leaf}]} generate code with all branch protection
features enabled at their standard level.
@samp{pac-ret[+@var{leaf}]} generate code with return address signing
set to its standard level, which is to sign all functions that save the
return address to memory.
@samp{leaf} When return address signing is enabled, also sign leaf
functions even if they do not write the return address to memory.
+@samp{bti} Add landing-pad instructions at the permitted targets of
indirect branch instructions.
If the @samp{+pacbti} architecture extension is not enabled, then all
branch protection and return address signing operations are constrained
to use only the instructions defined in the architectural-NOP space.
The generated code will remain backwards-compatible with earlier
versions of the architecture, but the additional security can be enabled
at run time on processors that support the @samp{PACBTI} extension.
Branch target enforcement using BTI can only be enabled at runtime if
all code in the application has been compiled with at least
@samp{-mbranch-protection=bti}.
The default is to generate code without branch protection or return
address signing.
================
R.
next prev parent reply other threads:[~2021-12-03 15:55 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-28 11:42 Tejas Belagod
2021-12-03 15:55 ` Richard Earnshaw [this message]
2021-12-06 14:47 ` Andrea Corallo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1dd1310a-5a30-7631-2261-f9721b38a22e@foss.arm.com \
--to=richard.earnshaw@foss.arm.com \
--cc=Richard.Earnshaw@arm.com \
--cc=Tejas.Belagod@arm.com \
--cc=gcc-patches@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).