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 AA285C433EF for ; Tue, 28 Jun 2022 23:40:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EAB306B0071; Tue, 28 Jun 2022 19:40:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E59F76B0072; Tue, 28 Jun 2022 19:40:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D22988E0001; Tue, 28 Jun 2022 19:40:51 -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 C30B86B0071 for ; Tue, 28 Jun 2022 19:40:51 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay13.hostedemail.com (Postfix) with ESMTP id 9B422603DF for ; Tue, 28 Jun 2022 23:40:51 +0000 (UTC) X-FDA: 79629267102.16.EC5CFD2 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf31.hostedemail.com (Postfix) with ESMTP id 38DDF20018 for ; Tue, 28 Jun 2022 23:40:51 +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 dfw.source.kernel.org (Postfix) with ESMTPS id 6905561B5D; Tue, 28 Jun 2022 23:40:50 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 28B65C341C8; Tue, 28 Jun 2022 23:40:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1656459649; bh=7nIWwuteCtLL/7qZso59iVjJhUGGVyjf9VgBjFYUDkI=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Psow3Oswi0EHugLEe52mJmeGzxbU7wKaNhIE/6NdJpD0FUh7Exs465CiQSgU3daYV REznHzpYhzehwyHMeQdqzVROVOKrRCqAZIJqVLhZziCCteHo7ZjmyVOakNa8EuC8Gk NamG9aqmvRYk+Qm5YBNgPBP6slb2rLniG2I3O1JPxXgsnzDvPid8Z4Yzs4t9j8ArFT dRur1a7xhVR5KYMfbfsWK9GC0sGagaLLqeigIHP3hB7qo1sBn6Fx/MxghBnJH++XI7 cXUrxKu0ZIR+Dbi685UnKUmLI7GNngfzbrnL0utdC5Y7L7ZXhhU8js8+WzwW/WCev1 kxqa1LfzWFw7w== Message-ID: <53d41f54-28ad-023c-537f-281cc2c40ae9@kernel.org> Date: Tue, 28 Jun 2022 16:40:48 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: [PATCHv3 5/8] x86/uaccess: Provide untagged_addr() and remove tags before address check Content-Language: en-US To: "Kirill A. Shutemov" , Dave Hansen , Peter Zijlstra Cc: 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 References: <20220610143527.22974-1-kirill.shutemov@linux.intel.com> <20220610143527.22974-6-kirill.shutemov@linux.intel.com> From: Andy Lutomirski In-Reply-To: <20220610143527.22974-6-kirill.shutemov@linux.intel.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656459651; a=rsa-sha256; cv=none; b=nszXAR8ao8l4bVMm3V438z+Fc307SVBs6bmEU/WWcfqsyU9VXnaU+JLY/D2jrqmeb483SK dFPbXbmGN68Hks1XIPqCjguCK+duXipD0bDWlnW6IArivcISCxkGpx47dKCbEBmwWgKLe2 WSUgVXYI20+f57Eu2xsUUwpKEGvqgqA= ARC-Authentication-Results: i=1; imf31.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Psow3Osw; spf=pass (imf31.hostedemail.com: domain of luto@kernel.org designates 139.178.84.217 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=1656459651; 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=1UL9W/kDDvjvljqTCtuX1Qx+hvhgSreuYOx4IdymUUo=; b=PyOLkKfLmZYWcZhOqB0MacByPYcjlGwgsI5/TB2Nazzg0XrXdk4KWABRufj2fOCSyXrBHX LczTSkXfwIwVHrWoQO2soEMkJ8jHY3uKSBX2KQmX0d8yzRU5fJRKLwtNoH/Rzo+otv2B59 pYJam8dz/YN7vyPgESiEA2IqNRI6+V0= X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 38DDF20018 Authentication-Results: imf31.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=Psow3Osw; spf=pass (imf31.hostedemail.com: domain of luto@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=luto@kernel.org; dmarc=pass (policy=none) header.from=kernel.org X-Rspam-User: X-Stat-Signature: gipwe5tteqrqen36mf5si4z38cwi3dgz X-HE-Tag: 1656459651-860861 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 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? 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? --Andy