All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: David Laight <david.laight.linux@gmail.com>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org, hpa@zystor.com,
	samitolvanen@google.com, kees@kernel.org, nathan@kernel.org,
	scott.d.constable@intel.com
Subject: Re: [PATCH] x86/kcfi: Optimize call sequence
Date: Wed, 17 Jun 2026 09:08:13 +0200	[thread overview]
Message-ID: <20260617070813.GI49951@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20260616214722.7742e394@pumpkin>

On Tue, Jun 16, 2026 at 09:47:22PM +0100, David Laight wrote:

> > --- a/arch/x86/kernel/alternative.c
> > +++ b/arch/x86/kernel/alternative.c
> > @@ -1356,6 +1356,10 @@ early_param("cfi", cfi_parse_cmdline);
> >   *  "Make conditional jumps most often not taken: The efficiency and throughput
> >   *   for not-taken branches is better than for taken branches on most
> >   *   processors. Therefore, it is good to place the most frequent branch first"
> > + *
> > + * NOTE: Update the kCFI caller sequence to make use of this observation.
> > + * Replace the "je 1f; ud2" sequence with "jne +1; test $0xd6, %al". This
> > + * clobbers flags, but those are clobbered by the hash test anyway.
> 
> I think it would be better to give the byte sequences for both pairs of
> instructions - it takes a bit of sleuthing to check they are the same size.

You mean, expand the comment like a few lines above, where we have the
kCFI/FineIBT contrast? Sure, I suppose I can make this comment longer
still.

> I think it would also be better it the code doing the patching checked
> what it was overwriting.

Ye of little faith :-)

> Also, what actually generates the list of cfi locations in the first place?
> If it is objtool, then maybe it could do the rewrite instead.

The list with UD2 locations is compiler generated. Also, objtool
typically avoids actually modifying code and generally prefers to just
ship additional sections such that the kernel can modify itself. There
is an exception to this, but there was definite grumbling about that.



  reply	other threads:[~2026-06-17  7:08 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-12  7:15 [PATCH] x86/kcfi: Optimize call sequence Peter Zijlstra
2026-06-16 18:55 ` Borislav Petkov
2026-06-16 20:47 ` David Laight
2026-06-17  7:08   ` Peter Zijlstra [this message]
2026-06-17  9:26     ` David Laight
2026-06-17 11:12       ` Peter Zijlstra
2026-06-17 12:36         ` David Laight
2026-06-17 12:47           ` 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=20260617070813.GI49951@noisy.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=david.laight.linux@gmail.com \
    --cc=hpa@zystor.com \
    --cc=kees@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nathan@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 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.