> Date: Sat, 24 Feb 2024 22:31:43 +0100 > From: Jonathan Schleifer <j...@nil.im> > > Fixed upstream: > https://objfw.nil.im/info/262baf76e7e66bc4 > https://objfw.nil.im/info/d73a388ecaf73b2a > > New release: > https://objfw.nil.im/downloads/objfw-1.0.10.tar.gz > https://objfw.nil.im/downloads/objfw-1.0.10.tar.gz.sig > > Am 24.02.24 um 22:17 schrieb Mark Kettenis: > > > Ah, right. What happens in that case is that the branch will use > > register X16 or X17 and those are special in the sense that both "bti > > c" and "bti j" landing pads are ok. > > Ah. Is that OpenBSD specific or on every OS? I used "bti jc" upstream > now to be on the safe side. I think security-wise it shouldn't make much > of a difference since it's still before the function prologue?
This is how the hardware behaves; see the documentation for PSTATE.BTYPE in Part D of the ARM Architecture Reference Manual (document DDI0487). The difference is that this will allow an attacker to exploit a "BR" type branch (jump) to jump to the start of a function. Not a big risk perhaps but still an uneccesary risk. > > No, functions referenced from .init_array need a landing pad. So the > > init function in src/forwarding/forwarding-arm64-elf.S would indeed > > need a "bti c" at its start. > > That's what I already did upstream, after quickly checking what clang > does :). > > -- > Jonathan >
