> 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
>
>
No comments:
Post a Comment