assigned to @DanielKristofKiss

This patch will fix this: https://reviews.llvm.org/D80791

I don't think this is a bug. From the Arm ELF64 ABI(2020Q2) we have first from
section 6.2

"GNU_PROPERTY_AARCH64_FEATURE_1_AND describes a set of processor features with
which an ELF object or executable image is compatible, but does not require
in order to execute correctly."

Certainly an object that contains no code is compatible with the PAC and BTI
features, without requiring them.

"Static linkers processing ELF relocatable objects must set the feature bit
in the output object or image only if all the input objects have the
corresponding feature bit set."

If the compiler didn't set those feature bits in an object file, which did not
contain code, then the linker must clear the feature bit from the final image,
which is clearly unwarranted, as the said object is fully compatible.

Also -mbranch-protection=none does not have the semantics of preventing the object to participate in a PAC/BTI enabled image. Passing the value of none
is equivalent to not passing the option at all.

This behaviour is in spec but from a practical deployment point of view I don't think it's good - at present we have the latest release of at least Debian (which is pretty widely used, especially on arm64) shipping a version of binutils that complains loudly any time it sees one of the notes but there's no way to stop the compiler emitting them. The fact that Debian is affected is especially unfortunate since it's quite commonly used as a basis for Docker containers used in CI systems.

The kernel is passing -mbranch-protection=none for separate reasons, it's doing it because the compiler might not default to none (eg, a distribution trying to get everything built with branch protection) but this can cause issues if the kernel is not expecting it (eg, if we have userspace but not kernel mode PAC any PAC instructions in the kernel will crash).

This behaviour is in spec but from a practical deployment point of view I
don't think it's good - at present we have the latest release of at least
Debian (which is pretty widely used, especially on arm64) shipping a version
of binutils that complains loudly any time it sees one of the notes but
there's no way to stop the compiler emitting them.

Equivalently, there's no way of stopping the linker from emitting the warnings, I presume.

I absolutely agree there is a problem that we need to solve, but so far I'm not convinced that the problem is in the specification or the compiler. It's in the linker.

Equivalently, there's no way of stopping the linker from emitting the warnings, > I presume.

Not that we're aware of.

I absolutely agree there is a problem that we need to solve, but so far I'm not > convinced that the problem is in the specification or the compiler. It's in the > linker.

Or the packaging of the compiler - if we're saying an updated linker is required then distributions of the compiler such as provided by llvm.org really ought to be ensuring that a suitable linker is available. Unfortunately lld still seems to have issues building the kernel and isn't used by default:

$ clang-11 -target aarch64-linux-gnu /tmp/foo.c /tmp/bar.c
/usr/bin/aarch64-linux-gnu-ld: warning: /tmp/bar-20bf33.o: unsupported GNU_PROPERTY_TYPE (5) type: 0xc0000000