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 755F6C433EF for ; Wed, 29 Jun 2022 00:42:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A2D148E0001; Tue, 28 Jun 2022 20:42:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9DF906B0072; Tue, 28 Jun 2022 20:42:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8A4A48E0001; Tue, 28 Jun 2022 20:42:57 -0400 (EDT) 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 7C1686B0071 for ; Tue, 28 Jun 2022 20:42:57 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay12.hostedemail.com (Postfix) with ESMTP id 5156F1202EC for ; Wed, 29 Jun 2022 00:42:57 +0000 (UTC) X-FDA: 79629423594.27.374C54E Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by imf14.hostedemail.com (Postfix) with ESMTP id 3539210001D for ; Wed, 29 Jun 2022 00:42:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1656463376; x=1687999376; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=celv9RtvlunAXoqVWxMaVGo9wta5M5+aFHyYY4I6Hvw=; b=T/Fih+vTcZFLjih1Z/JwfHIS1/pz7e7dY7C47rWS1tPZdHKP0SJ0161U tnm9xh0O1LRAHFjpjquUj0jik7Dv14vK5VhPm5U6jZn/GIMhm1xgR1XNu uOGxACAFb9P+gye6QkFphIcGL5cTxltiDW2gaY1X7p6jmajt9U+EGaMCH VSW4GqtvhSsAtx7Wi8tmVpazkyUY1sTUhfQuxOlXXo+gwh5RGwlnmF8Wg +2gh5JwrlrS6jK+QEGdSCse/rR0F++xwO67AiQhB9uccLfmef30tb9+k6 u8SvbR/eGKMMQ/n8PgqpHKuNnKL1CDKHYDKuf/uVQfKxYhhp6QUkhQPfN Q==; X-IronPort-AV: E=McAfee;i="6400,9594,10392"; a="307372704" X-IronPort-AV: E=Sophos;i="5.92,230,1650956400"; d="scan'208";a="307372704" Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 28 Jun 2022 17:42:55 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.92,230,1650956400"; d="scan'208";a="693344105" Received: from black.fi.intel.com ([10.237.72.28]) by fmsmga002.fm.intel.com with ESMTP; 28 Jun 2022 17:42:51 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id A4CE3CE; Wed, 29 Jun 2022 03:42:57 +0300 (EEST) Date: Wed, 29 Jun 2022 03:42:57 +0300 From: "Kirill A. Shutemov" To: Andy Lutomirski Cc: Dave Hansen , Peter Zijlstra , x86@kernel.org, Kostya Serebryany , Andrey Ryabinin , Andrey Konovalov , Alexander Potapenko , Dmitry Vyukov , "H . J . Lu" , Andi Kleen , Rick Edgecombe , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCHv3 5/8] x86/uaccess: Provide untagged_addr() and remove tags before address check Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53d41f54-28ad-023c-537f-281cc2c40ae9@kernel.org> ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656463377; a=rsa-sha256; cv=none; b=K4pUFmfE65IjJZWU/kpZ1fDvFYVjHrHQY7RBsu2YOkB1+P5Rc9nNt0KMSwZvKz+PxErPrE ocC1SQhd0mGvYPQcZ40lzVf+S5t8abzcU76VBTYC84/nkfGQuN0Y+xbY0nESSO2PWmkIMP KPqCkVV6ma0XBPcfhauTzCDuUfQBqTo= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="T/Fih+vT"; spf=none (imf14.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.55.52.88) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656463377; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=0miiUw1wt+ADlILiOkeMxij39sFRzPPQKWwyLkJoWlk=; b=JJKUFbbRoztbIo9Gu1NYK8N6th4ZbWgaowhG0GU709W8YHv7xLbAQv/1qYvB+cNi28Nfnq 8v1nc1migzZG23cicnsEF9ZRSiOnU3xLfJhdNidOVRcxwh0J//IX4FNfxRiRsUZ8p6fC7D +SPB/7CUzd+hBWbj8nETJiXK1HODzHs= X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 3539210001D Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="T/Fih+vT"; spf=none (imf14.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 192.55.52.88) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com X-Rspam-User: X-Stat-Signature: 5e3byhtumnfzhtxfh4cz55w59krmka1g X-HE-Tag: 1656463376-474994 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 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 and > > 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. > > > > The tags must not be included into check whether it's okay to access the > > userspace address. > > > > Strip tags in access_ok(). > > 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 'addr' + '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 address 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.) > > 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. -- Kirill A. Shutemov