From: Peter Zijlstra <peterz@infradead.org>
To: Sami Tolvanen <samitolvanen@google.com>
Cc: Joao Moreira <joao@overdrivepizza.com>,
Kees Cook <keescook@chromium.org>, X86 ML <x86@kernel.org>,
hjl.tools@gmail.com, Josh Poimboeuf <jpoimboe@redhat.com>,
andrew.cooper3@citrix.com, LKML <linux-kernel@vger.kernel.org>,
Nick Desaulniers <ndesaulniers@google.com>,
llvm@lists.linux.dev
Subject: Re: [RFC][PATCH 6/6] objtool: Add IBT validation / fixups
Date: Tue, 15 Feb 2022 21:53:49 +0100 [thread overview]
Message-ID: <20220215205349.GC23216@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <CABCJKuf-wouSCh4u43GPQHPPgG=mqOGboSoHPQRfmgQSBkFrMg@mail.gmail.com>
On Tue, Feb 15, 2022 at 08:56:03AM -0800, Sami Tolvanen wrote:
> On Mon, Feb 14, 2022 at 2:25 PM Peter Zijlstra <peterz@infradead.org> wrote:
> > On Mon, Feb 14, 2022 at 01:38:18PM -0800, Sami Tolvanen wrote:
> > > I'm fine with adding a trap mode that's used by default, but having
> > > more helpful diagnostics when something fails is useful even in
> > > production systems in my experience. This change results in a vmlinux
> > > that's another 0.92% smaller.
> >
> > You can easily have the exception generate a nice warning, you can even
> > have it continue. You really don't need a call for that.
>
> Sure, but wouldn't that require us to generate something like
> __bug_table, so we know where the CFI specific traps are?
Yes, but since you're going to emit a retpoline, and objtool already
generates a list of retpoline sites, we can abuse that. If the
instruction after the trap is a retpoline site, we a CFI fail.
> > > In this case the function has two indirect calls and Clang seems to
> > > prefer to emit just one ud2.
> >
> > That will not allow you to recover from the exception. UD2 is not an
> > unconditional fail. It should have an out-going edge in this case too.
>
> Yes, CFI failures are not recoverable in that code. In fact, LLVM
> assumes that the llvm.trap intrinsic (i.e. ud2) never returns, but I
> suppose we could just use an int3 instead. I assume that's sufficient
> to stop speculation?
It is. int3 is also smaller by one byte, but the exception is already
fairly complicated, but I can see if we can make it work.
> > Also, you really should add a CS prefix to the retpoline thunk call if
> > you insist on using r11 (or any of the higher regs).
>
> I actually didn't touch the retpoline thunk call, that's exactly the
> code Clang normally generates.
Yeah, and it needs help, also see:
https://lore.kernel.org/lkml/20211119165630.276205624@infradead.org/
Specifically, clang needs to:
- CS prefix stuff the retpoline thunk call/jmp;
- stop doing conditional indirect tail-calls.
next prev parent reply other threads:[~2022-02-15 20:54 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-22 17:03 [RFC][PATCH 0/6] x86: Kernel IBT beginnings Peter Zijlstra
2021-11-22 17:03 ` [RFC][PATCH 1/6] x86: Annotate _THIS_IP_ Peter Zijlstra
2021-11-23 13:53 ` Mark Rutland
2021-11-23 14:14 ` Peter Zijlstra
2021-11-24 18:18 ` Josh Poimboeuf
2021-11-22 17:03 ` [RFC][PATCH 2/6] x86: Base IBT bits Peter Zijlstra
2022-02-08 23:32 ` Kees Cook
2021-11-22 17:03 ` [RFC][PATCH 3/6] x86: Add ENDBR to IRET-to-Self Peter Zijlstra
2021-11-22 18:09 ` Peter Zijlstra
2022-02-08 23:33 ` Kees Cook
2021-11-22 17:03 ` [RFC][PATCH 4/6] objtool: Read the _THIS_IP_ hints Peter Zijlstra
2021-11-22 17:03 ` [RFC][PATCH 5/6] x86: Sprinkle ENDBR dust Peter Zijlstra
2021-11-23 14:00 ` Mark Rutland
2021-11-23 14:21 ` Peter Zijlstra
2022-02-08 23:38 ` Kees Cook
2021-11-22 17:03 ` [RFC][PATCH 6/6] objtool: Add IBT validation / fixups Peter Zijlstra
2021-11-24 19:30 ` Josh Poimboeuf
2022-02-08 23:43 ` Kees Cook
2022-02-09 5:09 ` Josh Poimboeuf
2022-02-09 11:41 ` Peter Zijlstra
2022-02-09 11:45 ` Peter Zijlstra
2021-12-24 2:05 ` joao
2022-02-08 23:42 ` Kees Cook
2022-02-09 2:21 ` Joao Moreira
2022-02-09 4:05 ` Kees Cook
2022-02-09 5:18 ` Joao Moreira
2022-02-11 13:38 ` Peter Zijlstra
2022-02-14 21:38 ` Sami Tolvanen
2022-02-14 22:25 ` Peter Zijlstra
2022-02-15 16:56 ` Sami Tolvanen
2022-02-15 20:03 ` Kees Cook
2022-02-15 21:05 ` Peter Zijlstra
2022-02-15 23:05 ` Kees Cook
2022-02-15 23:38 ` Joao Moreira
2022-02-16 12:24 ` Peter Zijlstra
2022-02-15 20:53 ` Peter Zijlstra [this message]
2022-02-15 22:45 ` Joao Moreira
2022-02-16 0:57 ` Andrew Cooper
2022-03-02 3:06 ` Peter Collingbourne
2022-03-02 3:32 ` Joao Moreira
2022-06-08 17:53 ` Fāng-ruì Sòng
2022-06-09 0:05 ` Sami Tolvanen
2021-11-23 7:58 ` [RFC][PATCH 0/6] x86: Kernel IBT beginnings Christoph Hellwig
2021-11-23 9:02 ` Peter Zijlstra
2022-02-08 23:48 ` Kees Cook
2022-02-09 0:09 ` Nick Desaulniers
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=20220215205349.GC23216@worktop.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=andrew.cooper3@citrix.com \
--cc=hjl.tools@gmail.com \
--cc=joao@overdrivepizza.com \
--cc=jpoimboe@redhat.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=ndesaulniers@google.com \
--cc=samitolvanen@google.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;
as well as URLs for NNTP newsgroup(s).