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 01526C43334 for ; Sat, 11 Jun 2022 01:12:19 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id F00A38D00FB; Fri, 10 Jun 2022 21:12:18 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EAFAA8D00F7; Fri, 10 Jun 2022 21:12:18 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D29708D00FB; Fri, 10 Jun 2022 21:12:18 -0400 (EDT) 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 C0C088D00F7 for ; Fri, 10 Jun 2022 21:12:18 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 89C7D2172C for ; Sat, 11 Jun 2022 01:12:18 +0000 (UTC) X-FDA: 79564179156.10.CFF5BF3 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by imf19.hostedemail.com (Postfix) with ESMTP id 57BB41A007A for ; Sat, 11 Jun 2022 01:12:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1654909935; x=1686445935; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=YkVAY5kVjUVtusvqvweHGO+n+u3CHpxTEhAo9kaMLts=; b=GEYun/Wpt1iOGwoW36F7xqDY4TR8ctscG2ALO+JVrtOI7Js66L/hW6PD rF+pr3y3YdcIzTInmThZs7tabT52ldQMbzc4Jab/28aoonIlOWIgHfZv8 UA87Fke0zPCXPaVYaBfyB4C/XNLO9vwjhzpVFaf0ZNRUNesX1B7MmzKR7 ypP2CJPThqR6J4Mwv45ZJfRvauTtvYs3/VZH2cNj9wI88/fgkMGbB0yU+ rSyktDQ+q5w9pMzmkmZj9E/NWd38zIwcFQo7J1lzq1Tv6YVKO7gO/32Xa dtTKZID+yuQGBYmQSUwIErqVuOCeyRKgSl4XZScFx4x/smp8HZPygEVB/ g==; X-IronPort-AV: E=McAfee;i="6400,9594,10374"; a="266564459" X-IronPort-AV: E=Sophos;i="5.91,292,1647327600"; d="scan'208";a="266564459" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Jun 2022 18:12:12 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.91,292,1647327600"; d="scan'208";a="610960174" Received: from black.fi.intel.com ([10.237.72.28]) by orsmga008.jf.intel.com with ESMTP; 10 Jun 2022 18:12:08 -0700 Received: by black.fi.intel.com (Postfix, from userid 1000) id 86459F8; Sat, 11 Jun 2022 04:12:12 +0300 (EEST) Date: Sat, 11 Jun 2022 04:12:12 +0300 From: "Kirill A. Shutemov" To: "Edgecombe, Rick P" Cc: "linux-kernel@vger.kernel.org" , "peterz@infradead.org" , "hjl.tools@gmail.com" , "linux-mm@kvack.org" , "dave.hansen@linux.intel.com" , "andreyknvl@gmail.com" , "kcc@google.com" , "ak@linux.intel.com" , "dvyukov@google.com" , "x86@kernel.org" , "ryabinin.a.a@gmail.com" , "Lutomirski, Andy" , "glider@google.com" Subject: Re: [PATCHv3 6/8] x86/mm: Provide ARCH_GET_UNTAG_MASK and ARCH_ENABLE_TAGGED_ADDR Message-ID: <20220611011212.ockffkv4h3fiwfdl@black.fi.intel.com> References: <20220610143527.22974-1-kirill.shutemov@linux.intel.com> <20220610143527.22974-7-kirill.shutemov@linux.intel.com> <20220610180635.l44opq2votd3gxpl@black.fi.intel.com> <5b56c88e477d879e5a0e3c15627cb05901a812f4.camel@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1654909938; a=rsa-sha256; cv=none; b=LL35pami9OrhRHoe6eKGS9eZPh3tdOgo+Wvbhr+s+iI2INjGkG6szdcpRLQpkDR/xMTryQ Jv8mZZT6dtygmLv7Jp5a69TrLfZL4R8WXN0uVU74I25oWxARabXNARP8X1F3XE1A0nIAd2 KsMtaabM6fIj+o/kJcKOMDZ3Qoecb0k= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="GEYun/Wp"; spf=none (imf19.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 134.134.136.20) 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=1654909938; 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=9HPeNlzvWcfyfiHPRelnszlcZtxOu+2sY5ChyM8dA/c=; b=Qp0HU3rgMboO62XWsO2VWkn4XQ+iZrS5AyYJtygplWYoh7qJzgyqrkNwf9H5cU/rnY+rdw zEdbbZ7Cz5LKFGLvBSg+KSZGz/xCMwtLBgfyXDjlL95krgcQ+wIp+xLb4LKHEdAHLnHc83 b/KNHUgLMetR53bYYctqFQ0RPnScOU0= X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: 57BB41A007A X-Stat-Signature: o6qfjdgkytggfexsy9ey65e3iu8dgo1d X-Rspam-User: Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="GEYun/Wp"; spf=none (imf19.hostedemail.com: domain of kirill.shutemov@linux.intel.com has no SPF policy when checking 134.134.136.20) smtp.mailfrom=kirill.shutemov@linux.intel.com; dmarc=pass (policy=none) header.from=intel.com X-HE-Tag: 1654909935-84540 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 Fri, Jun 10, 2022 at 10:18:23PM +0000, Edgecombe, Rick P wrote: > On Fri, 2022-06-10 at 11:08 -0700, Edgecombe, Richard P wrote: > > On Fri, 2022-06-10 at 21:06 +0300, Kirill A. Shutemov wrote: > > > On Fri, Jun 10, 2022 at 04:16:01PM +0000, Edgecombe, Rick P wrote: > > > > On Fri, 2022-06-10 at 17:35 +0300, Kirill A. Shutemov wrote: > > > > > +static int prctl_enable_tagged_addr(unsigned long nr_bits) > > > > > +{ > > > > > + struct mm_struct *mm = current->mm; > > > > > + > > > > > + /* Already enabled? */ > > > > > + if (mm->context.lam_cr3_mask) > > > > > + return -EBUSY; > > > > > + > > > > > + /* LAM has to be enabled before spawning threads */ > > > > > + if (get_nr_threads(current) > 1) > > > > > + return -EBUSY; > > > > > > > > Does this work for vfork()? I guess the idea is that locking is > > > > not > > > > needed below because there is only one thread with the MM, but > > > > with > > > > vfork() another task could operate on the MM, call fork(), etc. > > > > I'm > > > > not > > > > sure... > > > > > > I'm not sure I follow. vfork() blocks parent process until child > > > exit > > > or > > > execve(). I don't see how it is a problem. > > > > Oh yea, you're right. > > Actually, I guess vfork() only suspends the calling thread. So what if > you had: > 1. Parent spawns a bunch of threads > 2. vforks() > 3. Child enables LAM (it only has one thread, so succeeds) > 4. Child exits() > 5. Parent has some threads with LAM, and some not I think it is in "Don't do that" territory. It is very similar to cases described in "Caveats" section of the vfork(2) man-page. > It's some weird userspace that doesn't deserve to have things work for > it, but I wonder if it could open up little races around untagging. As > an example, KVM might have a super narrow race where it checks for tags > in memslots using addr != untagged_addr(addr) before checking > access_ok(addr, ...). See __kvm_set_memory_region(). If mm- > >context.untag_mask got set in the middle, tagged memslots could be > added. Ultimately, a process which calls vfork(2) is in control of what happens to the new process until execve(2) or exit(2). So, yes it is very creative way to shoot yourself into leg, but I don't think it worth preventing. And I'm not sure how the fix would look like. -- Kirill A. Shutemov