From patchwork Fri Apr 4 13:14:14 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Maciej Wieczor-Retman X-Patchwork-Id: 14038461 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 7E491C36010 for ; Fri, 4 Apr 2025 13:17:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6523028000E; Fri, 4 Apr 2025 09:17:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 60182280001; Fri, 4 Apr 2025 09:17:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 47A6828000E; Fri, 4 Apr 2025 09:17:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 2462E280001 for ; Fri, 4 Apr 2025 09:17:20 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 86EB91601AB for ; Fri, 4 Apr 2025 13:17:21 +0000 (UTC) X-FDA: 83296412682.14.969AD85 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.11]) by imf23.hostedemail.com (Postfix) with ESMTP id 4CE0C140010 for ; Fri, 4 Apr 2025 13:17:19 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=K6xPdlWR; spf=pass (imf23.hostedemail.com: domain of maciej.wieczor-retman@intel.com designates 198.175.65.11 as permitted sender) smtp.mailfrom=maciej.wieczor-retman@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1743772639; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=hdkFszdtBdvZ7spFw9JqGKHX1CI6+ij0yexdS7qNDVs=; b=ZqT9nsZw0kb44VwfyVdiff4/eRTdLv9pcmkKnJ1C+APrmZG06dmPHFU1m832kiGpnwBNT4 WGcBZemidVX32X3DXXFLC+FfUu1Cw8A3ZfF8/1yQFTub3zSaLyPWleLQbU+21YkHGmYm6s LmRWe2mMmM0mvRV4KayA6s/iuzk9rps= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=K6xPdlWR; spf=pass (imf23.hostedemail.com: domain of maciej.wieczor-retman@intel.com designates 198.175.65.11 as permitted sender) smtp.mailfrom=maciej.wieczor-retman@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1743772639; a=rsa-sha256; cv=none; b=eTjBu75uCMYCS0VAk/99+MTXrhlR2hIF4xfJ3ostoY60kxxjJOXn99XD0i7elKatyJSxnq k0IQ6dv1y1RrDDLfFzKQ1urjahvOTWYGtEEoyl8laTeH9x6JY/u7YC8spP+1gUCvzn3q8+ Ye0eKlIeDYhVLQz3BaA850Ius8dWSzI= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1743772640; x=1775308640; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=SGBIaGE4wssEPedJ31N8z8fzvg1X3QBHbqhKaFUlYMU=; b=K6xPdlWRSZA1RziIDrHcGYD49I7Y58sHI19QgfqFATTKcsGFzmOQ5PTN BDvogcZew3/OzYK9moGFtgU0TPhLw6lvDi5JM0D4kDMjBLs4wIz/VMpVX x6sJAUHLaWGksG/x+Uz7Sqj0QhXVLh+tcaUekbZ1W6G5o4+PBB+Tq204E Oj6UDWmRoMbPxHu6QrN3HjeW9NfR2jcBsZtzXULswQSM63gTRg2Yhqzb3 8vViWNHTDLmEz9g0BM1PY0Db91GqAZC03nCJGBfZ4My7/GwetlJVtPZlV EYJCaEC/FhkI7MJ24E6ZtMZxt/gV85JEicb3bOVq7PLNxF643Sv9UGv6A g==; X-CSE-ConnectionGUID: UyQFa2kMRAWuoj1Pz9M9Wg== X-CSE-MsgGUID: ygGGm9XSS4+xlTi6AnJGgQ== X-IronPort-AV: E=McAfee;i="6700,10204,11394"; a="55401958" X-IronPort-AV: E=Sophos;i="6.15,188,1739865600"; d="scan'208";a="55401958" Received: from fmviesa009.fm.intel.com ([10.60.135.149]) by orvoesa103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Apr 2025 06:17:18 -0700 X-CSE-ConnectionGUID: fsVEwllhSRmFPFm7kCxT5g== X-CSE-MsgGUID: rCQHxZP4R6qYhcSTuBxnqw== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.15,188,1739865600"; d="scan'208";a="128157312" Received: from opintica-mobl1 (HELO wieczorr-mobl1.intel.com) ([10.245.245.50]) by fmviesa009-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Apr 2025 06:17:02 -0700 From: Maciej Wieczor-Retman To: hpa@zytor.com, hch@infradead.org, nick.desaulniers+lkml@gmail.com, kuan-ying.lee@canonical.com, masahiroy@kernel.org, samuel.holland@sifive.com, mingo@redhat.com, corbet@lwn.net, ryabinin.a.a@gmail.com, guoweikang.kernel@gmail.com, jpoimboe@kernel.org, ardb@kernel.org, vincenzo.frascino@arm.com, glider@google.com, kirill.shutemov@linux.intel.com, apopple@nvidia.com, samitolvanen@google.com, maciej.wieczor-retman@intel.com, kaleshsingh@google.com, jgross@suse.com, andreyknvl@gmail.com, scott@os.amperecomputing.com, tony.luck@intel.com, dvyukov@google.com, pasha.tatashin@soleen.com, ziy@nvidia.com, broonie@kernel.org, gatlin.newhouse@gmail.com, jackmanb@google.com, wangkefeng.wang@huawei.com, thiago.bauermann@linaro.org, tglx@linutronix.de, kees@kernel.org, akpm@linux-foundation.org, jason.andryuk@amd.com, snovitoll@gmail.com, xin@zytor.com, jan.kiszka@siemens.com, bp@alien8.de, rppt@kernel.org, peterz@infradead.org, pankaj.gupta@amd.com, thuth@redhat.com, andriy.shevchenko@linux.intel.com, joel.granados@kernel.org, kbingham@kernel.org, nicolas@fjasle.eu, mark.rutland@arm.com, surenb@google.com, catalin.marinas@arm.com, morbo@google.com, justinstitt@google.com, ubizjak@gmail.com, jhubbard@nvidia.com, urezki@gmail.com, dave.hansen@linux.intel.com, bhe@redhat.com, luto@kernel.org, baohua@kernel.org, nathan@kernel.org, will@kernel.org, brgerst@gmail.com Cc: llvm@lists.linux.dev, linux-mm@kvack.org, linux-doc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, x86@kernel.org Subject: [PATCH v3 10/14] x86: Update the KASAN non-canonical hook Date: Fri, 4 Apr 2025 15:14:14 +0200 Message-ID: X-Mailer: git-send-email 2.49.0 In-Reply-To: References: MIME-Version: 1.0 X-Rspamd-Queue-Id: 4CE0C140010 X-Stat-Signature: qr5yntf5xinkcxd74sci3d5un4kn9x8k X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1743772639-948121 X-HE-Meta: U2FsdGVkX1+duuBYRgaAWFF2MC/dRGAfMXdUvm2StrVhGir5EUJmtxTIl9R1IZllt+qkJSggXLW4bRVaP4SrntyEbiN5D1y0zb1VwIl1Sq2kDEjnLHIASOEuqcBy6qvh23ECvkdvIOoR8Xkezq0Jj96svAfoOC4PXkdYWnKy6bLhY/FZrsZWxOIadKNXnu41ThsPKiGzqZgptPDn0H/gQdIrDr47ZvuDvJOSK+PDkLtGe9EbNduVrAstMRGkXEeqKcONN5YiUqqUsQi8z8gQbnzCeypiu+s6jrr4mJYQNXRU2RRDvUv4PENAgmuZvl9dVTpEHdxIFrOX9L9h4la4svtzYsqZ4HQAw7913jaUPaQWhVAUA+oo7Mvz6HhbbNl4dozMEKW606+H0u1K4GoQABIdt1fWjeAm5huft0+8G5kQxUnLdYOZ+3+jnkEG2pSYKWBmklyFxdB0/OKtZw/DH1vNUROEcTAASR8uXJ/p6bWH34BA6eV7quxGB3r4pui0+q8tA0fPHVElF0Ki4LK1TcLxCiT67op1LXYBXyr48DXtohpUdqsmqycqCAyjYojGpRrVIjy+J4deTl5SSHogKx/8YErrVXHOUHWw6HO62SCYvNBGuwBliIkKL7iisTamboZoGVx55Y/5g8P2j15v+7LyeAY1b/12UdkOE4GSh8ZDEc/AgI3xLLdHahTKIbgPwkEQea2Vh4SuQkkwCYBeb+dAAsIiuCI9uiCAlE4juoiRn2AGobDTlBCsbMWLl4kcwrq12eKLBGBjrY5A2PDe+jfDQ6wMbaft1HN0+ehzdiG01s+1dLQYUusU4g9YoGjBaVBSBKNR3ITfyHus+T52TTgFkZ48CpH7gWGl0jzEzZeyFUZtjYPUTe+BcVJ6daLJgbDhnSEKD0FOYYVbm9dX/WyA+gyC/nAeJvK0In1Oewlr2p7yzx+x6qKKzf3EdFwgYXO/5zXjQEjFWHg7Deu RZ6+dK/F mS/SBNPUE8e83GctQ7naGpLlhwGSSKgNZ5rDJrWMBlCuj/y00M9Uq7v/dBTSn4hR/WaVlftfAWOLo6lSKI9Q0KRo3S7NZEvFve3BRuuqINGwf3sy/uZ6dK1lNnt+X7XkHoyTzwXDalGvP3EDBhm7m8tbfHxIsu052nbgUe/SqGWw8z8FMVRIVSLMWClHcA7Yqhkl0o25Oi4VxCZQCWkMhMvnRRcqZlt/F9zPBWHU4whTN3hOU9tL3ydS2f0Lxz8/xNQsE 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: The kasan_non_canonical_hook() is useful in pointing out that an address which caused some kind of error could be the result of kasan_mem_to_shadow() mapping. Currently it's called only in the general protection handler code path but can give helpful information also in page fault oops reports. For example consider a page fault for address 0xffdefc0000000000 on a 5-level paging system. It could have been accessed from KASAN's kasan_mem_to_shadow() called on 0xfef0000000000000 address. Without the kasan_non_canonical_hook() in the page fault case it might be hard to figure out why an error occurred. Add kasan_non_canonical_hook() to the beginning of show_fault_oops(). Update kasan_non_canonical_hook() to take into account the possible memory to shadow mappings in the software tag-based mode of x86. Patch was tested with positive results by accessing the following addresses, causing #GPs and #PFs. Valid mappings (showing kasan_non_canonical_hook() message): 0xFFFFFFFF8FFFFFFF 0xFEF0000000000000 0x7FFFFF4FFFFFFFFF 0x7EF0000000000000 Invalid mappings (not showing kasan_non_canonical_hook() message): 0xFFFFFFFFF8FFFFFF 0xFFBFFC0000000000 0x07EFFC0000000000 0x000E000000000000 Signed-off-by: Maciej Wieczor-Retman --- Changelog v3: - Move the report.c part from first patch in the series to this new patch to have x86 changes in one place. - Add the call in fault oops. - Extend the comment in report.c with a graphical representation of what addresses are valid and invalid in memory to shadow mapping. arch/x86/mm/fault.c | 2 ++ mm/kasan/report.c | 36 +++++++++++++++++++++++++++++++++++- 2 files changed, 37 insertions(+), 1 deletion(-) diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c index 697432f63c59..16366af60ae5 100644 --- a/arch/x86/mm/fault.c +++ b/arch/x86/mm/fault.c @@ -511,6 +511,8 @@ show_fault_oops(struct pt_regs *regs, unsigned long error_code, unsigned long ad if (!oops_may_print()) return; + kasan_non_canonical_hook(address); + if (error_code & X86_PF_INSTR) { unsigned int level; bool nx, rw; diff --git a/mm/kasan/report.c b/mm/kasan/report.c index f24f11cc644a..135307c93c2c 100644 --- a/mm/kasan/report.c +++ b/mm/kasan/report.c @@ -700,7 +700,7 @@ void kasan_non_canonical_hook(unsigned long addr) * operation would overflow only for some memory addresses. However, due * to the chosen KASAN_SHADOW_OFFSET values and the fact the * kasan_mem_to_shadow() only operates on pointers with the tag reset, - * the overflow always happens. + * the overflow always happens (for both x86 and arm64). * * For arm64, the top byte of the pointer gets reset to 0xFF. Thus, the * possible shadow addresses belong to a region that is the result of @@ -715,6 +715,40 @@ void kasan_non_canonical_hook(unsigned long addr) return; } + /* + * For x86-64, only the pointer bits [62:57] get reset, and bits #63 + * and #56 can be 0 or 1. Thus, kasan_mem_to_shadow() can be possibly + * applied to two regions of memory: + * [0x7E00000000000000, 0x7FFFFFFFFFFFFFFF] and + * [0xFE00000000000000, 0xFFFFFFFFFFFFFFFF]. As the overflow happens + * for both ends of both memory ranges, both possible shadow regions + * are contiguous. + * + * Given the KASAN_SHADOW_OFFSET equal to 0xffeffc0000000000, the + * following ranges are valid mem-to-shadow mappings: + * + * 0xFFFFFFFFFFFFFFFF + * INVALID + * 0xFFEFFBFFFFFFFFFF - kasan_mem_to_shadow(~0UL) + * VALID - kasan shadow mem + * VALID - non-canonical kernel virtual address + * 0xFFCFFC0000000000 - kasan_mem_to_shadow(0xFEUL << 56) + * INVALID + * 0x07EFFBFFFFFFFFFF - kasan_mem_to_shadow(~0UL >> 1) + * VALID - non-canonical user virtual addresses + * VALID - user addresses + * 0x07CFFC0000000000 - kasan_mem_to_shadow(0x7EUL << 56) + * INVALID + * 0x0000000000000000 + */ + if (IS_ENABLED(CONFIG_KASAN_SW_TAGS) && IS_ENABLED(CONFIG_X86_64)) { + if ((addr < (u64)kasan_mem_to_shadow((void *)(0x7EUL << 56)) || + addr > (u64)kasan_mem_to_shadow((void *)(~0UL >> 1))) && + (addr < (u64)kasan_mem_to_shadow((void *)(0xFEUL << 56)) || + addr > (u64)kasan_mem_to_shadow((void *)(~0UL)))) + return; + } + orig_addr = (unsigned long)kasan_shadow_to_mem((void *)addr); /*