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 D6C93C43334 for ; Thu, 30 Jun 2022 02:38:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 60BAA8E0002; Wed, 29 Jun 2022 22:38:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5BC538E0001; Wed, 29 Jun 2022 22:38:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 45C2E8E0002; Wed, 29 Jun 2022 22:38:46 -0400 (EDT) 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 340518E0001 for ; Wed, 29 Jun 2022 22:38:46 -0400 (EDT) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 0CBE2603B8 for ; Thu, 30 Jun 2022 02:38:46 +0000 (UTC) X-FDA: 79633344252.22.58274A0 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf23.hostedemail.com (Postfix) with ESMTP id 62116140040 for ; Thu, 30 Jun 2022 02:38:45 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id BAF7FB827E2; Thu, 30 Jun 2022 02:38:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 052BAC3411E; Thu, 30 Jun 2022 02:38:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1656556722; bh=rfxOa7Si8i6HAVrL1PPC9Wi+JEHcRpWPQNKdTnH/Qvc=; h=In-Reply-To:References:Date:From:To:Cc:Subject:From; b=UQv7CTfdGqGmqPcTNBXqhka5g+oy8i5sFZf2IfBAKKbH169eZFQfkpu9AuPHhD81c YbqlkFJWJBD6I0KpYQhA6MLeIAU+YYwqENHkDW1ZyNXh1TXTJsUQw8jyY3bDlN6ly2 cGAE/wll8C3PjGogxC8teijr/YWWBxW8L+IYzSkPoQh4FWBJr80VHsyKE0x0DdYh3x /JmhllTeHFyCs/DeCe/sBqu+kKarG7lhcR50PAAiU9G/HQftG1anXs4r9cIox+3TQo aMcxfXUSI+JXP5TruhtHhG4+lXa8P7HsxeWfMn/FFesutL8zQBtN1LSVURqfj1HZhd QNhM4jmVCcSCQ== Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailauth.nyi.internal (Postfix) with ESMTP id D6B2027C0054; Wed, 29 Jun 2022 22:38:40 -0400 (EDT) Received: from imap48 ([10.202.2.98]) by compute2.internal (MEProxy); Wed, 29 Jun 2022 22:38:40 -0400 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudehtddgiedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtgfesthhqredtreerjeenucfhrhhomhepfdet nhguhicunfhuthhomhhirhhskhhifdcuoehluhhtoheskhgvrhhnvghlrdhorhhgqeenuc ggtffrrghtthgvrhhnpeduveffvdegvdefhfegjeejlefgtdffueekudfgkeduvdetvddu ieeluefgjeeggfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpegrnhguhidomhgvshhmthhprghuthhhphgvrhhsohhnrghlihhthidqudduiedu keehieefvddqvdeifeduieeitdekqdhluhhtoheppehkvghrnhgvlhdrohhrgheslhhinh hugidrlhhuthhordhush X-ME-Proxy: Feedback-ID: ieff94742:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9983531A0062; Wed, 29 Jun 2022 22:38:40 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.7.0-alpha0-713-g1f035dc716-fm-20220617.001-g1f035dc7 Mime-Version: 1.0 Message-Id: <7c8381b3-c71b-45e8-a162-c9701dabcc9b@www.fastmail.com> In-Reply-To: <20220629004257.x3pyoydmtk2lhrnx@black.fi.intel.com> References: <20220610143527.22974-1-kirill.shutemov@linux.intel.com> <20220610143527.22974-6-kirill.shutemov@linux.intel.com> <53d41f54-28ad-023c-537f-281cc2c40ae9@kernel.org> <20220629004257.x3pyoydmtk2lhrnx@black.fi.intel.com> Date: Wed, 29 Jun 2022 19:38:20 -0700 From: "Andy Lutomirski" To: "Kirill A. Shutemov" Cc: "Dave Hansen" , "Peter Zijlstra (Intel)" , "the arch/x86 maintainers" , "kcc@google.com" , "ryabinin.a.a@gmail.com" , "andreyknvl@gmail.com" , "glider@google.com" , "dvyukov@google.com" , "H.J. Lu" , "Andi Kleen" , "Rick P Edgecombe" , linux-mm@kvack.org, "Linux Kernel Mailing List" Subject: Re: [PATCHv3 5/8] x86/uaccess: Provide untagged_addr() and remove tags before address check Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656556725; a=rsa-sha256; cv=none; b=pCpJiIqVCNNFbKDPpJm0n+lGpA9T9kYLL3ISwEB41J6K/PxYb9rNZ4EHWs+hkOZR61j9VG yvkStzh2lofTNvaP+BkCmO5lT2lrJh3fPhGd5eeFqIDe1Oy0y1tww0eisd7shRewShdGHE gI9on6g8KV4Dw+HX12mm4ifd/6NTkrY= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=UQv7CTfd; spf=pass (imf23.hostedemail.com: domain of luto@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=luto@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656556725; 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=VndnA66wrHz1onoo2dkmx9iLQEXDAJlYsrOMjOVOjCc=; b=nr0H4yph9/wXtf/NM6oIVIpHRr+HZ3uTMqkK+Jl3zlPNGDO4R5uWsliyPpgdX6mbc80VTd RNGvOACfSSPChIrjRgeTh7IhgQMcro53gAOFVEe0OW05rsDz4Ps6lEomgZFa7n08JFj6TT FUK8+jRXpnS8IbeH002Afz8vD+om4e0= X-Rspam-User: X-Rspamd-Server: rspam04 Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=UQv7CTfd; spf=pass (imf23.hostedemail.com: domain of luto@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=luto@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Stat-Signature: 8jnm8ghbo8gcucdk1ewjysi8yp57umsq X-Rspamd-Queue-Id: 62116140040 X-HE-Tag: 1656556725-132048 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: On Tue, Jun 28, 2022, at 5:42 PM, Kirill A. Shutemov wrote: > On Tue, Jun 28, 2022 at 04:40:48PM -0700, Andy Lutomirski wrote: >> On 6/10/22 07:35, Kirill A. Shutemov wrote: >> > untagged_addr() is a helper used by the core-mm to strip tag bits a= nd >> > get the address to the canonical shape. In only handles userspace >> > addresses. The untagging mask is stored in mmu_context and will be = set >> > on enabling LAM for the process. >> >=20 >> > The tags must not be included into check whether it's okay to acces= s the >> > userspace address. >> >=20 >> > Strip tags in access_ok(). >>=20 >> What is the intended behavior for an access that spans a tag boundary? > > You mean if 'addr' passed to access_ok() is below 47- or 56-bit but 'a= ddr' > + 'size' overflows into tags? If is not valid access and the current > implementation works correctly. > >> Also, at the risk of a potentially silly question, why do we need to = strip >> the tag before access_ok()? With LAM, every valid tagged user addres= s is >> also a valid untagged address, right? (There is no particular need to >> enforce the actual value of TASK_SIZE_MAX on *access*, just on mmap.) >>=20 >> IOW, wouldn't it be sufficient, and probably better than what we have= now, >> to just check that the entire range has the high bit clear? > > No. We do things to addresses on kernel side beyond dereferencing them. > Like comparing addresses have to make sense. find_vma() has to find > relevant mapping and so on.=20 I think you=E2=80=99re misunderstanding me. Of course things like find_v= ma() need to untag the address. (But things like munmap, IMO, ought not = accept tagged addresses.) But I=E2=80=99m not talking about that at all. I=E2=80=99m asking why we= need to untag an address for access_ok. In the bad old days, access_ok= checked that a range was below a *variable* cutoff. But set_fs() is gon= e, and I don=E2=80=99t think this is needed any more. With some off-the-cuff bit hackery, I think it ought to be sufficient to= calculate addr+len and fail if the overflow or sign bits get set. If LA= M is off, we could calculate addr | len and fail if either of the top tw= o bits is set, but LAM may not let us get away with that. The general p= oint being that, on x86 (as long as we ignore AMD=E2=80=99s LAM-like fea= ture) an address is a user address if the top bit is clear. Whether that= address is canonical or not or will translate or not is a separate issu= e. (And making this change would require allowing uaccess to #GP, which = requires some care.) What do you think? > > --=20 > Kirill A. Shutemov