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
