[PATCH 03/12] aarch64: Add BTI landing pads to assembly code

[Szabolcs Nagy]

The 05/07/2020 13:55, Adhemerval Zanella via Libc-alpha wrote:
> On 30/04/2020 14:39, Szabolcs Nagy wrote:
> > From 550fe66ed93e13c0f063955e81bfcb8db386413c Mon Sep 17 00:00:00 2001
> > From: Sudakshina Das <sudi.das@arm.com>
> > Date: Tue, 17 Mar 2020 15:44:18 +0000
> > Subject: [PATCH 03/12] aarch64: Add BTI landing pads to assembly code
> > 
> > Adding the landing pads and the ELF markings are required if
> > glibc is built with branch protection. For the handful of asm
> > files this is done unconditionally, this simplifies maintenance
> > and avoids complications where code layout is carefully aligned
> > such that conditionally turning BTI off may cause performance
> > regression (e.g. string functions).
> 
> I am seeing the warning the cover letter warned on old binutils:
> 
>   unsupported GNU_PROPERTY_TYPE (5) type: 0xc0000000
> 
> In this case, how exactly binutils handles it? Does it still emit
> the expected correct notes, and if so, is the expected layout?

ok, v2 takes care of this (with config checks).

(linkers that don't handle the bti property will either
emit a note that is not valid so ignored at runtime or
not emit any note, so the warnings don't mean broken
behaviour just turned off security feature)

> > +/* Branch Target Identitication support.  */
> > +#define BTI_C		hint	34
> > +#define BTI_J		hint	36
> > +
> > +#define FEATURE_1_BTI 1
> > +#define FEATURE_1_PAC 2
> 
> There are GNU_PROPERTY_AARCH64_FEATURE_1_BTI and GNU_PROPERTY_AARCH64_FEATURE_1_PAC,
> why not use them?

i need definitions suitable for inclusion
into assembly code.
(i shortened the name so it does not go
off the screen, but i can use the same
name as in elf.h if that's less confusing)

> > +#define END_FILE GNU_PROPERTY(FEATURE_1_BTI)
> 
> END_FILE name does not really give much information.  Would be better
> to use ADD_GNU_PROPERTIES or something?

the assumption was that we may need to
add other things to asm files and don't
want to touch all asm files when that
happens, just reuse the END_FILE hook.

on the other hand i'm not sure how much
value this hook adds: i can do what arm
does for attributes: add them in sysdep.h
at the top of asm files that include it.

the sysdep.h solution means less changes
but may be easier to miss when new asm
files are added: we need to ensure that
all newly added asm code is compatible
with the added properties, including asm
like syscall-template.S that is shared
across targets. Explicitly adding END_FILE
implies the person who added it verified
the necessary properties, but it's not a
strong assurance and you could say the
same for adding 'include <sysdep.h>'.