From: Peter Zijlstra <peterz@infradead.org>
To: Kees Cook <keescook@chromium.org>
Cc: Peter Collingbourne <pcc@google.com>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Joao Moreira <joao@overdrivepizza.com>,
linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org,
andrew.cooper3@citrix.com, samitolvanen@google.com,
mark.rutland@arm.com, hjl.tools@gmail.com,
alyssa.milburn@linux.intel.com, ndesaulniers@google.com,
gabriel.gomes@linux.intel.com, rick.p.edgecombe@intel.com
Subject: Re: [RFC PATCH 01/11] x86: kernel FineIBT
Date: Mon, 9 May 2022 13:22:00 +0200 [thread overview]
Message-ID: <Ynj5WLYnuWs/3oZW@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <202205080033.82AB3703C3@keescook>
On Sun, May 08, 2022 at 01:29:13AM -0700, Kees Cook wrote:
> On Wed, May 04, 2022 at 08:16:57PM +0200, Peter Zijlstra wrote:
> > FineIBT kCFI
> >
> > __fineibt_\hash:
> > xor \hash, %r10 # 7
> > jz 1f # 2
> > ud2 # 2
> > 1: ret # 1
> > int3 # 1
> >
> >
> > __cfi_\sym: __cfi_\sym:
> > int3; int3 # 2
> > endbr # 4 mov \hash, %eax # 5
> > call __fineibt_\hash # 5 int3; int3 # 2
> > \sym: \sym:
> > ... ...
> >
> >
> > caller: caller:
> > movl \hash, %r10d # 6 cmpl \hash, -6(%r11) # 8
> > sub $9, %r11 # 4 je 1f # 2
> > call *%r11 # 3 ud2 # 2
> > .nop 4 # 4 (or fixup r11) call __x86_indirect_thunk_r11 # 5
>
> This looks good!
>
> And just to double-check my understanding here... \sym is expected to
> start with endbr with IBT + kCFI?
Ah, the thinking was that 'if IBT then FineIBT', so the combination of
kCFI and IBT is of no concern. And since FineIBT will have the ENDBR in
the __cfi_\sym thing, \sym will not need it.
But thinking about this now I suppose __nocfi call symbols will stlil
need the ENDBR on. Objtool IBT validation would need to either find
ENDBR or a matching __cfi_\sym I suppose.
So I was talking to Joao on IRC the other day, and I realized that if
kCFI generates code as per the above, then we can do FineIBT purely
in-kernel. That is; have objtool generate a section of __cfi_\sym
locations. Then use the .retpoline_sites and .cfi_sites to rewrite kCFI
into the FineIBT form in multi pass:
- read all the __cfi_\sym sites and collect all unique hash values
- allocate (module) memory and write __fineibt_\hash functions for each
unique hash value found
- rewrite callers; nop out kCFI
- rewrite all __cfi_\sym
- rewrite all callers
- enable IBT
And the same on module load I suppose.
But I've only thought about this, not actually implemented it, so who
knows what surprises are lurking there :-)
> Random extra thoughts... feel free to ignore. :) Given that both CFI
> schemes depend on an attacker not being able to construct an executable
> memory region that either starts with endbr (for FineIBT) or starts with
> hash & 2 bytes (for kCFI), we should likely take another look at where
> the kernel uses PAGE_KERNEL_EXEC.
>
> It seems non-specialized use is entirely done via module_alloc(). Obviously
> modules need to stay as-is. So we're left with other module_alloc()
> callers: BPF JIT, ftrace, and kprobes.
>
> Perhaps enabling CFI should tie bpf_jit_harden (which performs constant
> blinding) to the value of bpf_jit_enable? (i.e. either use BPF VM which
> reads from non-exec memory, or use BPF JIT with constant blinding.)
>
> I *think* all the kprobes and ftrace stuff ends up using constructed
> direct calls, though, yes? So if we did bounds checking, we could
> "exclude" them as well as the BPF JIT. Though I'm not sure how
> controllable the content written to the kprobes and ftrace regions are,
> though?
Both ftrace and kprobe only write fairly simple tramplines based off of
a template. Neither has indirect calls.
> For exclusion, we could separate actual modules from the other
> module_alloc() users by maybe allocating in opposite directions from the
> randomized offset and check indirect calls against the kernel text bounds
> and the new modules-only bounds. Sounds expensive, though. Maybe PKS,
> but I can't imagine 2 MSR writes per indirect call would be fast. Hmm...
I'm not sure what problem you're trying to solve..
next prev parent reply other threads:[~2022-05-09 11:22 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-20 0:42 [RFC PATCH 00/11] Kernel FineIBT Support joao
2022-04-20 0:42 ` [RFC PATCH 01/11] x86: kernel FineIBT joao
2022-04-29 1:37 ` Josh Poimboeuf
2022-05-02 17:17 ` Joao Moreira
2022-05-03 22:02 ` Josh Poimboeuf
2022-05-04 2:19 ` Joao Moreira
2022-05-04 10:20 ` Peter Zijlstra
2022-05-04 17:04 ` Peter Collingbourne
2022-05-04 18:16 ` Peter Zijlstra
2022-05-05 0:28 ` Sami Tolvanen
2022-05-05 7:36 ` Peter Zijlstra
2022-05-08 8:29 ` Kees Cook
2022-05-09 11:22 ` Peter Zijlstra [this message]
2022-04-20 0:42 ` [RFC PATCH 02/11] kbuild: Support FineIBT build joao
2022-04-20 0:42 ` [RFC PATCH 03/11] objtool: Support FineIBT offset fixes joao
2022-04-20 0:42 ` [RFC PATCH 04/11] x86/module: Support FineIBT in modules joao
2022-04-20 0:42 ` [RFC PATCH 05/11] x86/text-patching: Support FineIBT text-patching joao
2022-04-20 0:42 ` [RFC PATCH 06/11] x86/bpf: Support FineIBT joao
2022-04-20 0:42 ` [RFC PATCH 07/11] x86/lib: Prevent UACCESS call warning from objtool joao
2022-04-20 0:42 ` [RFC PATCH 08/11] x86/ibt: Add CET_TEST module for IBT testing joao
2022-04-20 0:42 ` [RFC PATCH 09/11] x86/FineIBT: Add FINEIBT_TEST module joao
2022-04-20 0:42 ` [RFC PATCH 10/11] linux/interrupt: Fix prototype matching property joao
2022-04-20 2:45 ` Kees Cook
2022-04-20 22:14 ` Joao Moreira
2022-04-20 0:42 ` [RFC PATCH 11/11] driver/int3400_thermal: Fix prototype matching joao
2022-04-20 2:55 ` Kees Cook
2022-04-20 22:28 ` Joao Moreira
2022-04-20 23:04 ` Kees Cook
2022-04-20 23:12 ` Joao Moreira
2022-04-20 23:25 ` Kees Cook
2022-04-21 0:28 ` Joao Moreira
2022-04-20 2:42 ` [RFC PATCH 00/11] Kernel FineIBT Support Kees Cook
2022-04-20 22:50 ` Joao Moreira
2022-04-20 7:40 ` Peter Zijlstra
2022-04-20 15:17 ` Josh Poimboeuf
2022-04-20 17:12 ` Nick Desaulniers
2022-04-20 22:40 ` Joao Moreira
2022-04-21 7:49 ` Peter Zijlstra
2022-04-21 15:23 ` Joao Moreira
2022-04-21 15:35 ` H.J. Lu
2022-04-21 22:11 ` Fangrui Song
2022-04-21 22:26 ` H.J. Lu
2022-04-20 23:34 ` Edgecombe, Rick P
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Ynj5WLYnuWs/3oZW@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=alyssa.milburn@linux.intel.com \
--cc=andrew.cooper3@citrix.com \
--cc=gabriel.gomes@linux.intel.com \
--cc=hjl.tools@gmail.com \
--cc=joao@overdrivepizza.com \
--cc=jpoimboe@redhat.com \
--cc=keescook@chromium.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=ndesaulniers@google.com \
--cc=pcc@google.com \
--cc=rick.p.edgecombe@intel.com \
--cc=samitolvanen@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).