public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
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.

  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).