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 A509BC021B8 for ; Tue, 25 Feb 2025 21:37:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0F911280008; Tue, 25 Feb 2025 16:37:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0A989280003; Tue, 25 Feb 2025 16:37:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E3DC0280008; Tue, 25 Feb 2025 16:37:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id C12C7280003 for ; Tue, 25 Feb 2025 16:37:52 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 3C078C039E for ; Tue, 25 Feb 2025 21:37:52 +0000 (UTC) X-FDA: 83159779584.26.3B4234A Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) by imf08.hostedemail.com (Postfix) with ESMTP id 4BA5D160006 for ; Tue, 25 Feb 2025 21:37:50 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=GNQTDVXU; spf=pass (imf08.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.221.44 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=1740519470; a=rsa-sha256; cv=none; b=OxYUHbLcaM1IgEcUtpTIkJmYCAJPZCssPCweqX9M1lJmlLDGsmPoYmsvfJOdb4RSA3z2SC B0pilHZzLf1fjFewi/VpLhfAgMHn52ivYGiX365AIEoHBvRGpIlCNiucdQM1WujdmILaV7 aOknrW1YIggG2xs0ZrVV06RjxUbdcac= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=GNQTDVXU; spf=pass (imf08.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.221.44 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=1740519470; 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=9QCyp1JUlv9qVfn+zUKpBjTnHTrPkzYz/kl8dlHJcy0=; b=JqEt/YJjMfuSp+cFQCEgmxCad6sHM+tHzzlqbuq+8LDrMSdO7xYbijjGNVlmgZlk7ckDbb 58PAFr0KC4UWF0PWe4xB5pBax5r9gnzuKLCrzbicGhC0Y1XfdlclfXO8lYvu2DqEX62doC DcEED1F2JS2Ps3zT7Sn9X42mwujZ7p0= Received: by mail-wr1-f44.google.com with SMTP id ffacd0b85a97d-38f488f3161so3373889f8f.3 for ; Tue, 25 Feb 2025 13:37:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740519469; x=1741124269; 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=9QCyp1JUlv9qVfn+zUKpBjTnHTrPkzYz/kl8dlHJcy0=; b=GNQTDVXUNAGsU29LFxBze5k1rhwSyR0uYr+zy+79Buf46MO4/6mHpH2frNLsbbDYS4 QHEIhLjYouJqH/b5xztrkonDIWMfxK+6kc2Y0F4J1Brz/6lcwPe0GVcGc8atAu4kNtNs qhwN+BrmecHb44Sgm3mIudYdv8F9PNt2PhiUc9UUGVR8452fgvn5IpuHfZgwibWMmddi 4ameHTRMhoMxxTCpL7B8CKxhg+eqyIn1TFLDkOAihPZR24T32HTCYkrpy+gC7paqwh1T aPt5cvkjZepk+KIoVZhvYMys1t/HixBXLSsEZCrd0Y2UTX+eUZu8lupN3I0himyV/gih 6J4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740519469; x=1741124269; 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=9QCyp1JUlv9qVfn+zUKpBjTnHTrPkzYz/kl8dlHJcy0=; b=W+hzh8XIcnDXC9pjfjo3pt4Tp6L9yfSmHM38zGJwZ0qhIqGvJBqHVivsldON9sfwep hz8aqlEUYgmppByBF1zWUq3V2hhflCt9kmvLhAEgkMNaS34dT7bBzxlVXcrWOpof8Qhh fnGaRJGw4gvW+zFWSRGYLgz//FS/TeprvP5c0+zsDmJ21eCVS4X970MxKUvMgexwRak1 lJv8f+wiODSzBVz4rsKLSK5Lpmwvr4omevjxBDCaxR+pV08BOIW0Sj0QymYNtoC9JwUT 8O1feKyYHc4THz9eFhsnowYl2AAkN1x32kAlCBmjnqJ49VRcC52nZzTDhPr7DnfAvr6m F1Pg== X-Forwarded-Encrypted: i=1; AJvYcCWCUJwF2kzP8Q9jMSu09q1o+yTwlyjF9Reb01S0F3+f8V179Ckc7H60tlN3ud4mf5IWvYuC4cubQg==@kvack.org X-Gm-Message-State: AOJu0YzLhmw2KPpA/4wzOnNmVf+VfobrJkA6OgIiRlKRj8HEBqsJukMV bDgk8ka7ZQbvs7TI6a47lKYlCJMzxoTVUnxLj7+D2HxRaYw4xUIpMq8P5VNPDC47OfStxb0HBgy /umjfJ4SrGe8GxHN4fab/wEr5lA0= X-Gm-Gg: ASbGnctNFILoFo2xSCcxSfhHeqT3Au4qhN0pzZSrc9ja8Pto3lA/cwYwIbwSATQ233G CaIYW+CUv+vkdHsa+llghEDvTUkgN6k9ls78/mpzpuuhHJ9v2CqGfnY4pc8p6PC0jLkUEFE75ND 1L9s/rps65 X-Google-Smtp-Source: AGHT+IH6S2mULqjQWrRVzKEgduMFAsvTkEdFQj+0CWyfGyaXp1XuShoVeKk5ny9pZxUEWkF4gZEny+EdppWtMZZUjmk= X-Received: by 2002:a5d:588d:0:b0:390:d5f1:de9f with SMTP id ffacd0b85a97d-390d5f1e3dcmr106316f8f.18.1740519468347; Tue, 25 Feb 2025 13:37:48 -0800 (PST) MIME-Version: 1.0 References: <2a2f08bc8118b369610d34e4d190a879d44f76b8.1739866028.git.maciej.wieczor-retman@intel.com> In-Reply-To: From: Andrey Konovalov Date: Tue, 25 Feb 2025 22:37:37 +0100 X-Gm-Features: AWEUYZnhs_dCGf3N8iOL4s8huRdd6HbG8f2NLaDJFhsXr34i64LAvkBz9QgjSAQ Message-ID: Subject: Re: [PATCH v2 13/14] x86: runtime_const used for KASAN_SHADOW_END To: Maciej Wieczor-Retman 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, ndesaulniers@google.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: 4BA5D160006 X-Stat-Signature: 5noq7jefc5o7zmy8ci974rwmg73dtwm8 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1740519470-666801 X-HE-Meta: U2FsdGVkX1/zZWCEwm1Cmb+oj3IoBhyCXy/Ec1TZVXowBaK3pF2PZ71PmlCiJoPHz3dtd8Z5i8XKl+Igdap+l1imZ0JmuNMEhTvdnl11CMCNcvMw7jxqFNqruPgdg5IAPezv+WcNU0A5oW6JbVtVP8lBnhDXQV+2ad2vL4/kHphv3KaeW/k45Z3SyrxFHKpVDLdNCMmzkvrZEubZkWdLelGGTmn2fc89pUbAiXR+URRjczA1OcYleq1/NCQlsFh0Smo6fjjgNfybgUmLNkQs5pmH7vb4DFwzfobgbXjKwimlD0KPDRoW9byZm5jiIvq4+l0DTX0G+Bjm8IdRbw/M4zfcO2/YuwPwCIYRUOeraZe+MIkAd46TR+Fi8lKfWhRNvAg086/OKfUAMJ6Cmlig5/USbU+hPkvHfKG9Zlj1VOqTibvLzFelDwUIFOEjz2PefoiveAYCvvpun1uwYWl8WldP7xjpbboSWQzvdiQ9Q9XbixKkh4+4ADUQxoL+JtSDg+aZdn04ymofK0G99n/ecsofktjHV90N0oMzFYYdmoSlxDGDgYobkk3v91KW2ndk19RvkvnpK6gtXuw1dAsi0FigL3IiE8cEJxlXRE8uyuleCC/49+I1nzbLtBkwYMoJqT2mEKsAUrYfMhLNUmI9CGSekZwCb/wYJtw5xCuZExMU3IKLinRgFB/DQuanXr4lS+Ktg2GK5I+fHDOgpbARi1FOzledx5e/oK0cCGZO4C6vHZzMiYbLmBnlV1O3vqxsReQHPHeJPwp5FCZ7ZEvA22xci59QEOlP4nFNGLrLiKRdXJDjBqnmbunoysqjkQCAfzlVaNZ0qycBjX7bQ53566AOqoEk64t5qAMzfPuAdQnKmP1FwLCpQ6onqy/il5M9bbtGhuln+a3s3/lejY6eYCTpWCbb8eLWlyVTPAVzc6x2gvr3QW8xD94iJcyp+SryLxx7ETxnRvmFzVtDMhl e+OOH78K EQF2YoovsEKf5B8w9HNe/Mi/aJnzQ/N/fynPYbq8md5fTVVEUSOF9PTLMbS0060cqEvNWpPWuytPOZ0h/iagetHvSzL6OzbQ+Ki+gCjwMASCe/Xeuz95P6o4eP2aBv7Gt23bZHj4ppDJ7fORGRTkFonaRW6H8fwkvTEbtCt2jr2t4ERfba6wxs71W+6MRnhFD1Z7D56rGumv+CJf8Zoyu5Jq49K7zAuLnO/T27uetABR/u7s35WcmJur+u+gD9cU9tginP0TqvCMXy/pgClkeKKVjzIldENYEdcI/J64b8u66Y+qTHtkYqJqqZX3Q4j/lU45GHYBuSIY9P3nOMgH0vrFtOuCcWaVtIA0xHGXFjxYOWABJHDEc4EgtTY4reoKD0Ox7CIThWV4wWbnAKfBHHAlMu1kMyzosYBnPtRzlNdlHmsYNbDa0Gc+ip7SIuugM/b2wKWRG24mJ408+AkDqlHuait7S2PNoKv7HkDswA2VDt1+k9taDLTzLbA== 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 Tue, Feb 25, 2025 at 6:16=E2=80=AFPM Maciej Wieczor-Retman wrote: > > I mean in my tests, with setting offset in runtime, everything works corr= ectly > in inline mode. Even though hwasan-mapping-offset ends up empty and doesn= 't end > up in CFLAGS_KASAN. I assume this means that the inline mode is pretty mu= ch the > same as outline mode with the runtime offset setting? > > I also tested if hwasan-mapping-offset does anything if I passed random v= alues > to it by hardcoding them in the makefile and still everything seemed to w= ork > just fine. Therefore I assumed that this option doesn't have any effect o= n x86. Hm that's weird. I wonder if inline instrumentation somehow gets auto-disab= led. > Hmm indeed it does. Then I'm not sure why I didn't crash when I started p= utting > in random variables. I'll dive into assembly and see what's up in there. Please do, I'm curious what's going on there. > But anyway I have an idea how to setup the x86 offset for tag-based mode = so it > works for both paging modes. I did some testing and value > 0xffeffc0000000000 > seems to work fine and has at least some of the benefits I was hoping for= when > doing the runtime_const thing. It works in both paging modes because in 5= levels > it's just a little bit below the 0xffe0000000000000 that I was thinking a= bout > first and in 4 levels, because of LAM, it becomes 0xfffffc0000000000 (bec= ause in > 4 level paging bits 62:48 are masked from address translation. So it's th= e same > as the end of generic mode shadow memory space. > > The alignment doesn't fit the shadow memory size so it's not optimal but = I'm not > sure it can be if we want to have the inline mode and python scripts work= ing at > the same time. At the very least I think the KASAN_SHADOW_END won't colli= de with > other things in the tab-based mode in 5 level paging mode, so no extra st= eps are > needed (arch/x86/mm/kasan_init_64.c in kasan_init()). What do you mean by "The alignment doesn't fit the shadow memory size"? > Do you see any problems with this offset for x86 tag-based mode? I don't, but I think someone who understands the x86 memory layout better needs to look at this. > Btw I think kasan_check_range() can be optimized on x86 if we use > addr_has_metadata() that doesn't use KASAN_SHADOW_START. Getting rid of i= t from > the implementation will remove pgtable_l5_enabled() which is pretty slow = so > kasan_check_range() which is called a lot would probably work much faster= . > Do you see any way in which addr_has_metadata() will make sense but won't= use > KASAN_SHADOW_START? Every one of my ideas ends up using pgtable_l5_enable= d() > because the metadata can have 6 or 15 bits depending on paging level. What if we turn pgtable_l5_enabled() into using a read-only static key (DEFINE_STATIC_KEY_FALSE_RO) instead of a bool variable? Or if that is not acceptable, we could cache its value in a KASAN-specific static key.