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 98629C021B8 for ; Wed, 26 Feb 2025 19:44:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E7BB56B0082; Wed, 26 Feb 2025 14:44:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E2A2C6B0085; Wed, 26 Feb 2025 14:44:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CCADA6B0089; Wed, 26 Feb 2025 14:44:51 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id AF8046B0082 for ; Wed, 26 Feb 2025 14:44:51 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id D3EFC1407F1 for ; Wed, 26 Feb 2025 19:44:50 +0000 (UTC) X-FDA: 83163123540.02.5131595 Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) by imf19.hostedemail.com (Postfix) with ESMTP id E76961A0005 for ; Wed, 26 Feb 2025 19:44:48 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="hI3l/wHM"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf19.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.221.53 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740599089; a=rsa-sha256; cv=none; b=VLNayIM3ueiAD3HYONMakqjUT/ReVVOR354hZ9UDiYg2fes7s11wqYap/UefCXlwO73Ron PrMBJ8NBtoCSQXxg1ociWFPVNKYRMdU8cW5uEso1XXxwyey4w3iDRJWcJR0LZcMozPerYK ZVcoYHSs77aPhNqfvMk+h3kaIsNz9KI= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740599089; 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=0ALXJzO2ZhXP82Zb99HSpRWAbbmI+C+3+0buhND8ud8=; b=HGsf78cUOVrr1467KtdlMAjlTREDbDZsnbbe08f8CLSal90a06JhTRmESpVfo+/2EVC24f 07aS7+h3zbYH9I2TMfqp8Bc3UyN31Y7X5+ygo/x4s981QcsvTOsBGheC4brFeapovEywUr kONyEje5fz3btfRLopOyHYCB8vNXwQQ= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="hI3l/wHM"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf19.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.221.53 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-38f29a1a93bso75585f8f.1 for ; Wed, 26 Feb 2025 11:44:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740599087; x=1741203887; 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=0ALXJzO2ZhXP82Zb99HSpRWAbbmI+C+3+0buhND8ud8=; b=hI3l/wHMFxbadY1dnKD4RGMst2rpbLWczEfAVxSCrIlThxna2P+7ETFrUTgk0RNyIz T3BEw18+Pki9VYX1eB60rEZ6BFTKfAIIYDjP76Kqlqy5jqOAEnBm084zKgQUShkk13eT 3OvGoZvCQuZ8qheXMys9soj0bLyFa871ywlSyPRu31QppiSv0xmRzgXSjXWyKxBEXovr qZYS1+s7giXWZwSWBM20vAcxkV8crlGW7QaxwdCrl3gXUNhYK5V3T1zo6JvIrMJlzK2i nkWhMCjd91Au4gWnab5bAVZDxrf12H8cQjvA9J31fRAXfjioavYRDkoH7ZCphBBvHJk7 XOyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740599087; x=1741203887; 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=0ALXJzO2ZhXP82Zb99HSpRWAbbmI+C+3+0buhND8ud8=; b=YQgCzNjQeBXFvvjeIwSg9i5xfAw6kGzurkANRYmYIyu28YhI42t1JI2eDLEjWwy5ce 0Soph5mFoGUy17WtGRVz2lIrKZALR/XQBStvCaC08zBMnE3fmRSMiGafwDB9wcSwdkun ysrPmZ8+VDW7r6Ywh5DI1zXTEbXWn7R5dEcXRZwCiUu3ZwiW1eiLWHfyXbtQSecJmZrs 2BL+iSlEZMVicgfhX1ePGeLYczNILVvg4leIg9bGYHNmUJkM3Pg40JyagbCG3Ovpml2F 4+ZQXVR6Y5UZSBOQuToTixD0PdIQPUVHfax46XZ8XltlRR06ZEMhaqELiO1VMsuj4QQb dIsQ== X-Forwarded-Encrypted: i=1; AJvYcCWQmCAy42zuisKOTKXdNN2wdMM4hVBnY8ujzfX9UdPaznR9QJp6kvDvjD6+lyxD9f/U0sKvPZnylw==@kvack.org X-Gm-Message-State: AOJu0YypH+R9C2FfB5JoHSwbwALl/7kU13CUXQzB2v5hlD0SAbIBA9eg Qf0QJsKaPQ766KzpibrerX/B6t9hplj2k26tmo6DyFc+OXf5iFAMyncO3ncuP1eUxDGRyAKgG6a J0uF78Rr+wAUIId+yT5RGeVDCsgU= X-Gm-Gg: ASbGncsorkFjlZSxg/RDOmkNLQ6rtsCACTvgY0yxNUbFbS084n33zS6XoNy0sdva+dx i1urACiMHbpmbLm4lc6zMTkvi1VCe4TYfGmOTUbKdW4v8aaXvSLTULxQCof5DFocJZ14dB+WGOO ZIxk2MAK5F7w== X-Google-Smtp-Source: AGHT+IHilSXiABFjyw+TG/xRCYQ7cyaP2Rc5n1xYVBGwvzFT0zNXCjxGLoWyBMyb5UlgopzX0CdEgRn+K7Y4/n90qsI= X-Received: by 2002:a05:6000:1848:b0:38d:d5af:29af with SMTP id ffacd0b85a97d-390d4fa3e25mr3522475f8f.49.1740599087190; Wed, 26 Feb 2025 11:44:47 -0800 (PST) MIME-Version: 1.0 References: <168f775c4587f3a1338271390204a9fe16b150dd.1739866028.git.maciej.wieczor-retman@intel.com> <6wdzi5lszeaycdfjjowrbsnniks35zhatavknktskslwop5fne@uv5wzotu4ri4> In-Reply-To: From: Andrey Konovalov Date: Wed, 26 Feb 2025 20:44:35 +0100 X-Gm-Features: AQ5f1JrdMqMC3b0HBepr7R3zwbWYmhOcf6RK7JusOEJWTmRQO7QPte-5YIs-RgA Message-ID: Subject: Re: [PATCH v2 01/14] kasan: sw_tags: Use arithmetic shift for shadow computation To: Maciej Wieczor-Retman Cc: Vitaly Buka , 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-Rspamd-Queue-Id: E76961A0005 X-Rspamd-Server: rspam08 X-Rspam-User: X-Stat-Signature: h765q8aaxdftmx1f87p58pmsxb1945s9 X-HE-Tag: 1740599088-524009 X-HE-Meta: U2FsdGVkX1+mvlZeQ/q47DXF1cHYBSJXXAfSUVu3EMiY0Ui9uI25dAjBzy+jigg6KgYP+FwpkdG0MDyejgmyVRQckW3DRbxf1SqRJ6HUb2/MVgPhVpyPN+PJc/5SdjLBbdlX+ulhGoyZ0gbm0Ees61bQWprNUOtzB7KVfqwl1lgmNdfRJacY3MbvNx0mS03CYSgiFJNg4BACaySfurzpQ7V1PW+jGCAp+7N3EAVVY85JqqY5Od+SDZ0iefIJXWJVCc+MhSNhuJB/7EJer6obmWmwQe4YVH3uGnwDKFdX+Rhrw4R39LbVXGdK3NLZCE0YqP8pBkq+KvD1H5KWCbarshNJJZU8tn6NTsK8FPt3UL2alOjdjmm3x6R5yRO6+ZGAc6/vhox+r3K3uJSZdv/yccA6r7D2bbs55oeUoDuyfLwB+AJ3msfYWI5MMOyqwnnSiKr2G/b7VeCBSY5UX+LEC6ScQ/nAeRzEh8sfZiKBzoRGC4+wjrf2bh7oAM0VsAAw06jM7fFcNWlGeNapTHUc73OEhxPjpu9RHnizLzzWqWBc+gFN54V5/4x2cOYhzWxKDxpMdMfzwAVPzjbZb8sz7PtkOMMfsTqI5SWneyO1gCCzpAD750htDAviCzCw43xO7Im4ThEiTZrGQC+msMkstqR3ZUewAd/+w0IC59ahcLiEg1fnEq4iUeCMrdjlUjwjnFygrMXxiQhF3Rk8kB7nne+AoFVFuZpwYuD3GOGlIVbB9g8Qu3ttdtLcGjVBZt0jwA6Y7ddovrCD08lRsYt4fSDBLVYAWwh8f89kvgFPTZXrlMLb0rKat1mGkgi/p4iZ6hMF33iC0o/t4h5s7LOD/R7oWPBmnSmOviDG8xKmEjFOIFAsJdjvOYRsDm7RlolvPi59kB+o1KqAUJGIVvzDFWLQl/wlOFsPgqlsPhZ3K9hQD4u+DH8BI8X+Hr7jFSfFVDELl50sHd46zX1tAaY JPlO+31i wRVB7JWiyUvvVJUC+2XMD/oienO/syXxIzi4y4L3i+jzAflXllJPQGDnAuvZ65jB0qS+cOYnsVHCCRRVYocmGzBnFxBC3Mi98t+QBklEEQ1kIeTHFEufVBilWdfkinVtnXjVBnWt/AM/cnvbyQLBArXdEN44GA/bRtJt1P05uEQFTSOX0YDQ6SZGUWn9JCiXpfsiQes7fvodHSV3di4sR/0iaS4sJ1vKCcfns0KIt2HFOuhXx8NjSI+OftwZ8//Swby9pmlhGgR11w7hFoUWjTkhnIkQJ9p9KMJrhRoiUrRMO4hLzgSynK15cPP7GehH4Nu0ovuDocjDHeYFBsTzgDS3kJRx5NivgBAqO4KmxtndCrzG6WHWyzChRXpADYiYCT30RZrJ9AU8Tny2J+td607G4NT7mRmonl51uSrxGGJtt/e2KWPxowf3dLhGurDJiUILkB/QqbdV6TPs= 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: On Wed, Feb 26, 2025 at 5:43=E2=80=AFPM Maciej Wieczor-Retman wrote: > > >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 LAM, valid pointers need to have bits 63 and 56 equal for 5 level pa= ging > and bits 63 and 47 equal for 4 level paging. Both set for kernel addresse= s and > both clear for user addresses. Ah, OK. Then I guess we could even change to compiler to do | 0xFF, same as arm. But I don't know if this makes sense. > >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. > > Aren't the 2 ranges you mentioned in the previous paragraph still valid, = no > matter what bits the __tag_set() function uses? I mean bits 62:57 are sti= ll > reset by the compiler so bits 62:61 still won't matter. For example addre= sses > 0x1e00000000000000 and 0x3e00000000000000 will resolve to the same thing = after > the compiler is done with them right? Ah, yes, you're right, it's the same 2 ranges. I was thinking about the outline instrumentation mode, where the shadow address would be calculated based on resetting only bits [60:57]. But then there we have a addr_has_metadata() check in kasan_check_range(), so KASAN should not try to deference a bad shadow address and thus should not reach kasan_non_canonical_hook() anyway.