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 A4DD3C021B2 for ; Sat, 22 Feb 2025 15:06:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BEABB6B0089; Sat, 22 Feb 2025 10:06:17 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B9A636B008A; Sat, 22 Feb 2025 10:06:17 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A3A936B008C; Sat, 22 Feb 2025 10:06:17 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 85CA56B0089 for ; Sat, 22 Feb 2025 10:06:17 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 109FEC16BD for ; Sat, 22 Feb 2025 15:06:17 +0000 (UTC) X-FDA: 83147906394.16.42C611F Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) by imf10.hostedemail.com (Postfix) with ESMTP id E13CCC001B for ; Sat, 22 Feb 2025 15:06:14 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=jIYxqGyL; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf10.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.128.50 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740236775; a=rsa-sha256; cv=none; b=vwDD4jNQu4xNkAqe4iAuOSXg6eOfyzKEy/ayvInrSPt4FNHOYwU52SyeSvui19ghT1E3G5 IqQ7PN77PADYkRpWUsXHVK0+ZbCh4qO3Mho4pf3vBdItcrQrpmjPZrlt2RSE0ipswxpEus HSIwwfpYZQbXLYzukE3htU/k6p3KQiE= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=jIYxqGyL; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf10.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.128.50 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740236775; 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=nzMYHvrv9HpWCutgVpnHfFN6zecH/fwJ8xUtPbSALWo=; b=3sipLGCM0SoWdUBKl6B0OpS1ymIcf1fVgxXozxT62LBVf1+k4J+86VeapzMm6v3mID5+WH b2K95nOzI1BVsJbJXJ+uWr5XdtiGVw/KjmQSxCxPJ+H1VplgXieIcUxf+D4mv+nx9P5JdY tSOv6en8rZcFeLQ8zenHUiNL+zvtXyc= Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-4394036c0efso19081745e9.2 for ; Sat, 22 Feb 2025 07:06:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740236773; x=1740841573; 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=nzMYHvrv9HpWCutgVpnHfFN6zecH/fwJ8xUtPbSALWo=; b=jIYxqGyL53ich0/jCeS7H4HbUVCveFxV3CEapq1nEjeRPMahgfJTEuISuNWa/F//Aq 1ykAKxPh+CPhlpzD2poVudYOqRiHOK7Y7E4RdTH8KSkOyiIjtPod/gpqa+Bd5FmJan+l kaxmS9FzeOz1+ZMu2LBHEvvDJ18hNZjOSzRmerpcLQJF8ejxTPfhvljSoGP1D+1KlxPO x3gU4mH2rh5MMWojshDUfQCdV4+HH6rFq9AvRDLCMg6iBas6VOAGUjyeKwcxP8fWswm/ 9/S6ANiPbm21XBVNvroyjwGydweQhlzwmmGhsMJR2oUNmBOfAL0J47085/ceSvgJMvYl S19A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740236773; x=1740841573; 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=nzMYHvrv9HpWCutgVpnHfFN6zecH/fwJ8xUtPbSALWo=; b=S/BUl4X15ZYIm6gMH538ecCZul57YgsoDTr6Z2nz80ffX5PJkmDy6m7T4LDFb5gVzm WVttPq4hrv/VSctwSY+0ZCj6B/SRtd5ji80wcuVWcpNPru8O9iDDe+x9NX4mjspaOnPw vgYw4HEWb2vsEpaUHWuglLam/FrjSRj/o1/vxnbi+RhRi34xP5ro9PzJAdJ7C0qflqT2 zqKzxt238wYyU0PRVt2dzMjYPZAF+s9pLAan1Cc9WtQ1ItnDpvpYgdMRKnlwXZ8Iv+ee ulILmxoEQCglveawf35Hc5H5PTL5NpgOZKoL/d6vsoWvvNJsse7NHS9mYXrqk0aw0FWS ZuvQ== X-Forwarded-Encrypted: i=1; AJvYcCVyNqhowItFBiy9iVHursDqjnti7bo97eWLBW37zfjcobcJ+lo1p/vrMTlQcjkvP3F8OjV8KlTgkg==@kvack.org X-Gm-Message-State: AOJu0Yy/g+SLaLhysJ2etO4dUjJ/Os3MEsNNTKk1uedSiD8rVHKQoIl+ BJCBz3/7lxhF69Kb43Mbe4sow2gNpdOtt/v4EiDoI2vBj/27ORjudSXlZq3zW+SDbucxcPVuWsc 74qJowfO2DbSVhfGm6glDITlWrfs= X-Gm-Gg: ASbGncu2CW10cYttVo6knhrumodXOWUu4PH5fBH2qqtTxYRTpmQ25Tjq3iLbG7HFgJA YG/3tNBXuNDRgyXyyiZdfN7rdtGEyTWi0ERo0wRiEd7+bkIplERe7oHM4MnIBlVIg3HhhQ+BQX4 Q+E/wwGV8bxQ== X-Google-Smtp-Source: AGHT+IG/5hYYNb7GJKzFAMA7qjQhD/2iJUv73XgnGmsxKtIVrNPOjotGccdz0pvGUzM8NDCVmC/Tnjv7k33iBVxJx6Y= X-Received: by 2002:a05:600c:4f84:b0:439:955d:7ad9 with SMTP id 5b1f17b1804b1-439ae1f145cmr75369895e9.14.1740236772914; Sat, 22 Feb 2025 07:06:12 -0800 (PST) MIME-Version: 1.0 References: <168f775c4587f3a1338271390204a9fe16b150dd.1739866028.git.maciej.wieczor-retman@intel.com> In-Reply-To: From: Andrey Konovalov Date: Sat, 22 Feb 2025 16:06:02 +0100 X-Gm-Features: AWEUYZnFqlAhlbFhk_9-WAra7TCYMXPYd8CyySx1oX6HAXsK_aRCuDKHtzc0hoo Message-ID: Subject: Re: [PATCH v2 01/14] kasan: sw_tags: Use arithmetic shift for shadow computation 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, 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: E13CCC001B X-Rspamd-Server: rspam12 X-Stat-Signature: kqeb1pwkorkk565juqif11bptoz6yyeq X-HE-Tag: 1740236774-974570 X-HE-Meta: U2FsdGVkX1/6azIXmRL50jjQA+UHYazcmPfmJKiCDHK4el2WKJkmRPVjPffhfE5v4QJmzTaZDGM8/eWMuGnGb3RJbNAgNoAL97l5avawgk+vwMN53hwlWIubFoOfuqUtm/35iC9XOKYoFwcizJ59TTyfKj7UeYrv9NjLm6/iZyj49iy/OW3xSLdtTSBuqoOaGbVpVKf8XmxklmdDDOT86y1SWKWmr3zudba2/Xg8McvU3DVCejBiKFc7Qgtiss1NItFBl2FnSFLJIoU0Yn74Mxef1K8tzOgghuaABLKKVQHi507rdpbn4tB5wR+N4P0kOF5Yfw4W0/ZHi946YRYubLL76Hv1mYUSSWIIyFt/Nu2Zev18CTKSnVqj9JBhohG3n5d2EQZyRyyw7fr7luP6+udKZSL4ltiJucfPcc6/Qyhl/2r2egK0ecfOQLAaB2fS6vzNdUYzRNZiPuKlqNGpMxfPxuY3vPn/TM9SXnWmhTuDj3u15dMYI/iPJ49MLruoq5iFQrwNg4Lll4n/BafsHUuFvtVuK/5fKVP94oO1xuVrfbkjOkqlcYmNmfAIZ35OGSMsr94NS2OAsHAX9j6WSDdSOLV82qHlzokpncFZdEpnfyReFGGTgaKEDSy7ycFKCXrd3qqyPEFlB1AnVqje2Tks656NPQ3TOxAD8ABEg2uDBuPY5kRupmF9WCP2EauRD96bBeTN0M2ZeGHn6jzBZ8LqF6gVP13xjinoldhrm7PtNMF07PhANWs2bxHUQq0zgxvEcEvTaFRnSA6Kr4UG4VP3dciijL7DV1w/LFvQYWJ5lAwe8YCWga6Tj5d2P9685Sy3imSIY+yruhj9t8XEn0iLGkL8g+9OiRCJGTC9fZ6IJ2mXrrLt+Y1gKcYZMiaed1chitEXvYzeA9TJAmti4uz2cC0QtA+J8fcf5GAvQq/vj8rAKQhFyg53XRWU9JrF942I2rnLfadjkAPu420 E1XM4nsW OQc27FNdrqCoOwlHToIGYBEE/Qh0fPlom+hJJjEBEoFgWcirjtFFKmsmMplZ05aQVGZeXVbeOtfbKAiGp+yFAMRm+xVYttDnYAHkDzi77Ck5OElyPPuOy062DUcQ/ZKpjxmOfFBsQJvqeyFv3D0pqPqPE/qJyFU/jX5stHuKKx+XY3Wnjw57pkI3mqyLPaeSgtG+DN5OzyYGF83fqivn8xIqZMCmuELhWqT34JJVFfwdgvgOkdnYEqDkj8qoWe5hPlEvmmxu91JTotWNT1pnhEJUWFlXiQqEoelUiTjhoOfP9cwF54vhFlH2BR8RMJRmGHfijwKcwP+I6cJbrDzGK4IbjsVLXmTu2E7wtU5sB4b2LkgJhmTr6lxea8m2JW6HP1o99vnucpc04pfKRRzSrLd/ElUfiIf0H0XkRUdECakMWX8rzFGNx3xKBZ+2KouhoZnHF6Aupy9HN2P6jfUHguKh96DWkA1FJ089Lh7miJh+30Yg= X-Bogosity: Ham, tests=bogofilter, spamicity=0.112760, 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 Fri, Feb 21, 2025 at 2:12=E2=80=AFPM Maciej Wieczor-Retman wrote: > > >Is there any reason we need this change for x86 SW_TAGS besides the > >optimization benefits? > > I wanted to have the shadow memory boundries aligned properly, to not was= te page > table entries, so the memory map is more straight forward. This patch hel= ps with > that, I don't think it would have worked without it. Ok, I see - let's add this info into the commit message then. > >However, I just realized that this check is not entirely precise. When > >doing the memory-to-shadow mapping, the memory address always has its > >top byte set to 0xff: both the inlined compiler code and the outline > >KASAN code do this > > Do you mean that non-canonical addresses passed to kasan_mem_to_shadow() = will > map to the same space that the canonical version would map to? No, but non-canonical address are never passed to kasan_mem_to_shadow(): KASAN always resets the tag before calling this function. > What does that? Does the compiler do something more than is in > kasan_mem_to_shadow() when instrumenting functions? Same for the compiler, it always untags the pointer first [1]. [1] https://github.com/llvm/llvm-project/blob/llvmorg-20-init/llvm/lib/Tran= sforms/Instrumentation/HWAddressSanitizer.cpp#L922 > > Thus, the possible values a shadow address can > >take are the result of the memory-to-shadow mapping applied to > >[0xff00000000000000, 0xffffffffffffffff], not to the whole address > >space. So we can make this check more precise. > > In case my question above didn't lead to this: what happens to the rest o= f the > values if they get plugged into kasan_mem_to_shadow()? We will get some invalid addresses. But this should never happen in the first place.