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 <[email protected]> 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