From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A5679D2B92C for ; Tue, 5 Nov 2024 13:44:34 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0B8DD6B0096; Tue, 5 Nov 2024 08:44:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 068C36B0098; Tue, 5 Nov 2024 08:44:33 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E72926B009A; Tue, 5 Nov 2024 08:44:33 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id C7B816B0096 for ; Tue, 5 Nov 2024 08:44:33 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 68DA781529 for ; Tue, 5 Nov 2024 13:44:33 +0000 (UTC) X-FDA: 82752160848.02.ACE393F Received: from relay1-d.mail.gandi.net (relay1-d.mail.gandi.net [217.70.183.193]) by imf08.hostedemail.com (Postfix) with ESMTP id 11CCA160006 for ; Tue, 5 Nov 2024 13:44:08 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf08.hostedemail.com: domain of alex@ghiti.fr designates 217.70.183.193 as permitted sender) smtp.mailfrom=alex@ghiti.fr ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730814213; a=rsa-sha256; cv=none; b=mYvlSiiApGHvX7jUKLpt8xR+fXwBlUQnLGEH8g68uZmYkKvBkOxpkSVvg9p2tFpCitmcLE FQ4+OfyMSH1qhR5n/ip4ebHq+EA+cyZwG2Fw/6BM+fDTwYadGhMqIDMGjtnZZu6mwqtPUv Gxaae/n2S+8FdV+7gJrdxZbQ8tQggJs= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf08.hostedemail.com: domain of alex@ghiti.fr designates 217.70.183.193 as permitted sender) smtp.mailfrom=alex@ghiti.fr ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1730814213; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=TetSS7jFoBp6Tin3h7L23IRUGsf90Xa/sZ5eLbt1uIE=; b=dNf+1QOvP0MVGKIHyb9kziuAlbV8nIjCv46PjHaZvWD5eDadd2xvUdWn8hAQEgtZE8wgot uTOZWCjF6SmhnEjuozrlFpuzhRtFwGFm42o5nO8GArCOAKq1aDdStxtgBA+iGGm9v5RFNX tIyKl/2UoBhvf6V41ppXY3ExioFLgX8= Received: by mail.gandi.net (Postfix) with ESMTPSA id 21972240006; Tue, 5 Nov 2024 13:44:25 +0000 (UTC) Message-ID: <5dba5a49-91e5-4988-9018-63b146b5e26c@ghiti.fr> Date: Tue, 5 Nov 2024 14:44:25 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 5/9] riscv: mm: Log potential KASAN shadow alias Content-Language: en-US To: Samuel Holland , Palmer Dabbelt , linux-riscv@lists.infradead.org, Andrey Ryabinin , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Vincenzo Frascino , kasan-dev@googlegroups.com Cc: llvm@lists.linux.dev, Catalin Marinas , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Alexandre Ghiti , Will Deacon , Evgenii Stepanov , Andrew Morton , linux-arm-kernel@lists.infradead.org References: <20241022015913.3524425-1-samuel.holland@sifive.com> <20241022015913.3524425-6-samuel.holland@sifive.com> From: Alexandre Ghiti In-Reply-To: <20241022015913.3524425-6-samuel.holland@sifive.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-GND-Sasl: alex@ghiti.fr X-Rspam-User: X-Rspamd-Queue-Id: 11CCA160006 X-Rspamd-Server: rspam11 X-Stat-Signature: 33j6wqjnci6ta8csront7i6xzeu57tao X-HE-Tag: 1730814248-120587 X-HE-Meta: U2FsdGVkX18oyOiy/pCy9uC6GPYB27ykvgcDoxnM8bLVGFBBhSjmjoIrhaA3s8WagLu/w4YgFBW6BtziANe7wnPKfJr9nILdCBFyXzkF8XheF3FsTLppf9BOhsIWd9mUTulZIHryO0cdNvowxAGBrT76UHnNxxrD5Y3J8aFMDJWSPxBxiEGIUwTLBPG1mzVu9zQDfGe4SlP/wkVggZwJsCizrIlAA/C1YLNxmDN4FczJIrvGNDJezWrhTE/u6EMxvdGhP1guUUBgzexionLugBnHxNdrf2pJvIizoN5xid2s2Eq+hnnkOfi19wFkGK59f9LLZV82y1+lWidWTm1wS+jU2FZYZLFo7Ye4YkWCF1X3mM4/24NuNU8SGSl5KmAbHTSWAWgRrbB1aB1xmLz6I6l9nL7JkqaEGUfA89B0PEETujTZ0vwfLJbEV38+X7evfZtajYL2eOWj33rypiej3rhjSDIV9box2cLoa0+iLKA5UOnV2sq2S8IFsbLrYqvF36dBK4U9TnmHO9FEJTeXkpxsaPTQgsSgohQ43ir6ZlgzIyFWDNLBsMesGlFwZ9BDmSQuP64S0NNNdkR+06155R0g7tjPu1V7yn9Rq4lhvYbdw5F7Gr9biVNSkKFp/VbgA/Yjh9IozErgCeWo6UFfRzVyEKlKIJyWI5r2UOxzEehrCSwGXKhDVKjNLv+gYEyA/oSmD8pgF8ZFakFu0SSHIyDIdnqkeMXOFEeJWVy6RgNLFPKynnlHpkzoLOlQIXSL+/UbUi1nDwYrV8e4KBYCYtsuFDFDVXmpJ7sd35td3Py8GROxYAT+s1d+x4BBbGKPpHvUuE1mCiR7XF/JVtNim8BeBgdXfeOKOJD/OnIo3X1CI0OfthD3AS9E3J22W+dshpMQmZmrKOPRUSb6IJjCiO8vtorM0daQfsyZzCBaA3MEiJ6j//gPm/WUht8xbseuLB05lXKfMnlWZl1h0GV p/gCDMeH aNtS8+GRMe9I0ccdDhKyXdyxUiKCP8RONak6HrWQGQcwF7Rxy2DdAiMExtPBW1VpQ3SP57vysslT7q7jvxZvrWVYjdYlYKu2Cs76WMVUv78At/vnC3v+pDUVlRvvPwrW/7bQUDpnyS+s5osVBM5fUs/FWV1V936LNZrkZHcTW/yEn7vPgfAKDSFbY2OGZCEdx9kN1iiXhzANLmaxYcLX7ag3tPv71TX0VBumGfDrMKYesuquvCv+I9A7G3ZpEa3lMSqKV6PlwdTuGsBsJkpza80+crA== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Hi Samuel, On 22/10/2024 03:57, Samuel Holland wrote: > When KASAN is enabled, shadow memory is allocated and mapped for all > legitimate kernel addresses, but not for the entire address space. As a > result, the kernel can fault when accessing a shadow address computed > from a bogus pointer. This can be confusing, because the shadow address > computed for (e.g.) NULL looks nothing like a NULL pointer. To assist > debugging, if the faulting address might be the result of a KASAN shadow > memory address computation, report the range of original memory > addresses that would map to the faulting address. > > Signed-off-by: Samuel Holland > --- > > Changes in v2: > - New patch for v2 > > arch/riscv/mm/fault.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/arch/riscv/mm/fault.c b/arch/riscv/mm/fault.c > index a9f2b4af8f3f..dae1131221b7 100644 > --- a/arch/riscv/mm/fault.c > +++ b/arch/riscv/mm/fault.c > @@ -8,6 +8,7 @@ > > > #include > +#include > #include > #include > #include > @@ -30,6 +31,8 @@ static void die_kernel_fault(const char *msg, unsigned long addr, > pr_alert("Unable to handle kernel %s at virtual address " REG_FMT "\n", msg, > addr); > > + kasan_non_canonical_hook(addr); > + > bust_spinlocks(0); > die(regs, "Oops"); > make_task_dead(SIGKILL); That's nice, I used to do that by hand :) Reviewed-by: Alexandre Ghiti Thanks, Alex