linux-kernel - Re: [PATCH v2] mm: fix KASAN build error due to p*d_populate

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2fb52098-3952-48f1-b6c3-bbc95ce00d8d@gmail.com>
Date: Fri, 22 Aug 2025 18:02:40 +0200
From: Andrey Ryabinin <ryabinin.a.a@...il.com>
To: Harry Yoo <harry.yoo@...cle.com>, Dave Hansen <dave.hansen@...el.com>
Cc: Liam.Howlett@...cle.com, akpm@...ux-foundation.org, andreyknvl@...il.com,
 aneesh.kumar@...ux.ibm.com, anshuman.khandual@....com, apopple@...dia.com,
 ardb@...nel.org, arnd@...db.de, bp@...en8.de, cl@...two.org,
 dave.hansen@...ux.intel.com, david@...hat.com, dennis@...nel.org,
 dev.jain@....com, dvyukov@...gle.com, glider@...gle.com,
 gwan-gyeong.mun@...el.com, hpa@...cr.com, jane.chu@...cle.com,
 jgross@...e.de, jhubbard@...dia.com, joao.m.martins@...cle.com,
 joro@...tes.org, kas@...nel.org, kevin.brodsky@....com,
 linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-mm@...ck.org, lorenzo.stoakes@...cle.com, luto@...nel.org,
 maobibo@...ngson.cn, mhocko@...e.com, mingo@...hat.com, osalvador@...e.de,
 peterx@...hat.com, peterz@...radead.org, rppt@...nel.org,
 ryan.roberts@....com, stable@...r.kernel.org, surenb@...gle.com,
 tglx@...utronix.de, thuth@...hat.com, tj@...nel.org, urezki@...il.com,
 vbabka@...e.cz, vincenzo.frascino@....com, x86@...nel.org,
 zhengqi.arch@...edance.com
Subject: Re: [PATCH v2] mm: fix KASAN build error due to p*d_populate_kernel()



On 8/22/25 3:11 AM, Harry Yoo wrote:
> On Thu, Aug 21, 2025 at 10:36:12AM -0700, Dave Hansen wrote:
>> On 8/21/25 04:57, Harry Yoo wrote:
>>> However, {pgd,p4d}_populate_kernel() is defined as a function regardless
>>> of the number of page table levels, so the compiler may not optimize
>>> them away. In this case, the following linker error occurs:
> 
> Hi, thanks for taking a look, Dave!
> 
> First of all, this is a fix-up patch of a mm-hotfixes patch series that
> fixes a bug (I should have explained that in the changelog) [1].
> 
> [1] https://lore.kernel.org/linux-mm/20250818020206.4517-1-harry.yoo@oracle.com
> 
> I think we can continue discussing it and perhaps do that as part of
> a follow-up series, because the current patch series need to be backported
> to -stable and your suggestion to improve existing code doesn't require
> -stable backports.
> 
> Does that sound fine?
> 
>> This part of the changelog confused me. I think it's focusing on the
>> wrong thing.
>>
>> The code that's triggering this is literally:
>>
>>>                         pgd_populate(&init_mm, pgd,
>>>                                         lm_alias(kasan_early_shadow_p4d));
>>
>> It sure _looks_ like it's unconditionally referencing the
>> 'kasan_early_shadow_p4d' symbol. I think it's wrong to hide that with
>> macro magic and just assume that the macros won't reference it.
>>
>> If a symbol isn't being defined, it shouldn't be referenced in C code.:q


That's not exactly the case for the kernel. It historically relied on being
compiled with optimization and compiler being able to eliminate unused references.
AFAIR BUILD_BUG_ON() works like that, there are also plenty of code like

if  (IS_ENABLED(CONFIG_SOMETHING))
	ptr = &something;
else
	ptr = &something_else; 

e.g. irq_remaping_prepare();


> 
> A fair point, and that's what KASAN code has been doing for years.
> 
>> The right way to do it is to have an #ifdef in a header that avoids
>> compiling in the reference to the symbol.
> 
> You mean defining some wrapper functions for p*d_populate_kernel() in
> KASAN with different implementations based on ifdeffery?
> 
> Just to clarify, what should be the exact ifdeffery to cover these cases?
> #if CONFIG_PGTABLE_LEVELS == 4 and 5, or
> #ifdef __PAGETABLE_P4D_FOLDED and __PAGETABLE_PUD_FOLDED ?
> 

I think ifdef should be the same as for symbol, so '#if CONFIG_PGTABLE_LEVELS > 4'
for *_p4d and '#if CONFIG_PGTABLE_LEVELS > 3' for *_pud


> I have no strong opinion on this, let's hear what KASAN folks think.
> 

So, I think we have following options:

1. Macros as you did.
2. Hide references in function under  '#if CONFIG_PGTABLE_LEVELS > x', like Dave suggested.
3. It should be enough to just add if in code like
            if (CONFIG_PGTABLE_LEVELS > 4)
		pgd_populate_kernel(addr, pgd,
                                          lm_alias(kasan_early_shadow_p4d));
Compiler should be able to optimize it away.

4. I guess that the link error is due to enabled CONFIG_DEBUG_VIRTUAL=y
lm_alias() ends up with __phys_addr_symbol() function call which compiler can't optimize away.
Technically we can declare __phys_addr_symbol() with __attribute__((pure)), so compiler will
be able to optimize away this call, because the result should be unused.
But I'm not sure we really want that, because it's debug function and even if the result is unused
we might want to still have a check if symbol address is correct.


I would probably prefer 3rd option, but I don't really have very strong opinion, so either way is fine.