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] [day] [month] [year] [list]

Message-ID: <BC4A7BFB-6EF1-40D5-93DC-0322084F4D31@oracle.com>
Date: Thu, 18 Sep 2025 20:14:20 +0000
From: Qing Zhao <qing.zhao@...cle.com>
To: Kees Cook <kees@...nel.org>
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 Sep 18, 2025, at 15:39, Kees Cook <kees@...nel.org> wrote:
> 
> 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. ;)

Yeah, this sounds very natural and reasonable now. Nice!
> 
> (But my new mystery is why my new KCFI matching typeid merging happens
> on all backend _except_ arm... I will investigate that.)

Have fun. -:)

Qing
> 
> -Kees
> 
> -- 
> Kees Cook