Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp3351544pxb; Mon, 16 Nov 2020 12:10:53 -0800 (PST) X-Google-Smtp-Source: ABdhPJyaHqoB11XgnxJrKiSKc69Nx6iA0DqhpmpolLrf8QAXVaay3KnFF5DlIg6M8vZNdzUr3t5v X-Received: by 2002:a17:906:3644:: with SMTP id r4mr16285875ejb.517.1605557452795; Mon, 16 Nov 2020 12:10:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605557452; cv=none; d=google.com; s=arc-20160816; b=JMMEP8eKg76Rffsx0jX3DGJ0YitCUfRGabxTV/Sj5Cr+f1viY7tnT0QLdWx8z0ICWf hrBDLxZXG3G+JfavGqSiFhHCbGnsmuZ8G76sT51jab2ArwfvgQsTwnL/TjnZQlqFzvhd iwAzEckpFhXCFoQM74PJ2Brbs9VnpUyyWBdMqRqQ5YQuyhrsdHoZYQXgPzqbybF7c1wl Wf5oWh8jvsKNU92GyHNdiJp6Wp+KaAbcIli2oEfUPKhIr6nFXCFSNOfPOZ7kbM0zWkZo N3KAlqux9aBePGCvaafM8QfRHf8JAozxZ2O161b9fgPZfUTakHfrRjj+Dk7CWNNhDeg7 sFEQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=MqIy6vRHBVfAzA3qssTHaKjQGN38IC2kr4TlO0tIc90=; b=WxnLqLTO6j/2weh3UFx1J8XwmjcXaDstCHWAd3LIisGyv+lE8Q8WUMzFVQcyJygqxO muGscT/O4YjwyuORY//Xbs5dXUe+6SlTiq3e02dL3Ut62Mre0mLk3TBz7q+0LMIvY+SL G0eeYV+Cv02ZUF5Drn3rfWWAYvmee4B/rAAAMggsXaPQaOQhZmy0bezA8QMTOJ+uVbmc Mw00AfBEyCeE5N33VoQp6bpAtXhOMec2I3AuZzr9OS1mqPFe0iTz7La9i0SjSlLDeLJl warRsWNHT59taoA+7btciVo20crlLbBro4E7WG5CPMBWsj0xcRpeZ6dByxSSH+OXzG/u mz3w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id rn28si12415362ejb.585.2020.11.16.12.10.29; Mon, 16 Nov 2020 12:10:52 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727359AbgKPMmS (ORCPT + 99 others); Mon, 16 Nov 2020 07:42:18 -0500 Received: from foss.arm.com ([217.140.110.172]:39166 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726614AbgKPMmR (ORCPT ); Mon, 16 Nov 2020 07:42:17 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id DC39B101E; Mon, 16 Nov 2020 04:42:16 -0800 (PST) Received: from [10.37.12.42] (unknown [10.37.12.42]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 003023F70D; Mon, 16 Nov 2020 04:42:12 -0800 (PST) Subject: Re: [PATCH RFC v2 04/21] kasan: unpoison stack only with CONFIG_KASAN_STACK To: Dmitry Vyukov , Catalin Marinas Cc: Marco Elver , Andrey Konovalov , Will Deacon , Alexander Potapenko , Evgenii Stepanov , Kostya Serebryany , Peter Collingbourne , Serban Constantinescu , Andrey Ryabinin , Elena Petrova , Branislav Rankov , Kevin Brodsky , Andrew Morton , kasan-dev , Linux ARM , Linux-MM , LKML References: From: Vincenzo Frascino Message-ID: <9d4156e6-ec4f-a742-a44e-f38bf7fa9ba9@arm.com> Date: Mon, 16 Nov 2020 12:45:19 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/16/20 12:19 PM, Dmitry Vyukov wrote: > On Mon, Nov 16, 2020 at 1:16 PM Catalin Marinas wrote: >> >> On Mon, Nov 16, 2020 at 12:50:00PM +0100, Marco Elver wrote: >>> On Mon, 16 Nov 2020 at 11:59, Dmitry Vyukov wrote: >>>> On Thu, Oct 29, 2020 at 8:57 PM 'Andrey Konovalov' via kasan-dev >>>> wrote: >>>>> On Tue, Oct 27, 2020 at 1:44 PM Dmitry Vyukov wrote: >>>>>> >>>>>> On Thu, Oct 22, 2020 at 3:19 PM Andrey Konovalov wrote: >>>>>>> >>>>>>> There's a config option CONFIG_KASAN_STACK that has to be enabled for >>>>>>> KASAN to use stack instrumentation and perform validity checks for >>>>>>> stack variables. >>>>>>> >>>>>>> There's no need to unpoison stack when CONFIG_KASAN_STACK is not enabled. >>>>>>> Only call kasan_unpoison_task_stack[_below]() when CONFIG_KASAN_STACK is >>>>>>> enabled. >>>>>>> >>>>>>> Signed-off-by: Andrey Konovalov >>>>>>> Link: https://linux-review.googlesource.com/id/If8a891e9fe01ea543e00b576852685afec0887e3 >>>>>>> --- >>>>>>> arch/arm64/kernel/sleep.S | 2 +- >>>>>>> arch/x86/kernel/acpi/wakeup_64.S | 2 +- >>>>>>> include/linux/kasan.h | 10 ++++++---- >>>>>>> mm/kasan/common.c | 2 ++ >>>>>>> 4 files changed, 10 insertions(+), 6 deletions(-) >>>>>>> >>>>>>> diff --git a/arch/arm64/kernel/sleep.S b/arch/arm64/kernel/sleep.S >>>>>>> index ba40d57757d6..bdadfa56b40e 100644 >>>>>>> --- a/arch/arm64/kernel/sleep.S >>>>>>> +++ b/arch/arm64/kernel/sleep.S >>>>>>> @@ -133,7 +133,7 @@ SYM_FUNC_START(_cpu_resume) >>>>>>> */ >>>>>>> bl cpu_do_resume >>>>>>> >>>>>>> -#ifdef CONFIG_KASAN >>>>>>> +#if defined(CONFIG_KASAN) && CONFIG_KASAN_STACK >>>>>>> mov x0, sp >>>>>>> bl kasan_unpoison_task_stack_below >>>>>>> #endif >>>>>>> diff --git a/arch/x86/kernel/acpi/wakeup_64.S b/arch/x86/kernel/acpi/wakeup_64.S >>>>>>> index c8daa92f38dc..5d3a0b8fd379 100644 >>>>>>> --- a/arch/x86/kernel/acpi/wakeup_64.S >>>>>>> +++ b/arch/x86/kernel/acpi/wakeup_64.S >>>>>>> @@ -112,7 +112,7 @@ SYM_FUNC_START(do_suspend_lowlevel) >>>>>>> movq pt_regs_r14(%rax), %r14 >>>>>>> movq pt_regs_r15(%rax), %r15 >>>>>>> >>>>>>> -#ifdef CONFIG_KASAN >>>>>>> +#if defined(CONFIG_KASAN) && CONFIG_KASAN_STACK >>>>>>> /* >>>>>>> * The suspend path may have poisoned some areas deeper in the stack, >>>>>>> * which we now need to unpoison. >>>>>>> diff --git a/include/linux/kasan.h b/include/linux/kasan.h >>>>>>> index 3f3f541e5d5f..7be9fb9146ac 100644 >>>>>>> --- a/include/linux/kasan.h >>>>>>> +++ b/include/linux/kasan.h >>>>>>> @@ -68,8 +68,6 @@ static inline void kasan_disable_current(void) {} >>>>>>> >>>>>>> void kasan_unpoison_memory(const void *address, size_t size); >>>>>>> >>>>>>> -void kasan_unpoison_task_stack(struct task_struct *task); >>>>>>> - >>>>>>> void kasan_alloc_pages(struct page *page, unsigned int order); >>>>>>> void kasan_free_pages(struct page *page, unsigned int order); >>>>>>> >>>>>>> @@ -114,8 +112,6 @@ void kasan_restore_multi_shot(bool enabled); >>>>>>> >>>>>>> static inline void kasan_unpoison_memory(const void *address, size_t size) {} >>>>>>> >>>>>>> -static inline void kasan_unpoison_task_stack(struct task_struct *task) {} >>>>>>> - >>>>>>> static inline void kasan_alloc_pages(struct page *page, unsigned int order) {} >>>>>>> static inline void kasan_free_pages(struct page *page, unsigned int order) {} >>>>>>> >>>>>>> @@ -167,6 +163,12 @@ static inline size_t kasan_metadata_size(struct kmem_cache *cache) { return 0; } >>>>>>> >>>>>>> #endif /* CONFIG_KASAN */ >>>>>>> >>>>>>> +#if defined(CONFIG_KASAN) && CONFIG_KASAN_STACK >>>>>> >>>>>> && defined(CONFIG_KASAN_STACK) for consistency >>>>> >>>>> CONFIG_KASAN_STACK is different from other KASAN configs. It's always >>>>> defined, and its value is what controls whether stack instrumentation >>>>> is enabled. >>>> >>>> Not sure why we did this instead of the following, but okay. >>>> >>>> config KASAN_STACK >>>> - int >>>> - default 1 if KASAN_STACK_ENABLE || CC_IS_GCC >>>> - default 0 >>>> + bool >>>> + default y if KASAN_STACK_ENABLE || CC_IS_GCC >>>> + default n >>> >>> I wondered the same, but then looking at scripts/Makefile.kasan I >>> think it's because we directly pass it to the compiler: >>> ... >>> $(call cc-param,asan-stack=$(CONFIG_KASAN_STACK)) \ >>> ... >> >> Try this instead: >> >> $(call cc-param,asan-stack=$(if $(CONFIG_KASAN_STACK),1,0)) \ > > > We could have just 1 config instead of 2 as well. > For gcc we could do no prompt and default value y, and for clang -- > prompt and default value n. I think it should do what we need. > I agree with Catalin's proposal since it should simplify things. Nit: 'default n' is the default hence I do not think it should be required explicitly. -- Regards, Vincenzo