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 E61EBC021B2 for ; Tue, 25 Feb 2025 21:38:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7893228000B; Tue, 25 Feb 2025 16:38:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 75FA1280003; Tue, 25 Feb 2025 16:38:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6011F28000B; Tue, 25 Feb 2025 16:38:21 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 41BED280003 for ; Tue, 25 Feb 2025 16:38:21 -0500 (EST) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id EAA70B03BE for ; Tue, 25 Feb 2025 21:38:20 +0000 (UTC) X-FDA: 83159780760.06.104781A Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) by imf02.hostedemail.com (Postfix) with ESMTP id 0D69180005 for ; Tue, 25 Feb 2025 21:38:18 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Wx3LZMg+; spf=pass (imf02.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.221.53 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740519499; 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:dkim-signature; bh=fXFKcm0lZuF5OG0aApeKuQOf3+mW6bFB0yCFPCGgwEk=; b=lpnkRgs6Hr7yhzh/Cum2ySqG4kxERSKz6Ym5ZLtEBL2lGL746EGrDzv1eDpoUf4xztf5sR imFqrr9a47UgBDS6Cqn2/nrCZRbR9Fs6oFPf+57rKk+ORz3sWyh59DxWxydms6kUSGiX6h go5J0rg2IT139kApmwvom4dClgo2WzI= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Wx3LZMg+; spf=pass (imf02.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.221.53 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740519499; a=rsa-sha256; cv=none; b=56e3C/xXu7QvbgiY+SYwYoJSrYbE2kmIvYRbjOL3RkjZXz4y6OtW5w9t3O0g13e2syKeX5 HQhi7hsu07Zv4VbE4nJU9ZhVOO1CP/FCJPxSRHlzWKGfzbtzS+Ctac19aTRe4kUbdjvvD1 vUAGaqrpAwyKykDJzP5KTBVlorCS/U8= Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-38a8b17d7a7so3484212f8f.2 for ; Tue, 25 Feb 2025 13:38:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740519498; x=1741124298; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=fXFKcm0lZuF5OG0aApeKuQOf3+mW6bFB0yCFPCGgwEk=; b=Wx3LZMg+hFpkdb7PR76Ec6whIPfXcf8ZXec2/OH7O/iK4B/EPZ5/sdsgoF+aRMoN5r xB0GrjNF36ls2DVrYLqk9NwqZmcOBJn0IEJZv1vqqk1aaAA3q+pcnX+W31sFarussjAo 76IwRnLt+pT1eYz2DOI1zzsSqL03SByTJZ07TGtA9lQYkmZUBLmKjzdfS+i4G0LL2/N+ 3GLEVvA4C5K2lxwZhmZdtzRl7hEh60wM4FyWNerxX9GI6t9Ipu4e9we83kAt7eij1J7z GkXijS6qZsQ2T+fKL5Ld7vh42IOjDWUr3SsIdPRBNS/TPu00nv5KvzzvSAwyb0/gBs12 8gbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740519498; x=1741124298; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=fXFKcm0lZuF5OG0aApeKuQOf3+mW6bFB0yCFPCGgwEk=; b=W6ppCD5qJ0kEJP6BCF1hxud1n4UHib6ip6eN/73zu66A4n+vfMyOpqO+GUcUwgZP9o 3l8mzYE0XNdqF8GTgVU+oz5jmv5g9HFr1bENUOXE+bIle9d2yAA5oxl4hkurX2TaMOiI X+alvN1psFnZUwnDWr9ySNDLFtbmfZxM3cKjsDDzsX+zrGu5ryICCyTYEL7maweAaa+p +LCl6tNtwGfk+klG5ogF3FDo0r8WJoox3vRBY6RY3lk6tMkx/rnM0IvU1Imjuyw7R2id /+aPxjdpKIwV7qXuLfqqq254VnyjPgU5fn6SUGzJHOnnekNZe7G9z7g+N2cxXZpZw9PG YRYA== X-Forwarded-Encrypted: i=1; AJvYcCXAfldESD6ihV439yk+Gp1OjQswAPDXXT+3ex+GfzRECsjk+fA4KPPHypnxouqiarrxOFxJDnXPfg==@kvack.org X-Gm-Message-State: AOJu0Yyu6XAnJgRLSjsKgmhhPQJjAXO54stb4ppx/TVVnpJqX3rqxkf0 NfTZXyJ0+RHDxHqeoNZdoxJIvP/1/8QNyew1WwUiAmZo1IS/pcg0x105DJDKrM6AX3QhnWUfBsp jM6yamDRqdCVH/l70hscX8nVdh6o= X-Gm-Gg: ASbGnctHiYA/pnfX625SB2CIy0YxeWhBTiMBWGOQUCDksIx97x2TV05sWyR7OnoVu3M SWawt23UED//FxMAxfsXfev5avuO5bxxbBAru2pz69FW2mUM08bT3h7lL3efy/j0MQVIXy6LZRk mGGkoxfrZu X-Google-Smtp-Source: AGHT+IGh8E+lTwkx8iX124FdlLJw2Xy9DPydEazX+qcbmRtx4fMlCbmv7VFo9hwZNeA+xmoTq7Gl/a44OapVymXi8YM= X-Received: by 2002:adf:f003:0:b0:388:da10:ff13 with SMTP id ffacd0b85a97d-390d4f3c491mr589082f8f.21.1740519497503; Tue, 25 Feb 2025 13:38:17 -0800 (PST) MIME-Version: 1.0 References: <168f775c4587f3a1338271390204a9fe16b150dd.1739866028.git.maciej.wieczor-retman@intel.com> <6wdzi5lszeaycdfjjowrbsnniks35zhatavknktskslwop5fne@uv5wzotu4ri4> In-Reply-To: <6wdzi5lszeaycdfjjowrbsnniks35zhatavknktskslwop5fne@uv5wzotu4ri4> From: Andrey Konovalov Date: Tue, 25 Feb 2025 22:38:06 +0100 X-Gm-Features: AWEUYZlodhwAbgPi0Dk16h7YK7x4HrrqY-JVxMx5ByQmdcv8cbnJsNVhi4etBIM Message-ID: Subject: Re: [PATCH v2 01/14] kasan: sw_tags: Use arithmetic shift for shadow computation To: Maciej Wieczor-Retman , Vitaly Buka Cc: kees@kernel.org, julian.stecklina@cyberus-technology.de, kevinloughlin@google.com, peterz@infradead.org, tglx@linutronix.de, justinstitt@google.com, catalin.marinas@arm.com, wangkefeng.wang@huawei.com, bhe@redhat.com, ryabinin.a.a@gmail.com, kirill.shutemov@linux.intel.com, will@kernel.org, ardb@kernel.org, jason.andryuk@amd.com, dave.hansen@linux.intel.com, pasha.tatashin@soleen.com, guoweikang.kernel@gmail.com, dwmw@amazon.co.uk, mark.rutland@arm.com, broonie@kernel.org, apopple@nvidia.com, bp@alien8.de, rppt@kernel.org, kaleshsingh@google.com, richard.weiyang@gmail.com, luto@kernel.org, glider@google.com, pankaj.gupta@amd.com, pawan.kumar.gupta@linux.intel.com, kuan-ying.lee@canonical.com, tony.luck@intel.com, tj@kernel.org, jgross@suse.com, dvyukov@google.com, baohua@kernel.org, samuel.holland@sifive.com, dennis@kernel.org, akpm@linux-foundation.org, thomas.weissschuh@linutronix.de, surenb@google.com, kbingham@kernel.org, ankita@nvidia.com, nathan@kernel.org, ziy@nvidia.com, xin@zytor.com, rafael.j.wysocki@intel.com, andriy.shevchenko@linux.intel.com, cl@linux.com, jhubbard@nvidia.com, hpa@zytor.com, scott@os.amperecomputing.com, david@redhat.com, jan.kiszka@siemens.com, vincenzo.frascino@arm.com, corbet@lwn.net, maz@kernel.org, mingo@redhat.com, arnd@arndb.de, ytcoode@gmail.com, xur@google.com, morbo@google.com, thiago.bauermann@linaro.org, linux-doc@vger.kernel.org, kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org, llvm@lists.linux.dev, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, x86@kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Queue-Id: 0D69180005 X-Stat-Signature: aouompkdf8yqpkxyrd7i3wx3tzs8jciw X-Rspamd-Server: rspam03 X-HE-Tag: 1740519498-492807 X-HE-Meta: U2FsdGVkX19rowS+E3Xkwe8nRe3Tw3jaPlnhMuBe1j7pn6kz6tPS6SLbHJS2uDRNio7VnDfd9GEtP+s+/Mat2S4OUceQqOJ2+eKfWAGm9C73Z6aH4cpTWphXwUvssTzyE/PLuA6Lzl/9KQpnoGrlDvMuD25ncOhqaF6C6iy63ERnqa1gtmJlyATZzRq+gEpYI++sTglv2Z+lB954vommHw8dDVwNQXDIkPypV7IqXBOV8pSbn+tSdR26d5dq8dKZ3sTRQgcB3hSBJ+61TRw4+Tfz99ICvpIf3ltKO65X+mrZXgFkzf81z3h8KuoQ42dRaHrf6uD+P8PFHuOTJV3hhNfEHVVWkkEn5Jz9JKemVWyX3vIfrtk+6ztGWQtflG7s5ZgetXlP57ek9HPi7tQrU+NvvpY9OEqPiyM5LSaYkbf2l5zu7Rl/UwXQFZhKUbuG7X+TBNdYhAQDEP0TSOiDC196Pg2SfcFhTQ5/KDRREC0USRsYLOY0jc8R/aSn92teXKIxSv31A1Dn62r5pWQcAuFIdDignPI/Yb3KGlHSkNSk4gD7srs/pcKJgutDMlFofOsgzGgFrljLsVNkG4M0eBkzFjN6d5P2d6myKCDMsuvGysaHd4/kEQYJOILjCn/688mLeeNIWPgnuVmRgFP25Pp01pEA5GVaJJ+epk08c0lYd6NYrJfVIHt/TqHYq00b7xwcCT4+N87qdgfJIBYabRKJ+V8ObF7PGMHU/U83jhmU9jce8Mb7bGas3U6msmqxM2PEdXn95L6unAwHBJIOU1s/UeLCMrliwJFXWqvqEftT+5H+Z5oYQbTtynEziZ0FRNv5bb5RmfZAPo4FcjPncqHTIG0MSXAGimmo96JFdjIGcOQAto0KKvodp/MZ34WSpyXl4M4cweu4OAhcj7fi4BKP14JnO+mH1CxtEBG0yK8UHXXZoAVfgO9qMSHTwy5fYkl4r/wN7qYgOXCDONK EcCNNuQ8 iJHhxppK63FVY50OwBvVpD41d2JBgr7Ki2XMc2ykS47f96lkYQ8TJHQ5EydxwSkiT+e2cvdeznjqin0kf2DkdA/Z9hJv36CCsBWY6POGmyhNk07w7ZkEaK0vH0yqFhVxb+Vx70lUqr6cWtBCLQjqhF8xvE7HPUsdRrTz1pYRw1z0JCPeJv3xLYnMVxEq2YEqne4YR+tY8844uqTpjKEVLYP0QHD67ha7gttDCxtXlamqCyrp6g16+3F7n3QyOTpjxB+WIKF0eDuGJ4sRt3bFN1yY7KU2AnKyoJ7JDCzH7cwc1LNdlOpNozfJR3cBypRTaiatITi/58yFL2IsPAI+GES6tc3TihMH942udTyvArrWuPuuNGzS7lD24i/Pe1q3tUWEYQcbtqvPK7lWkYZrh03PwdvWnj8l25HjrQH+MdYp+/I5qlAk8lAkEBqlYBWJITPML X-Bogosity: Ham, tests=bogofilter, spamicity=0.000002, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Feb 25, 2025 at 9:13=E2=80=AFPM Maciej Wieczor-Retman wrote: > > >>Thanks for letting me know about the tag resets, that should make chang= ing the > >>check in kasan_non_canonical_hook() easier. > > > >Ah, but the [0xff00000000000000, 0xffffffffffffffff] won't be true for x= 86 > >right? Here the tag reset function only resets bits 60:57. So I presume > >[0x3e00000000000000, 0xffffffffffffffff] would be the range? > > Sorry, brain freeze, I meant [0x1e00000000000000, 0xffffffffffffffff] +Vitaly, who implemented [1] Ah, so when the compiler calculates the shadow memory address on x86, it does | 0x7E (=3D=3D 0x3F << 1) [2] for when CompileKernel =3D=3D true, because LAM uses bits [62:57], I see. What value can bit 63 and take for _valid kernel_ pointers (on which KASAN is intended to operate)? If it is always 1, we could arguably change the compiler to do | 0xFE for CompileKernel. Which would leave us with only one region to check: [0xfe00000000000000, 0xffffffffffffffff]. But I don't know whether changing the compiler makes sense: it technically does as instructed by the LAM spec. (Vitaly, any thoughts? For context: we are discussing how to check whether a pointer can be a result of a memory-to-shadow mapping applied to a potentially invalid pointer in kernel HWASAN.) With the way the compiler works right now, for the perfectly precise check, I think we need to check 2 ranges: [0xfe00000000000000, 0xffffffffffffffff] for when bit 63 is set (of a potentially-invalid pointer to which memory-to-shadow mapping is to be applied) and [0x7e00000000000000, 0x7fffffffffffffff] for when bit 63 is reset. Bit 56 ranges through [0, 1] in both cases. However, in these patches, you use only bits [60:57]. The compiler is not aware of this, so it still sets bits [62:57], and we end up with the same two ranges. But in the KASAN code, you only set bits [60:57], and thus we can end up with 8 potential ranges (2 possible values for each of the top 3 bits), which gets complicated. So checking only one range that covers all of them seems to be reasonable for simplicity even though not entirely precise. And yes, [0x1e00000000000000, 0xffffffffffffffff] looks like the what we need. [1] https://github.com/llvm/llvm-project/commit/cb6099ba43b9262a317083858a2= 9fd31af7efa5c [2] https://github.com/llvm/llvm-project/blob/llvmorg-20-init/llvm/lib/Tran= sforms/Instrumentation/HWAddressSanitizer.cpp#L1259