> Date: Sat, 24 Feb 2024 21:03:34 +0100
> From: Jonathan Schleifer <js@nil.im>

Hi Jonathan,

> 
> Am 24.02.24 um 20:01 schrieb Theo Buehler:
> 
> > This adds missing landing pads for amd64 and arm64. Not sure if for
> > upstream a <cet.h> dance using _CET_ENDBR would be preferable. For the
> > port I kept it simple.
> > 
> > ld: warning: objc_msg_lookup: missing endbr64
> > ld: warning: objc_msg_lookup_stret: missing endbr64
> > ld: warning: objc_msg_lookup_super: missing endbr64
> > ld: warning: objc_msg_lookup_super_stret: missing endbr64
> > ld: warning: OFForward: missing endbr64
> > ld: warning: OFForward_stret: missing endbr64
> 
> Thanks for reporting this! Does this mean all binaries on OpenBSD use 
> CET now?

Unless we explicitly mark them as not, yes, they will use IBT (but not
Shadow Stack).

> > Index: patches/patch-src_forwarding_forwarding-amd64-elf_S
> > ===================================================================
> > RCS file: patches/patch-src_forwarding_forwarding-amd64-elf_S
> > diff -N patches/patch-src_forwarding_forwarding-amd64-elf_S
> > --- /dev/null	1 Jan 1970 00:00:00 -0000
> > +++ patches/patch-src_forwarding_forwarding-amd64-elf_S	24 Feb 2024 18:53:27 -0000
> > @@ -0,0 +1,19 @@
> > +Index: src/forwarding/forwarding-amd64-elf.S
> > +--- src/forwarding/forwarding-amd64-elf.S.orig
> > ++++ src/forwarding/forwarding-amd64-elf.S
> > +@@ -22,6 +22,7 @@
> > +
> > + .section .text
> > + OFForward:
> > ++	endbr64
> > + 	pushq	%rbp
> > + 	movq	%rsp, %rbp
> > +
> > +@@ -107,6 +108,7 @@ OFForward:
> > + .size OFForward, .-OFForward
> > +
> > + OFForward_stret:
> > ++	endbr64
> > + 	pushq	%rbp
> > + 	movq	%rsp, %rbp
> > +
> 
> I'll add something similar upstream, however it won't as simple as here 
> - configure needs to gain a check to see if the assembler supports endbr64.
> 
> > Index: patches/patch-src_forwarding_forwarding-arm64-elf_S
> > ===================================================================
> > RCS file: patches/patch-src_forwarding_forwarding-arm64-elf_S
> > diff -N patches/patch-src_forwarding_forwarding-arm64-elf_S
> > --- /dev/null	1 Jan 1970 00:00:00 -0000
> > +++ patches/patch-src_forwarding_forwarding-arm64-elf_S	24 Feb 2024 18:53:27 -0000
> > @@ -0,0 +1,11 @@
> > +Index: src/forwarding/forwarding-arm64-elf.S
> > +--- src/forwarding/forwarding-arm64-elf.S.orig
> > ++++ src/forwarding/forwarding-arm64-elf.S
> > +@@ -23,6 +23,7 @@
> > + .section .text
> > + OFForward:
> > + OFForward_stret:
> > ++	bti	c
> > + 	stp	fp, lr, [sp, #-208]!
> > + 	mov	fp, sp
> > + 	sub	sp, sp, #208
> 
> I'm not sure if bti c is correct. Shouldn't it rather be bti jc because 
> the compiler could do tail call elimination?

No.  Tail call elimination will use a *direct* branch, which doesn't
need a landing pad at all.

> However, there is more in that file:
> 
> > .Linit:
> >         adrp    x0, .Lmodule
> >         add     x0, x0, :lo12:.Lmodule
> >         b       __objc_exec_class
> 
> Doesn't that mean some flag needs to be added to the compiler as well so 
> that it allows that function to be jumped into, rather than branched to? 
> Because this is just above-mentioned tail call elimination.

Right.  And this is what a direct branch looks like.  An indirect
branch is when you load the address of a function into a register and
then us that register in the branch instruction.

> Also what happens on CPUs that are older than ARMv8.5? Is it the same 
> opcode as something that previously was a nop, like was done on AMD64? 
> Unfortunately I couldn't find anything about that in ARM's 
> documentation. But it seems on my RK3399 it does nothing, which seems to 
> indicate so.

Like endbr64 on amd64, the bti instructions are all executed as nop
instructions on older hardware.

> 
> Unfortunately I don't have any hardware to test this (neither my Ryzen 
> 7940HS seems to have CET nor my RK3399 BTI, and my Mac Mini M1 seems to 
> just miss it with ARMv8.4). Did you try this on real hardware with CET / 
> ARMv8.5?
> 
> I need to look more into CET as well for securing the dispatch tables. 
> If someone has the hardware and would be willing to test patches, that'd 
> be great.
> 
> -- 
> Jonathan
> 
>