Re: [PATCH] powerpc/kasan: require memintrinsic prefix support for KASAN

["Christophe Leroy (CS GROUP)" <chleroy@kernel.org>]

Le 12/09/2026 à 19:35, Christophe Leroy (CS GROUP) a écrit :
> Hi Mukesh,
> 
> Le 11/09/2026 à 19:39, Mukesh Kumar Chaurasiya a écrit :
>>
>> [...]
>>>> diff --git a/arch/powerpc/kernel/cputable.c b/arch/powerpc/kernel/ 
>>>> cputable.c
>>>> index 6f6801da9dc1..44115f904c2c 100644
>>>> --- a/arch/powerpc/kernel/cputable.c
>>>> +++ b/arch/powerpc/kernel/cputable.c
>>>> @@ -36,8 +36,8 @@ void __init set_cur_cpu_spec(struct cpu_spec *s)
>>>>        t = PTRRELOC(t);
>>>>        /*
>>>> -     * use memcpy() instead of *t = *s so that GCC replaces it
>>>> -     * by __memcpy() when KASAN is active
>>>> +     * use memcpy() instead of *t = *s so that the compiler 
>>>> replaces it
>>>> +     * by __asan_memcpy() when KASAN is active
>>>>         */
>>>
>>> Does the initial problem still exist with the new __asan_memcpy() 
>>> approach ?
>>> If not the comment should be removed.
>>>
>> Hey Christophe,
>>
>> Thanks for pointing it out, i took a deeper look into this, here's my
>> understanding on it.
>>
>> On PowerPC during very early boot the kernel is loaded by the
>> bootloader/firmware at some physical address, but the kernel was linked
>> expecting it to run at KERNELBASE(virtual address like
>> 0xc000000000000000). The MMU mapping that makes that virtual address
>> valid hasn't been set up yet. So far for a window of early boot, code is
>> executing at the physical load address while all symbol addresses in the
>> binary refer to the virtual linked address. reloc_offset() computes the
>> gap between these two and PTRRELOC applies it to any pointer.
>>
>> So PTRRELOC(&the_cpu_spec) gives the physical address where the struct
>> actually lives in memory right now, not where the linker thinks it lives.
>>
>> Why *t = *s would be wrong?
>>
>> In set_cur_cpu_spec:
>>
>> struct cpu_spec *t = &the_cpu_spec;  // linked (virtual) address
>> t = PTRRELOC(t);                     // physical address — where it 
>> actually is
>> memcpy(t, s, sizeof(*t));            // copy into the right place
>>
>> If you wrote *t = *s instead, the compiler generates a struct assignment.
>> For a large struct like cpu_spec, GCC is free to implement that however
>> it likes — including emitting a call to memcpy(). But crucially, a
>> compiler-generated memcpy call resolves through the GOT/PLT or direct
>> symbol — which points to the linked virtual address of memcpy, not the
>> physical address. At this point in boot, calling through the wrong
>> address would jump to garbage or an unmapped page.
>>
>> memcpy(t, s, sizeof(*t)) written explicitly is different: t is already
>> the corrected physical address, s points into the cpu_specs table which
>> has also been PTRRELOC'd. The explicit call goes through the normal
>> early-boot call mechanism which is safe.
>>
>> The original comment said:
>>
>> "use memcpy() instead of *t = *s so that GCC replaces it by __memcpy()
>> when KASAN is active"
>>
>> This was added because under the old KASAN scheme
>> (!CC_HAS_KASAN_MEMINTRINSIC_PREFIX), KASAN overrode the memset/memcpy
>> linker symbols globally with C wrappers that called kasan_check_range().
>> If the compiler turned *t = *s into an implicit memcpy(), that would hit
>> the KASAN wrapper — calling kasan_check_range() at a point in early boot
>> where the KASAN shadow isn't mapped yet, causing a crash.
>>
>> Writing memcpy(t, s, sizeof(*t)) explicitly made GCC emit __memcpy()
>> (the raw assembly alias exposed by _GLOBAL_KASAN) instead of the
>> KASAN-wrapped memcpy(), bypassing the shadow check.
>>
>> That was the secondary reason. The primary reason that t is a
>> PTRRELOC-adjusted physical pointer and the copy must go through it
>> correctly was never stated.
>>
>> So the KASAN comment is not required but i think we still need to state
>> why memcpy is required. For PTRRELOC adjustment, comment should reflect
>> that.
>>
>> I'll update the comment and commit message and send out a new version.
> 
> Explanation based on kernel v5.10
> 
> The problem was not linked to PTRRELOC, the t = PTRRELOC(t) followed by 
> *t = *s works well in term of adressing, regardless of whether 
> CONFIG_KASAN is enabled or not.
> 
> The problem is that with *t = *s, gcc emits a call to memcpy(). When 
> CONFIG_KASAN is enabled, memcpy() is instrumented. But we don't want 
> cputable.o instrumented as we have KASAN_SANITIZE_cputable.o := n in 
> Makefile.
> 
> In asm/string.h we have:
> 
> #if defined(CONFIG_KASAN) && !defined(__SANITIZE_ADDRESS__)
> /*
>   * For files that are not instrumented (e.g. mm/slub.c) we
>   * should use not instrumented version of mem* functions.
>   */
> #define memcpy(dst, src, len) __memcpy(dst, src, len)
> #define memmove(dst, src, len) __memmove(dst, src, len)
> #define memset(s, c, n) __memset(s, c, n)
> 
> Because in non-instrumented files like cputable.o we want memcpy() to be 
> replaced at buildtime by __memcpy() to skip KASAN instrumentation. But 
> this is resolved by pre-processing, and pre-processor doesn't know that 
> the compiler will emit a call to memcpy().
> 
> By replacing *t = *s by the memcpy(), the pre-processor replaces 
> memcpy() by __memcpy() when CONFIG_KASAN is enabled.
> 
> See the difference:
> 
> This is v5.10
> 
> 00000000 <set_cur_cpu_spec>:
>     0:    94 21 ff e0     stwu    r1,-32(r1)
>     4:    7c 69 1b 78     mr      r9,r3
>     8:    bf c1 00 18     stmw    r30,24(r1)
>     c:    3f e0 00 00     lis     r31,0
>              e: R_PPC_ADDR16_HA    .data..read_mostly
>    10:    3b ff 00 00     addi    r31,r31,0
>              12: R_PPC_ADDR16_LO    .data..read_mostly
>    14:    7c 08 02 a6     mflr    r0
>    18:    7d 3e 4b 78     mr      r30,r9
>    1c:    7f e3 fb 78     mr      r3,r31
>    20:    90 01 00 24     stw     r0,36(r1)
>    24:    48 00 00 01     bl      24 <set_cur_cpu_spec+0x24>
>              24: R_PPC_REL24    add_reloc_offset
>    28:    7f c4 f3 78     mr      r4,r30
>    2c:    38 a0 00 58     li      r5,88
>    30:    48 00 00 01     bl      30 <set_cur_cpu_spec+0x30>
>              30: R_PPC_REL24    __memcpy
>    34:    38 7f 00 58     addi    r3,r31,88
>    38:    48 00 00 01     bl      38 <set_cur_cpu_spec+0x38>
>              38: R_PPC_REL24    add_reloc_offset
>    3c:    93 e3 00 00     stw     r31,0(r3)
>    40:    80 01 00 24     lwz     r0,36(r1)
>    44:    83 c1 00 18     lwz     r30,24(r1)
>    48:    83 e1 00 1c     lwz     r31,28(r1)
>    4c:    7c 08 03 a6     mtlr    r0
>    50:    38 21 00 20     addi    r1,r1,32
>    54:    4e 80 00 20     blr
> 
> This is v5.10 with commit adcf59187e270 reverted:
> 
> 00000000 <set_cur_cpu_spec>:
>     0:    94 21 ff e0     stwu    r1,-32(r1)
>     4:    7c 69 1b 78     mr      r9,r3
>     8:    bf c1 00 18     stmw    r30,24(r1)
>     c:    3f e0 00 00     lis     r31,0
>              e: R_PPC_ADDR16_HA    .data..read_mostly
>    10:    3b ff 00 00     addi    r31,r31,0
>              12: R_PPC_ADDR16_LO    .data..read_mostly
>    14:    7c 08 02 a6     mflr    r0
>    18:    7d 3e 4b 78     mr      r30,r9
>    1c:    7f e3 fb 78     mr      r3,r31
>    20:    90 01 00 24     stw     r0,36(r1)
>    24:    48 00 00 01     bl      24 <set_cur_cpu_spec+0x24>
>              24: R_PPC_REL24    add_reloc_offset
>    28:    7f c4 f3 78     mr      r4,r30
>    2c:    38 a0 00 58     li      r5,88
>    30:    48 00 00 01     bl      30 <set_cur_cpu_spec+0x30>
>              30: R_PPC_REL24    memcpy
>    34:    38 7f 00 58     addi    r3,r31,88
>    38:    48 00 00 01     bl      38 <set_cur_cpu_spec+0x38>
>              38: R_PPC_REL24    add_reloc_offset
>    3c:    93 e3 00 00     stw     r31,0(r3)
>    40:    80 01 00 24     lwz     r0,36(r1)
>    44:    83 c1 00 18     lwz     r30,24(r1)
>    48:    83 e1 00 1c     lwz     r31,28(r1)
>    4c:    7c 08 03 a6     mtlr    r0
>    50:    38 21 00 20     addi    r1,r1,32
>    54:    4e 80 00 20     blr
> 
> So my question is ? Do we still have this issue nowadays ?

I now did the same test with v7.2 without and with adcf59187e270 
reverted. I both cases I get memcpy().

Christophe