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?

> 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?

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.

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.

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