[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALvbMcCi8SZs415AE8WYFiijh6K0HYixqz68Nbios=BvuB_jsg@mail.gmail.com>
Date: Thu, 8 Jan 2026 21:48:58 -0800
From: Andrew Pinski <andrew.pinski@....qualcomm.com>
To: Kees Cook <kees@...nel.org>
Cc: Qing Zhao <qing.zhao@...cle.com>, Uros Bizjak <ubizjak@...il.com>,
Joseph Myers <josmyers@...hat.com>, Richard Biener <rguenther@...e.de>,
Jeff Law <jeffreyalaw@...il.com>, 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 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,
Andrew
>
> -Kees
>
>
> --
> Kees Cook
Powered by blists - more mailing lists