Received: by 2002:a05:6a10:16a7:0:0:0:0 with SMTP id gp39csp221181pxb; Thu, 12 Nov 2020 01:55:45 -0800 (PST) X-Google-Smtp-Source: ABdhPJwwpI1Y5ilnxRWhAKq0YPXp9PoRxAF4rlR9hW/CpVDuodL7/gjgsYZEH464xlGKKzFyHM3t X-Received: by 2002:a17:906:8398:: with SMTP id p24mr30307207ejx.401.1605174945711; Thu, 12 Nov 2020 01:55:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1605174945; cv=none; d=google.com; s=arc-20160816; b=dsb/zGXLWQqXNYHN0r5bm9cF+MVKoDx4BbrxxGgObl4N0/sHx6gt4NhmzHt8ussO8R ZI4cGAr/KihLdiHVayNPtmWICu4f+/F6L/tB05sNSbEgOvWVXQocsSqrpA7BYSEJJKjh Trut7boC8NoYCuoQpj6xoYlV2yApGTZy1NqHlMeFe2DYUNPlZmx/lRuLIVWimSqo16ww x2gKVFUB5GfdRBtoZmHwE1JzQRjpp9uFKd5OjmRappFUCKNhWoU5r3Da+j//WXWNdAVt 9n5thkvWx6CDVBGHeXty8+lG+kzNYXuJJ3zJv2s8KeABWatQrqQ9SJtWdWCygituSKHC fNqg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=7iwh72+BvaNWzPAbdR1tCaVm/Ug3yNqjOtD06/oAPVQ=; b=ZvEt9dLEHEagp39kq18ib+Ugl1XVcSMi/My27f96nT5PBj1duEmyIsUm3bTb9VIXcb WKQ1fEl4ZHcu8mIr0c77IjSiFnoCFm/AoePZ1c7KORgSKZdHMiBw1QLvFOsrJJ/vbVSE k1R5qcRLkNZ4RnphjP7HZOnq6LmSRJ/pNrW7OXvb9PDxjr2V/aBOU4sHlPq4cR/pJTub 9/bc9MUgNBO9UwKGpjCH0lXp0goEu1q3hMaKucb3CnFD60QaSG9Rk9BlGhK5EEbVdmm1 +AuSdaCHNFvjKCJTe4qPq+CXQK9Fl6o0EFa5SS4uRGBVQOUf8z+/QDqUcWYf41yZDum4 1UuA== 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 a16si3161053ejd.678.2020.11.12.01.55.22; Thu, 12 Nov 2020 01:55:45 -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 S1727475AbgKLJvl (ORCPT + 99 others); Thu, 12 Nov 2020 04:51:41 -0500 Received: from mail.kernel.org ([198.145.29.99]:42106 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726028AbgKLJvk (ORCPT ); Thu, 12 Nov 2020 04:51:40 -0500 Received: from gaia (unknown [2.26.170.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 95C632053B; Thu, 12 Nov 2020 09:51:37 +0000 (UTC) Date: Thu, 12 Nov 2020 09:51:35 +0000 From: Catalin Marinas To: Andrey Konovalov Cc: Dmitry Vyukov , Alexander Potapenko , Marco Elver , Will Deacon , Vincenzo Frascino , Evgenii Stepanov , Andrey Ryabinin , Branislav Rankov , Kevin Brodsky , Andrew Morton , kasan-dev@googlegroups.com, linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 04/20] kasan, arm64: unpoison stack only with CONFIG_KASAN_STACK Message-ID: <20201112095134.GI29613@gaia> References: <7e95d4739f5617b2c1acf52f37e01f1ca83750b5.1605046662.git.andreyknvl@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7e95d4739f5617b2c1acf52f37e01f1ca83750b5.1605046662.git.andreyknvl@google.com> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Nov 10, 2020 at 11:20:08PM +0100, 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. > > Note, that CONFIG_KASAN_STACK is an option that is currently always > defined when CONFIG_KASAN is enabled, and therefore has to be tested > with #if instead of #ifdef. > > 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 I don't understand why CONFIG_KASAN_STACK is not a bool (do you plan to add more values to it?) but for arm64: Acked-by: Catalin Marinas