Message-ID: <e25bee08-908c-402e-bd5d-9723073f0a37@gmail.com>
Date: Fri, 9 Jan 2026 11:43:05 -0700
From: Jeffrey Law <jeffreyalaw@...il.com>
To: Kees Cook <kees@...nel.org>,
 Andrew Pinski <andrew.pinski@....qualcomm.com>
Cc: Qing Zhao <qing.zhao@...cle.com>, Uros Bizjak <ubizjak@...il.com>,
 Joseph Myers <josmyers@...hat.com>, Richard Biener <rguenther@...e.de>,
 Andrew Pinski <pinskia@...il.com>, Jakub Jelinek <jakub@...hat.com>,
 Martin Uecker <uecker@...raz.at>, Peter Zijlstra <peterz@...radead.org>,
 Ard Biesheuvel <ardb@...nel.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>,
 "Osterlund, Sebastian" <sebastian.osterlund@...el.com>,
 "Constable, Scott D" <scott.d.constable@...el.com>, gcc-patches@....gnu.org,
 linux-hardening@...r.kernel.org
Subject: Re: [PATCH v9 0/7] Introduce Kernel Control Flow Integrity ABI
 [PR107048]



On 1/9/2026 11:22 AM, Kees Cook wrote:
> On Thu, Jan 08, 2026 at 09:48:58PM -0800, Andrew Pinski wrote:
>> On Thu, Jan 1, 2026 at 7:42 PM Kees Cook <kees@...nel.org> wrote:
>>>
>>>
>>> On January 1, 2026 2:42:59 PM PST, Andrew Pinski <andrew.pinski@....qualcomm.com> wrote:
>>>> On Tue, Dec 9, 2025 at 6:22 PM Kees Cook <kees@...nel.org> wrote:
>>>>> Hi,
>>>>>
>>>>> This series implements[1][2] the Linux Kernel Control Flow Integrity
>>>>> ABI, which provides a function prototype based forward edge control flow
>>>>> integrity protection by instrumenting every indirect call to check for
>>>>> a hash value before the target function address. If the hash at the call
>>>>> site and the hash at the target do not match, execution will trap.
>>>>>
>>>>> I'm hoping we can land front- and middle-end and do architectures as
>>>>> they also pass review. What do folks think? I'd really like to get this
>>>>> in a position where more people can test with GCC snapshots, etc.
>>>> So looking back into the other implementation that was submitted a few
>>>> years back (https://patchwork.sourceware.org/project/gcc/patch/20230325081117.93245-3-ashimida.1990@gmail.com/),
>>>> a regnote (REG_CALL_CFI_TYPEID) was used instead of the wrapping with
>>>> kfci rtl.
>>>> I get the feeling a regnote would be better as there is less for the
>>>> backend to deal with including new patterns.
>>>> What do others think?
>>> I started there and it created way too many problems that I had to continuously hack around. Switching to RTL solved all of it. (See v1 and v2 of this series where that was how it was implemented.)
>> Ok, thanks for confirming that. I will try to give v10 a full review
>> by the end of next week. But since GCC is starting stage 4 on Monday
>> and I think it is too late to add this feature so this might be the
>> first thing to be pushed once GCC 17 stage 1 starts (mid to late March
>> depending on how fast regressions are fixed).
> Thanks! Yeah, I'm not expecting to land this in GCC 16. We're very late
> in the cycle. :)
Good, I'd already mentally pushed it to gcc-17, but hadn't explicitly 
mentioned it outside the RISC-V patchwork call..  While I would have 
loved to have user and kernel CFI lit up for gcc-16, as you note, it's 
very late in the gcc-16 cycle.  Good to see we're in alignment on the 
schedule.

Jeff

Powered by blists - more mailing lists