> Date: Sat, 24 Feb 2024 22:31:43 +0100
> From: Jonathan Schleifer <js@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
>
No comments:
Post a Comment