> From: "Theo de Raadt" <[email protected]> > Date: Fri, 21 Apr 2023 07:54:39 -0600 > > +.if ${MACHINE_ARCH:Maarch64} > +CONFIGURE_ENV+= ASMFLAGS=-mmark-bti-property > +.endif > > For some of these diffs, it might help to consider amd64 (and i386?) at > the same time. Or, all architectures. In theory this type of thing will > eventually show up on some other architectures. > > The ELF tag doesn't hurt on a processor family which lacks the lower-level > capability. > > When it comes to the compiler option, it is very unfortunate that arm64 > uses different flags than the other architctures (I say other architectures, > meaning not just amd64 and i386, because based upon reading clang source, > they have written the -fcf-protection argument passing to be applicable to > other architectures as well)
So as far as I can tell, only arm64 has the -mmark-bti-property option. On x86 there is a <cet.h> include file that, when included, emits the "right" .note.gnu.property based on preprocessor macros that get set based on the compiler options. As far as I can tell, this <cet.h> include is an "Intel standard" that exists in all recent versions of clang, gcc and the Intel compiler. The downside of this approach is that it requires modifications to every x86 assembly file. We could extend the <cet.h> trick to arm64, but this would mean more changes to arm64 assembly in ports, and wouldn't be upstreamable. As for the actual code changes to emit BTI/ENDBR32/ENDBR64 instructions. For this port that would probably mean a similar change to the x86-specific M4 macros. Although a patch that I found on their mailing list suggests that that may not be enough as the x86 assembly itself contains some indirect branches: https://gmplib.org/list-archives/gmp-devel/2020-January/005694.html That patch series was not picked up as far as I can tell.
