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 <[email protected]> wrote:
On January 1, 2026 2:42:59 PM PST, Andrew Pinski
<[email protected]> wrote:
On Tue, Dec 9, 2025 at 6:22 PM Kees Cook <[email protected]> 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/[email protected]/),
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
