Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <c6fbc75a-4e8c-05f4-c1d9-53693a7c604f@gmail.com>
Date:   Fri, 28 Oct 2022 17:20:22 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.0
Subject: Re: [PATCH] x86/kasan: map shadow for percpu pages on demand
To:     "Yin, Fengwei" <fengwei.yin@intel.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        kernel test robot <yujie.liu@intel.com>
Cc:     Seth Jenkins <sethjenkins@google.com>,
        Kees Cook <keescook@chromium.org>,
        linux-kernel@vger.kernel.org, x86@kernel.org,
        Alexander Potapenko <glider@google.com>,
        Andrey Konovalov <andreyknvl@gmail.com>,
        Dmitry Vyukov <dvyukov@google.com>,
        Vincenzo Frascino <vincenzo.frascino@arm.com>,
        kasan-dev@googlegroups.com, Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        "H. Peter Anvin" <hpa@zytor.com>, Andy Lutomirski <luto@kernel.org>
References: <864b4fbe-4462-9962-7afd-9140d5165cdb@intel.com>
 <20221027213105.4905-1-ryabinin.a.a@gmail.com>
 <3a372c25-7ce1-e931-8d7e-a2e14b82c8f0@intel.com>
Content-Language: en-US
From:   Andrey Ryabinin <ryabinin.a.a@gmail.com>
In-Reply-To: <3a372c25-7ce1-e931-8d7e-a2e14b82c8f0@intel.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk


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.