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 565D7C021A9 for ; Mon, 17 Feb 2025 16:13:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 76D2C280072; Mon, 17 Feb 2025 11:13:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6F613280070; Mon, 17 Feb 2025 11:13:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 548D1280072; Mon, 17 Feb 2025 11:13:38 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 33505280070 for ; Mon, 17 Feb 2025 11:13:38 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id DAEEBB116E for ; Mon, 17 Feb 2025 16:13:37 +0000 (UTC) X-FDA: 83129932074.02.64B3E4D Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com [209.85.221.47]) by imf17.hostedemail.com (Postfix) with ESMTP id EC42940012 for ; Mon, 17 Feb 2025 16:13:35 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=QwPbPekI; spf=pass (imf17.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.221.47 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=1739808816; a=rsa-sha256; cv=none; b=LVtl2tQhAhqtIOgv40vkCDyiDvW4Dxy3yrLh5tdVTkCS3jLFuPUt178+3dDyeOu9KQ4dH1 5/Hulgr6S/iQVlwTp+Hg2+X7J/oYqX3r/aewXPbWcTKRDnBLmgzsd3dhjqpCEixZQrnBtk 5vf5T7jvm9Lip6QwgFVh3mPyNfX3NCI= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=QwPbPekI; spf=pass (imf17.hostedemail.com: domain of andreyknvl@gmail.com designates 209.85.221.47 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=1739808816; 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=1KxbE/LUi+pBeXrp6r1WoRsJN4gZHatc3HSxCggqAc8=; b=v/2aHkSGiAO0UEWfs20RGxl5+MehFhfh8xNTScG/joUq91rkHnZQcpSostbAdoHD/Xxx3S pOBNo6xKgaDxPa1gIUxrpUOdXe9L6KjIi0bkaiQM9ywIERkzwzPqD2oWCXcfPlFp4Ooeid xGfLqqsfB4FyMmI34S8bNK+XkgpGEDI= Received: by mail-wr1-f47.google.com with SMTP id ffacd0b85a97d-38f2b7ce319so2592904f8f.2 for ; Mon, 17 Feb 2025 08:13:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1739808814; x=1740413614; 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=1KxbE/LUi+pBeXrp6r1WoRsJN4gZHatc3HSxCggqAc8=; b=QwPbPekI4wyHuagawAglnZSBrcxOgOhXv+snmQHibrHBPQ9M4yBg8krZMhlVRja1vs xbGuB3hhO3Ko746nvRBL62RJuPgUbjuXK5adCMflgRNbWknfIK4D0X878RP9/83cYqPM 1DG8qmPMloUIacgtGI2jDpjXIbqXK2cx/G3ebty5fnxkC5CGK/IaGgaZQtFy6duH4FDg imBLG8p6FRgDrMZ7cQ4S/gcDz21Y/uXpd96WjYDLgXuXYNXUtZCCgxDFG2RmVZzjzXsI KBdHQdch+At1qPN0nScpodFumhsZ+BbkjYjLzzr2o0vJ4m9wlNZeEoNbQ0FuxGjoxhw2 sLJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739808814; x=1740413614; 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=1KxbE/LUi+pBeXrp6r1WoRsJN4gZHatc3HSxCggqAc8=; b=r6KblYhD+7Hk09I3xdc52BAD6Bs5oFrqZ3VuiSEjrNm+W3vTvKi3MU7k3JMUrJL80w dMrDRtiZ4xWfg49z1C9qE//k9Q2pWWlwnIG2sfCUWQsZtSdWCIeCWtBpoQ4UFAGOjbSR G2qvxaC+ULJNeK/a6qdVs7hQthP5BCeJOysmhfUfvMhNhySZI/RtsNoza7lVgn2hwphA T6WQcjJ7sOcmVP3rRohEoP6ypNHu0sgICU1ntl3xjLQxuD7O7PX5t2XDFCkkx9IeN0Y5 SMia3a7yXYW91JaOGgLl+dE+7tTPxNhe0c65sOB0myCF5K5NNGqGuM+CkDrvzNUYi8PU I6VA== X-Forwarded-Encrypted: i=1; AJvYcCXGOd7IlITjaANp0Bx409W7oKHPMw1LJFQGv78R9+z1rAxXGY9sRUj/bxbUI1O3UpW9U+M/+Q39YA==@kvack.org X-Gm-Message-State: AOJu0Yx/nTo4My84VSm6hBsY38I5bgh8AWVFtCqS0D0C9T10yD3LbTs0 VbIkFsvDQXJsQffqHcYdjK8BDdMf1j0PXrjICV8XGyOiYwaVeZNYPcrHW81e25ppf7+FipFSoTY 7kbCwx+ujrf3YVqj/8UdkmlE1mgg= X-Gm-Gg: ASbGncse/nRtcLgUkkem2zPrrzJYic5ETyTqhmoKU4vuCTJ+i8sdKN0QibpEkZVl9Cb lphEbmx3npGV97iloEIEKBBNqWx+w9eoM//BIq+u6yAx8K97uaWWx2QVbTQ71yX0OtDIymy+pG+ 0= X-Google-Smtp-Source: AGHT+IHm8HBgn3sImk7NTjtXb+A27btOABGGevI0EONCrC/Ff9AcLGqA4yAvmgT0QuA1lhKIHNQku0J8pxt9SI1xfb8= X-Received: by 2002:a5d:64cc:0:b0:38f:4fa6:bb24 with SMTP id ffacd0b85a97d-38f4fa6bca3mr698753f8f.39.1739808814051; Mon, 17 Feb 2025 08:13:34 -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: Mon, 17 Feb 2025 17:13:23 +0100 X-Gm-Features: AWEUYZmQ1uvVHZE607fk9A3oqamhim11vzns-dfPoe7sFHHzYYWlnLIpBeOBi1A 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-Stat-Signature: cfeafheh75i7po473udenf4snywk3xaf X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: EC42940012 X-Rspam-User: X-HE-Tag: 1739808815-566721 X-HE-Meta: U2FsdGVkX18CePLEDqRwEz45x6rXYWddag5mNoFeXsONf+JU45XRypQo7hqnGd9qzZbwxVNM6oAdo5AXjMhbn53KpQ4EDe2mCbPzrTVdtSHRnFoVSwCkt5pVZPaQZPQnIHHiZ9e7rPlW9Jlm056eMJwRzB7ttELkheFARTCIZZyxYyJac7sSXT4KBtwJgR4KCgXR/H2aiP+0B2wEngdSx3yWI/FFKX88mSLN5tYlT0X+VrUBg99o7/UVXscARvqMaQDt3MSAop87j1w60FCE9Ka+EBtMt9esTNdV6Qmr64UKn7egxubjUmZnrY9/3uC2sxedegsSct+f1G54gnZfGhaNohbwfhwbCD5SjKsDHchsJmHlOpl0S5Bvgu2mumWoVTaCozkVDCTMxeg6PZbxOay/AxXiseN1/Pxzp/kes4T4SW72wq4PW2356W8+ndtQS3rB9rwytaGRgJw32jgMPuOghV21sPXqrmnfMG5ggM3AyuHV5vPT1SU1GxYwRjZUQKYklODe5fzSAYC2hqQxrtzxV0VH1K10Hd5KO5/y+iWRsuxO2YPZlhRXZ2I3uWeD29REDzzfDA1+jeecOqftMQh8Np6r7lCl6g+VqXM8OgLCOOQAAvggpACp8BVL0rCm5QbW6b/sUGmmVIdza9Aq2OumaJAqXvLjTMmyUYJvbL9OC138E6LxWQgOoigo7kduyniOccd7IpKPWdCIj/Oq9bqdBPZISrVc6cQGgrHIFedWnukXLizSRTXiQcLTRqIA+KtNbaHbZ7X4yuMsVGRQl2p09LsvhzOyKqLkBFVs6yNTpAauu3P0UZjq/LijezI2ObTklDEXHG1En7RV0exVTcieKp4REZYP7sCSyMMeOvva8EyCfSaGGa2j+AI2Meu059x7FSaWQNQ2haAzKvaC6xfTIjt0rI52+t1E/C/T6B70NXhO05kkTorzItf7mpyD70eyg/WUwhYjXGdl3MQ FfEzsoFc 74XLAjecuKO0aOSmRp/zqvHGkSeYZsEJOupYVUpfDAsDQ6mEg87w5TbljiBiiUZPI4E6hFrE2w0SBwyfjf9shfWl2PbuyoL/CXFhalrcr1xy7lO+lUf/KuoNhZ/T9z99uELegrTdlvWBsVjMjiV7YtVe9C2UT9Tv1pmsjHkwKWLOj78Xsvvs+h9+4wdH6NMeRNY/p1/3lVnTQ1ateT57odVqNrECX0FgLbQya59ZqLU4OQGUGR1ALNSgzQHwzuvFX8EXC8rhmMvD+IDvY13kBmjMPUfQscwaLUH+/2kyCNpZ3wTEXvVx28gpED5ExHYEiFEFBMNkynwtwlMYhf2eGPgGQ0LtMNTk7qK/xMXu9KeeerB7L6lALk/58SfvqITcYY17SsC5+Z1qqsWxoIq/Jee7iMIUWKku3VmzjNBKaYvlW7PM3yLXeDadbDX4KcL8B5sSduSTaTEkjGQRTKmQWsJ2O4jYAWzyyTZygQzS9kUif7+c= 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 Fri, Feb 14, 2025 at 9:21=E2=80=AFAM Maciej Wieczor-Retman wrote: > > On 2025-02-13 at 17:20:22 +0100, Maciej Wieczor-Retman wrote: > >On 2025-02-13 at 02:28:08 +0100, Andrey Konovalov wrote: > >>On Thu, Feb 13, 2025 at 2:21=E2=80=AFAM Andrey Konovalov wrote: > >>> > >>> 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 addr= ess out when > >>> > we consider any random bogus pointers. > >>> > > >>> > I used the KASAN_SHADOW_OFFSET from your example above. Userspace a= ddresses seem > >>> > to map to the range [KASAN_SHADOW_OFFSET - 0xffff8fffffffffff]. The= n going > >>> > through non-canonical addresses until 0x0007ffffffffffff we reach t= he 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 pro= per shadow > >>> > 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 exper= iment > >>> > 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 o= n > >>> 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. > >> > >>Eh, scratch that, the 3rd bit from the top changes, as > >>KASAN_SHADOW_OFFSET is not a that-well-aligned value, the overall size > >>of the mapping holds. > >> > >>> 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(). > >>> > > > >Right, I somehow forgot that obviously the whole LA has to map to 1/16th= of the > >address space and it shold stay contiguous. > > > >After rethinking how the mapping worked before and will work after makin= g stuff > >signed I thought this patch could make use of the overflow? > > > >From what I noticed, all the Kconfig values for KASAN_SHADOW_OFFSET shou= ld make > >it so there will be overflow when inputing more and more positive addres= ses. > > > >So maybe we should first find what the most negative and most positive (= signed) > >addresses map to in shadow memory address space. And then when looking f= or > >invalid values that aren't the product of kasan_mem_to_shadow() we shoul= d check > > > > if (addr > kasan_mem_to_shadow(biggest_positive_address) && > > addr < kasan_mem_to_shadow(smallest_negative_address)) > > return; > > > >Is this correct? > > I suppose the original code in the patch does the same thing when you cha= nge the > || into &&: > > if (addr < KASAN_SHADOW_OFFSET - max_shadow_size / 2 && > addr >=3D KASAN_SHADOW_OFFSET + max_shadow_size / 2) > return; > > kasan_mem_to_shadow(0x7FFFFFFFFFFFFFFF) -> 0x07ff7fffffffffff > kasan_mem_to_shadow(0x8000000000000000) -> 0xf7ff800000000000 I'm a bit lost with these calculations at this point. Please send the full patch, including the new values for KASAN_SHADOW_OFFSET (do I understand correctly that you want to change them?). It'll be easier to look at the code. Feel free to send this patch separately from the rest of the series, so that we can finalize it first.