Re: [PATCH v2 07/10] arm64: asm: Provide a mechanism for generating ELF note for BTI

Mark Brown
2020-05-06T12:39:05Z

[-- Attachment #1.1: Type: text/plain, Size: 1607 bytes --]

On Wed, May 06, 2020 at 12:26:33PM +0100, Will Deacon wrote:
> On Tue, May 05, 2020 at 06:06:29PM +0100, Mark Brown wrote:

> > I was unsure about that - it'd be a bit annoying to have to have all the
> > callers of the macro list things like BTI where

> It just feels inevitable that we'll need to do this at some point!
> Do you know what is supposed to happen if an object has multiple instances
> of this property identifying different features? For example, could we
> do something like:

Regardless of what is supposed to happen my strong suspicion is that
we'll have some more.

> If we have to merge this stuff in a single .long, then I think we'll
> probably have to put up with passing in the features as an optional macro
> argument, which defaults to "all features" if it's omitted. So on top of
> your patches, we could do:

> +#define GNU_PROPERTY_AARCH64_FEATURE_1_ALL \
> + (GNU_PROPERTY_AARCH64_FEATURE_1_BTI | \
> + GNU_PROPERTY_AARCH64_FEATURE_1_PAC)
> +
> +.macro emit_aarch64_feature_1_and, feat=GNU_PROPERTY_AARCH64_FEATURE_1_ALL

Right, I was just expecting to have the ifdefs selecting the flags to
emit in the middle of the asm macro definiton rather than separately - I
didn't see a huge win in defining a macro with the only user being
another macro. I can do something along those lines though.

> -.macro emit_aarch64_feature_1_and
> +.macro emit_aarch64_feature_1_and, feat=0
> .endm

That will result in us emitting the note with no flags set which
*should* be totally fine but is a bit unusual and feels like tempting
fate.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]