All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Joao Moreira <joao@overdrivepizza.com>
Cc: Nick Desaulniers <ndesaulniers@google.com>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	hjl.tools@gmail.com, Fangrui Song <maskray@google.com>,
	linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org,
	andrew.cooper3@citrix.com, keescook@chromium.org,
	samitolvanen@google.com, mark.rutland@arm.com,
	alyssa.milburn@linux.intel.com, gabriel.gomes@linux.intel.com,
	rick.p.edgecombe@intel.com
Subject: Re: [RFC PATCH 00/11] Kernel FineIBT Support
Date: Thu, 21 Apr 2022 09:49:20 +0200	[thread overview]
Message-ID: <20220421074920.GK2731@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <bf3273120d8d48a79357f229c5890576@overdrivepizza.com>

On Wed, Apr 20, 2022 at 03:40:41PM -0700, Joao Moreira wrote:
> > > 
> > > If FineIBT needs it, I could reconsider.  But I think there's a strong
> > > case to be made that the linker should be doing that instead.
> > 
> > That sounds reasonable to me (and reminds me of linker relaxation).
> > Joao, can you please work with Fangrui (LLD) and HJ (GNU binutils) to
> > determine how feasible this would be? I assume code outside the kernel
> > might enjoy such an optimization, too.  When that's the case, then it
> > probably makes more sense to "upstream" such "optimizations" from the
> > kernel-specific objtool into the toolchains.
> 
> Alright, these are the greenlights I was hoping for.
> 
> I went quickly into this with HJ and he mentioned that it should be doable
> in the linker, and that he has a patch for it in gcc (for local function,
> from what I could see):
> https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590832.html
> 
> If @Fangrui is fine with it, I would like to try implementing this myself in
> lld (I'm still learning a lot about lld and having an actual problem to
> solve is the kind of fuel I need). Should take me a while, but I think this
> is not urgent, right? I can also go ahead and replicate HJ's gcc patch into
> clang, so we can also handle the local functions within the compiler (I
> think this makes a lot of sense).
> 
> Once we have these in, I'll revisit FineIBT and extend the features to
> handle the FineIBT instrumentation. Hopefully we'll be released from needing
> objtool (famous last words?!).
> 
> This sounds like a plan, but I'm ofc open to suggestions or different
> ideas/plans.

So trivially the plan sounds like: compiler fixes STB_LOCAL because it
has the scope, and the linker fixes everything else. However, that seems
to assume that !STB_LOCAL will have ENDBR.

This latter isn't true; for one there's __attribute__((nocf_check)) that
can be used to suppress ENDBR generation on a function.

Alternatively the linker will need to 'read' the function to determine
if it has ENDBR, or we need to augment the ELF format such that we can
tell from that.

So what exactly is the plan?

  reply	other threads:[~2022-04-21  7:50 UTC|newest]

Thread overview: 44+ 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
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  8:23   ` kernel test robot
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 [this message]
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=20220421074920.GK2731@worktop.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=maskray@google.com \
    --cc=ndesaulniers@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.