Thread (15 messages) 15 messages, 4 authors, 2023-07-11

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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help