From: Peter Zijlstra <peterz@infradead.org>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
alyssa.milburn@intel.com, scott.d.constable@intel.com,
joao@overdrivepizza.com, jpoimboe@kernel.org,
jose.marchesi@oracle.com, hjl.tools@gmail.com,
ndesaulniers@google.com, samitolvanen@google.com,
nathan@kernel.org, ojeda@kernel.org, kees@kernel.org,
alexei.starovoitov@gmail.com, mhiramat@kernel.org, jmill@asu.edu
Subject: Re: [PATCH v3 07/10] x86/ibt: Add paranoid FineIBT mode
Date: Wed, 19 Feb 2025 21:07:56 +0100 [thread overview]
Message-ID: <20250219200756.GF23004@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <dc7c570e-153e-4e46-ae40-d1590682d50c@citrix.com>
On Wed, Feb 19, 2025 at 05:31:39PM +0000, Andrew Cooper wrote:
> On 19/02/2025 4:21 pm, Peter Zijlstra wrote:
> > --- a/arch/x86/include/asm/cfi.h
> > +++ b/arch/x86/include/asm/cfi.h
> > @@ -1116,6 +1129,52 @@ extern u8 fineibt_caller_end[];
> >
> > #define fineibt_caller_jmp (fineibt_caller_size - 2)
> >
> > +/*
> > + * Since FineIBT does hash validation on the callee side it is prone to
> > + * circumvention attacks where a 'naked' ENDBR instruction exists that
> > + * is not part of the fineibt_preamble sequence.
> > + *
> > + * Notably the x86 entry points must be ENDBR and equally cannot be
> > + * fineibt_preamble.
> > + *
> > + * The fineibt_paranoid caller sequence adds additional caller side
> > + * hash validation. This stops such circumvetion attacks dead, but at the cost
> > + * of adding a load.
> > + *
> > + * <fineibt_paranoid_start>:
> > + * 0: 41 ba 78 56 34 12 mov $0x12345678, %r10d
> > + * 6: 45 3b 53 f7 cmp -0x9(%r11), %r10d
> > + * a: 4d 8d 5b <f0> lea -0x10(%r11), %r11
> > + * e: 75 fd jne d <fineibt_paranoid_start+0xd>
> > + * 10: 41 ff d3 call *%r11
> > + * 13: 90 nop
> > + *
> > + * Notably LEA does not modify flags and can be reordered with the CMP,
> > + * avoiding a dependency. Again, using a non-taken (backwards) branch
> > + * for the failure case, abusing LEA's immediate 0xf0 as LOCK prefix for the
> > + * JCC.d8, causing #UD.
> > + */
>
> I don't know what to say. This is equal parts horrifying and beautiful.
>
> > +asm( ".pushsection .rodata \n"
> > + "fineibt_paranoid_start: \n"
> > + " movl $0x12345678, %r10d \n"
> > + " cmpl -9(%r11), %r10d \n"
> > + " lea -0x10(%r11), %r11 \n"
> > + " jne fineibt_paranoid_start+0xd \n"
>
> Maybe `jne . - 3` ?
>
> Or perhaps `1: jne 1b - 1` ?
>
> Both seem marginally less fragile than tying the reference to
> fineibt_paranoid_start.
Right, so I initially had '. - 3' (and '. - 7' in
fineibt_preamble_start), but I ended up going with this form because
that's what you end up with if you run it through an assembler and
disassembler.
So I figured this form was easier to compare vs disassembly, which is
what most people will see if they ever look at this.
Anyway, I'm happy to go '. - 3' again if that's preferred.
next prev parent reply other threads:[~2025-02-19 20:08 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-19 16:21 [PATCH v3 00/10] x86/ibt: FineIBT-BHI Peter Zijlstra
2025-02-19 16:21 ` [PATCH v3 01/10] x86/cfi: Add warn option Peter Zijlstra
2025-02-19 17:50 ` Kees Cook
2025-02-19 17:56 ` Peter Zijlstra
2025-02-19 16:21 ` [PATCH v3 02/10] x86/ibt: Add exact_endbr() helper Peter Zijlstra
2025-02-19 17:51 ` Kees Cook
2025-02-19 16:21 ` [PATCH v3 03/10] x86/traps: Decode 0xEA #UD Peter Zijlstra
2025-02-19 16:47 ` Andrew Cooper
2025-02-19 16:49 ` Peter Zijlstra
2025-02-19 17:52 ` Kees Cook
2025-02-19 16:21 ` [PATCH v3 04/10] x86/traps: Allow custom fixups in handle_bug() Peter Zijlstra
2025-02-19 17:55 ` Kees Cook
2025-02-19 18:17 ` Peter Zijlstra
2025-02-19 16:21 ` [PATCH v3 05/10] x86/ibt: Optimize FineIBT sequence Peter Zijlstra
2025-02-19 17:15 ` Andrew Cooper
2025-02-20 18:28 ` Constable, Scott D
2025-02-19 18:01 ` Kees Cook
2025-02-19 18:18 ` Peter Zijlstra
2025-02-19 18:23 ` Kees Cook
2025-02-19 16:21 ` [PATCH v3 06/10] x86/traps: Decode LOCK Jcc.d8 #UD Peter Zijlstra
2025-02-19 16:45 ` Peter Zijlstra
2025-02-19 18:20 ` Kees Cook
2025-02-19 18:33 ` Peter Zijlstra
2025-02-19 19:44 ` Peter Zijlstra
2025-02-19 16:21 ` [PATCH v3 07/10] x86/ibt: Add paranoid FineIBT mode Peter Zijlstra
2025-02-19 17:31 ` Andrew Cooper
2025-02-19 20:07 ` Peter Zijlstra [this message]
2025-02-21 13:40 ` David Laight
2025-02-19 18:05 ` Kees Cook
2025-02-19 16:21 ` [PATCH v3 08/10] x86: BHI stubs Peter Zijlstra
2025-02-19 18:07 ` Kees Cook
2025-02-19 18:07 ` Peter Zijlstra
2025-02-19 16:21 ` [PATCH v3 09/10] x86/ibt: Implement FineIBT-BHI mitigation Peter Zijlstra
2025-02-19 18:11 ` Kees Cook
2025-02-19 16:21 ` [PATCH v3 10/10] x86/ibt: Optimize fineibt-bhi arity 1 case Peter Zijlstra
2025-02-19 18:21 ` Kees Cook
2025-02-19 17:36 ` [PATCH v3 00/10] x86/ibt: FineIBT-BHI Kees Cook
2025-02-20 11:27 ` Peter Zijlstra
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=20250219200756.GF23004@noisy.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=alexei.starovoitov@gmail.com \
--cc=alyssa.milburn@intel.com \
--cc=andrew.cooper3@citrix.com \
--cc=hjl.tools@gmail.com \
--cc=jmill@asu.edu \
--cc=joao@overdrivepizza.com \
--cc=jose.marchesi@oracle.com \
--cc=jpoimboe@kernel.org \
--cc=kees@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=ojeda@kernel.org \
--cc=samitolvanen@google.com \
--cc=scott.d.constable@intel.com \
--cc=x86@kernel.org \
/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