Re: [RFC PATCH 2/2] x86/kprobes: Prohibit probing on compiler generated CFI checking code
From: Peter Zijlstra <peterz@infradead.org>
Date: 2023-07-11 07:16:04
Also in:
lkml
On Tue, Jul 11, 2023 at 08:58:37AM +0900, Masami Hiramatsu wrote:
quoted
Hmm, so I was thinking something like the below, which also catches things when we rewrite kCFI to FineIBT, except I don't think we care if the FineIBT callsite gets re-written. FineIBT only relies on the __cfi_ symbol not getting poked at (which the previous patches should ensure).Oh, is FineIBT different from kCFI? I thought those are same. But anyway for kCFI=y && FineIBT=n case, I think this code still needed.
Ah, I forgot to answer your other question; FineIBT is dynamically patched since it relies on optional hardware features, only if the hardware has IBT support can FineIBT work. So yeah, your check is definitely needed. And I think it'll 'gracefully' fail when FineIBT is patched in because the instructions aren't exactly the same. And since FineIBT has most of the magic in the __cfi_ prefix, which isn't patched per the previous patch, I think we're good on the call-site.
quoted
So I tihnk I'm ok with the above, just adding the below for reference (completely untested and everything).I wonder the distance can be used outside of x86. CFI implementation depends on the arch?
Currently only arm64 and x86_64 have CFI, and while the particulars are a little different, they do have a lot in common, including the reporting. IIRC the arm64 variant is a little simpler because of fixed instruction size. There is no worry someone will jump in the middle of an instruction stream.