linux-hardening - Re: [PATCH v3 2/7] kcfi: Add core Kernel Control Flow Integrity infrastructure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <202509181229.FF689207B@keescook>
Date: Thu, 18 Sep 2025 12:39:25 -0700
From: Kees Cook <kees@...nel.org>
To: Qing Zhao <qing.zhao@...cle.com>
Cc: Andrew Pinski <pinskia@...il.com>, Jakub Jelinek <jakub@...hat.com>,
	Martin Uecker <uecker@...raz.at>,
	Richard Biener <rguenther@...e.de>,
	Joseph Myers <josmyers@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>, Jan Hubicka <hubicka@....cz>,
	Richard Earnshaw <richard.earnshaw@....com>,
	Richard Sandiford <richard.sandiford@....com>,
	Marcus Shawcroft <marcus.shawcroft@....com>,
	Kyrylo Tkachov <kyrylo.tkachov@....com>,
	Kito Cheng <kito.cheng@...il.com>,
	Palmer Dabbelt <palmer@...belt.com>,
	Andrew Waterman <andrew@...ive.com>,
	Jim Wilson <jim.wilson.gcc@...il.com>,
	Dan Li <ashimida.1990@...il.com>,
	Sami Tolvanen <samitolvanen@...gle.com>,
	Ramon de C Valle <rcvalle@...gle.com>,
	Joao Moreira <joao@...rdrivepizza.com>,
	Nathan Chancellor <nathan@...nel.org>,
	Bill Wendling <morbo@...gle.com>,
	"gcc-patches@....gnu.org" <gcc-patches@....gnu.org>,
	"linux-hardening@...r.kernel.org" <linux-hardening@...r.kernel.org>
Subject: Re: [PATCH v3 2/7] kcfi: Add core Kernel Control Flow Integrity
 infrastructure

On Wed, Sep 17, 2025 at 02:09:54PM -0700, Kees Cook wrote:
> On Wed, Sep 17, 2025 at 01:42:32PM +0000, Qing Zhao wrote:
> > > On Sep 13, 2025, at 19:23, Kees Cook <kees@...nel.org> wrote:
> > > +- Keep indirect calls from being merged (see earlier example) by
> > > +  checking the KCFI insn's typeid for equality.
> > 
> > Is this resolved by the following code:
> > 
> > rtlanal.cc
> > index 63a1d08c46cf..5016fe93ccac 100644
> > --- a/gcc/rtlanal.cc
> > +++ b/gcc/rtlanal.cc
> > @@ -1177,6 +1177,11 @@ reg_referenced_p (const_rtx x, const_rtx body)
> >     case IF_THEN_ELSE:
> >       return reg_overlap_mentioned_p (x, body);
> > 
> > +    case KCFI:
> > +      /* For KCFI wrapper, check both the wrapped call and the type ID.  */
> > +      return (reg_overlap_mentioned_p (x, XEXP (body, 0))
> > +      || reg_overlap_mentioned_p (x, XEXP (body, 1)));
> > +
> 
> The above is needed for accurate register "liveness" checking. When the
> above code is removed, the kcfi-move-preservation.c regression test
> fails (since it doesn't see the clobbers).
> 
> AFAICT, simply making it a new type of RTL (the DEF_RTL_EXPR), made it
> unmergeable. I assume this is because whatever was doing the call
> merging was looking strictly for "CALL" types, but I honestly don't know
> where that was happening.

Okay, I've found this. The pass that merged the regression test's calls
is jump2. Specifically, the jump2 pass calls old_insns_match_p() which
compares instruction patterns using rtx_equal_p(), and that is doing it
naturally based on the RTL expression, i.e. matching RTL codes for KCFI,
and then matching format (KCFI defines itself as "ee" format, i.e. 2
expressions):

  code = GET_CODE (x);
  /* Rtx's of different codes cannot be equal.  */
  if (code != GET_CODE (y))
    return false;
...
  fmt = GET_RTX_FORMAT (code);
  for (i = GET_RTX_LENGTH (code) - 1; i >= 0; i--)
    {
      switch (fmt[i])
        {
...
        case 'e':
          if (!rtx_equal_p (XEXP (x, i), XEXP (y, i), cb))
            return false;
          break;

So if it's the same call and the same typeid, it'll get merged, otherwise
it won't. And I've validated this now with an addition to the regression
test. It now makes 3 calls, once with typeid A, and then 2 calls with
typeid B, and the typeid B calls get merged.

So there was no special handling for CALL, it's just that CALL didn't have
the typeid associated with it, and KCFI does. RTL working as intended. ;)

(But my new mystery is why my new KCFI matching typeid merging happens
on all backend _except_ arm... I will investigate that.)

-Kees

-- 
Kees Cook