> On Sep 18, 2025, at 15:39, Kees Cook <[email protected]> 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 <[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. ;)
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
