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 A83F5C02198 for ; Thu, 13 Feb 2025 01:21:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1DF016B0085; Wed, 12 Feb 2025 20:21:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1685E6B0088; Wed, 12 Feb 2025 20:21:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F23616B0089; Wed, 12 Feb 2025 20:21:48 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id D48956B0085 for ; Wed, 12 Feb 2025 20:21:48 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 6B17F1415B2 for ; Thu, 13 Feb 2025 01:21:48 +0000 (UTC) X-FDA: 83113169496.25.7B6D667 Received: from mail-wm1-f41.google.com (mail-wm1-f41.google.com [209.85.128.41]) by imf26.hostedemail.com (Postfix) with ESMTP id 85686140002 for ; Thu, 13 Feb 2025 01:21:46 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=PjsNAYiS; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf26.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.128.41 as permitted sender) smtp.mailfrom=andreyknvl@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739409706; a=rsa-sha256; cv=none; b=LLJnsivFkKwdtBIOxEWIxEEkjlsSM+8VqQgMO7G8C4xdGjEbGN48riMNTCOIh+aL0QDoLf xt0jpy82KdbpM4KZgZ1Vxpw4OBB90uhq36p15lSdKs6klrK50Cf64bnc9Pf+V/ba/XXdQR o2s05J/p7iiSpRve0vGKkimaiHA4hmo= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=PjsNAYiS; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf26.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.128.41 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=1739409706; 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=q+nCXvcuGbP6lZuLocKajT0ORe5EGrF6T3/N8VpC8fs=; b=o/SrjQtlyo5x51DcvSidqxkdfqHMs3vvq0uW8h8Wcyv/aZq+Nm59jSAZjpvvmgD0wqo3jX 96iu8j69C0Ncc0zGcfymRbinKhIolQIHq0Iu5vZ1Y1fU68xttNhCj3qs8j+9+T7qoGBikx Bc44MtRy/fCIILTut98eiQgUyn3Uhlc= Received: by mail-wm1-f41.google.com with SMTP id 5b1f17b1804b1-4394036c0efso1991535e9.2 for ; Wed, 12 Feb 2025 17:21:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1739409705; x=1740014505; 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=q+nCXvcuGbP6lZuLocKajT0ORe5EGrF6T3/N8VpC8fs=; b=PjsNAYiSRYO2G9pOJIXsu28XVmz4c7rLSm/if5fen0dTdNv8lKO0jVHm5gqsxXl5YK wBtIz/9V1m8x0qfUv8Aeafz0WtaiPXACN5bm9MmiKNg2PJpKYoSaruPsu+OR8L4znmao 3wMkmEzAO22EJM50UdTMolQg1tdpQ4rsOaXJsAtsYwYSTWJ10/Dia3M8amEn5/CL2gG8 3Ytse+3tZ1VYL11HUsWhtLTGn8hOx/SeNtUcZQR7UwajgLdJjFlyDWfOQ/qF0oLOUcVC zPTdMXXR8y7KKMc60aDmPhofXpJMEfZJsMbTAe4pb7eHekHBe7Tx7lzPOv2WG02bnfns QxPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739409705; x=1740014505; 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=q+nCXvcuGbP6lZuLocKajT0ORe5EGrF6T3/N8VpC8fs=; b=pfPPcHFc3IOxNhGLgmhL/50BSqwsdOCPJTMqQUYDfYkA24jBGTpfznvKtHoczWWyzL 0HQNS4lLpVQaiqnPolilVNRtlemfRgQHarzCQJ/3LNg+uXUoDCcjVCuP6b+c62Y6YhSS etTC78k5BFKUDE7VwIlWL5xBn5SLw3r2aoifRIVzyolOciyyMw/VKlI+8pKgKBg95wy+ GA9H53eTwl4fResxfcwIFWemKDoNWyQnLDopViWTdgQElpt26W92InwiiTPQxi+0AYvU YLIlG8iuSnZCGdA/4atGGi0fQRfRFgMbBFacv+xLnOObp3zisrMqYVcKu0BLeQ/J2oGG Qh5Q== X-Forwarded-Encrypted: i=1; AJvYcCVxR/2ImsUvIeOtp4901XK9TxUPG6HonRCh1Z8TsfIUeCM5l0csGCaY0TtFCHbYZbA1PG498Ms6jg==@kvack.org X-Gm-Message-State: AOJu0YxlZKXeNk+/mAKxviHEIHErU164syyxK4jaP2KlpphB7NLpPorA rT85HqEfEpHI2Hwi+ML9t2boeRye0Sngbz7TKmHhZdCN9SxsiAx250RfaeoFJEhgMcKROCED1G1 gndXOJ/3e1Cf3JZZtEGLdPA0jwio= X-Gm-Gg: ASbGncu9O3WskBCtV35g3cyzrPunKX7yfa6xWE3ioOtx4tsK/8TB/Z+n8NinFDzWJSk DXn0fQosnj8ZvfJaOgPqCgc3vDz/pCZh5QuZg0RfYImooYAGpIXJLOTgKv+2meLrZnddDQ95R/G Q= X-Google-Smtp-Source: AGHT+IEjJMkC/hHaotdqSukhMJQZrOiaCkGtVrbEkJiI15zjYiRvHohJ4FkUwvWx7PY95qrg/tcG6HP5nsDWETkesBs= X-Received: by 2002:a05:600c:198b:b0:439:60bc:71b3 with SMTP id 5b1f17b1804b1-43960bc744emr6893225e9.25.1739409704648; Wed, 12 Feb 2025 17:21:44 -0800 (PST) MIME-Version: 1.0 References: <20241022015913.3524425-1-samuel.holland@sifive.com> <20241022015913.3524425-2-samuel.holland@sifive.com> In-Reply-To: From: Andrey Konovalov Date: Thu, 13 Feb 2025 02:21:33 +0100 X-Gm-Features: AWEUYZnQToSGphLmBmZFBpfuiZIg1iWlon9vHp3PXB7Fk9evMSAokOcZX5tZFRE Message-ID: Subject: Re: [PATCH v2 1/9] kasan: sw_tags: Use arithmetic shift for shadow computation To: Maciej Wieczor-Retman Cc: Samuel Holland , Palmer Dabbelt , linux-riscv@lists.infradead.org, Andrey Ryabinin , Alexander Potapenko , Dmitry Vyukov , Vincenzo Frascino , kasan-dev@googlegroups.com, llvm@lists.linux.dev, Catalin Marinas , linux-kernel@vger.kernel.org, linux-mm@kvack.org, Alexandre Ghiti , Will Deacon , Evgenii Stepanov , Andrew Morton , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 85686140002 X-Stat-Signature: og73yzioeiqh1f3mopehtiyfk4w6q3r6 X-Rspam-User: X-HE-Tag: 1739409706-262137 X-HE-Meta: U2FsdGVkX19a+gWVE5Kkgh0VPniBFbl56/keq3bFVmMdRw/vjCES3wGSMTXCAiq+5XLoMATK7/DzuzWdDB17JWI7RFukWOQVNQg7bW13/h0MOG6MvGilRQH7EIgxM/wJ1YL6prg2tXYAM37ZMNH9KObKLqCm82uaZlDtCXvijsxCok5j2Z6oDAorFzHuXKbpgAskoy/y/ArqqJMhzKOHmvKHYjxgr6qLZ42CQ7FxZ/k/23IoyAmfKW9JqrvfRAcuWsJxkkQTUyWY329AAQTrBb69Uh53XvreXg+AZD3mCzLonhx0f3ewAXhHqb5kVM5jU26RVSpV93yqyDAURiQ7ERc7YwJpLg1fRpfd7cs7d4ta1j4gPWTcDSNoVQpSEP7TPKAycBrglTjxIzaJzXxbyQEn18/ZHCZcBxebFLX3NQ6fEheijxhAs1KgNKwDUIRa283iYD1VvoIhBKgy8FhXWXo/kodf+NT9NzGcCOtLGCr4xjx/JIhIN4zzqa956r5hTT5IojNWeORGblq7mtiqE/sO7HzcyRENXLxt6WOXIFL6gfuo4uK/rS3pi/YAhG6kb2SmJxVjx9gt72f9yoH+PEv588/Bl8upRni97K4qOsmPid+0CX8/0GS39GvH/9dtiW5qqel96O9nWsamAdfPOa03PpepBdrhXXp6qFL/vqMXLl5r/81RYhUa/kRqKd2CZW6/h3gyglWcnJfJgwPDkqTLE6TRRMMEW1REOqyPa3WQyTCbPADaroEAlMC+1TVwduXuFIFP50Ruz7se4O6/5SjzZefalMnmoHcHr/fI1nugkejY/Oea1BCi+jTksgeI3LFTMDNKez4vn7RDNTQmG6lN52e6eFI8Fk4PvKfrpDeb/bqsJBfydpIN7O4HGdIiLbH7s9UZP8mS5GSERnZ2c/dvb4/pLc2XFpOw8DojAxd1JII28IFcAB0lh0CNqf/aHMR4K6amuGiFCsU+m1O B1CTmViJ s4a0FZBMLg8plROQadgx2PmmCWyTK0Fo5fhOEdHwbzfy27KVx/KF99cFiHA5jk8fLlYD8B4j42MVWphurtH5fpdLdUjBvkeib1CTpRcw4kkL1CziF9IrHLvz9kKaPtkHZMLSAdwdvnSGMQ7uwjf9F5Hne24zKiNVSuU3DPhGYNErG3ZoYJoUH6YxcO2BBDBrx/6ldBp77jWy0dhme1A6daN/dPUzRIyLNvSaYQU8/cJGCuvgpsF9fySOr3fOwfLlW2m9Zb50x2kQupgTXtLffVbbD9uHKON5wSv/m2TepJrFgGCRB2Tp5qH3y92kpXf99qxuF2J8F9xERmOZNCt3pXXJ0rch1oMBTFbbA1nZElXzV/LOgGQLjPvRl1bDtkkIcC2J7plK+pqQiLr6JUrwn5KKROJJ5HEKlBfYs0LCtS9LIzk1JeLfTnM+LXO7ULZR4hH/TxzYOhFwALij1hgbKvPb5kY6ZN0M/r8V3/lRBQ2JWuqM= 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 11, 2025 at 7:07=E2=80=AFPM Maciej Wieczor-Retman wrote: > > I did some experiments with multiple addresses passed through > kasan_mem_to_shadow(). And it seems like we can get almost any address ou= t when > we consider any random bogus pointers. > > I used the KASAN_SHADOW_OFFSET from your example above. Userspace address= es seem > to map to the range [KASAN_SHADOW_OFFSET - 0xffff8fffffffffff]. Then goin= g > through non-canonical addresses until 0x0007ffffffffffff we reach the end= of > kernel LA and we loop around. Then the addresses seem to go from 0 until = we > again start reaching the kernel space and then it maps into the proper sh= adow > memory. > > It gave me the same results when using the previous version of > kasan_mem_to_shadow() so I'm wondering whether I'm doing this experiment > incorrectly or if there aren't any addresses we can rule out here? By the definition of the shadow mapping, if we apply that mapping to the whole 64-bit address space, the result will only contain 1/8th (1/16th for SW/HW_TAGS) of that space. For example, with the current upstream value of KASAN_SHADOW_OFFSET on x86 and arm64, the value of the top 3 bits (4 for SW/HW_TAGS) of any shadow address are always the same: KASAN_SHADOW_OFFSET's value is such that the shadow address calculation never overflows. Addresses that have a different value for those top 3 bits are the once we can rule out. The KASAN_SHADOW_OFFSET value from my example does rely on the overflow (arguably, this makes things more confusing [1]). But still, the possible values of shadow addresses should only cover 1/16th of the address space. So whether the address belongs to that 1/8th (1/16th) of the address space is what we want to check in kasan_non_canonical_hook(). The current upstream version of kasan_non_canonical_hook() actually does a simplified check by only checking for the lower bound (e.g. for x86, there's also an upper bound: KASAN_SHADOW_OFFSET + (0xffffffffffffffff >> 3) =3D=3D 0xfffffbffffffffff), so we could improve it. [1] https://bugzilla.kernel.org/show_bug.cgi?id=3D218043