[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c6fbc75a-4e8c-05f4-c1d9-53693a7c604f@gmail.com>
Date: Fri, 28 Oct 2022 17:20:22 +0300
From: Andrey Ryabinin <ryabinin.a.a@...il.com>
To: "Yin, Fengwei" <fengwei.yin@...el.com>,
Peter Zijlstra <peterz@...radead.org>,
Dave Hansen <dave.hansen@...ux.intel.com>,
kernel test robot <yujie.liu@...el.com>
Cc: Seth Jenkins <sethjenkins@...gle.com>,
Kees Cook <keescook@...omium.org>,
linux-kernel@...r.kernel.org, x86@...nel.org,
Alexander Potapenko <glider@...gle.com>,
Andrey Konovalov <andreyknvl@...il.com>,
Dmitry Vyukov <dvyukov@...gle.com>,
Vincenzo Frascino <vincenzo.frascino@....com>,
kasan-dev@...glegroups.com, Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
"H. Peter Anvin" <hpa@...or.com>, Andy Lutomirski <luto@...nel.org>
Subject: Re: [PATCH] x86/kasan: map shadow for percpu pages on demand
On 10/28/22 05:51, Yin, Fengwei wrote:
> Hi Andrey,
>
>> void __init kasan_init(void)
>> {
>> int i;
>> @@ -393,9 +405,6 @@ void __init kasan_init(void)
>> kasan_mem_to_shadow((void *)VMALLOC_END + 1),
>> shadow_cpu_entry_begin);
>>
>> - kasan_populate_shadow((unsigned long)shadow_cpu_entry_begin,
>> - (unsigned long)shadow_cpu_entry_end, 0);
>> -
> There will be address in the range (shadow_cpu_entry_begin, shadow_cpu_entry_end)
> which has no KASAN shadow mapping populated after the patch. Not sure whether
> it could be a problem. Thanks.
>
This shouldn't be a problem. It's vital to have shadow *only* for addresses with mapped memory.
Shadow address accessed only if the address itself accessed. So the difference between not having shadow
for address with no mapping vs having it, is whether we crash on access to KASAN shadow or crash few
instructions later on access to the address itself.
Powered by blists - more mailing lists