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 92B79C77B61 for ; Mon, 24 Apr 2023 18:22:10 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E2D0A6B0072; Mon, 24 Apr 2023 14:22:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DDD096B0074; Mon, 24 Apr 2023 14:22:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CA4936B0075; Mon, 24 Apr 2023 14:22:09 -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 B99F66B0072 for ; Mon, 24 Apr 2023 14:22:09 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 73A091A02DB for ; Mon, 24 Apr 2023 18:22:09 +0000 (UTC) X-FDA: 80717103978.02.62F408C Received: from mail-wr1-f48.google.com (mail-wr1-f48.google.com [209.85.221.48]) by imf04.hostedemail.com (Postfix) with ESMTP id 835714001E for ; Mon, 24 Apr 2023 18:22:07 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=H5waO2lV; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf04.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.221.48 as permitted sender) smtp.mailfrom=lstoakes@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1682360527; 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=GNWb62e8CZIjs8fCUmW4pdVL9gTqXJEWDD+orJ1zuz0=; b=QX4luSpiGqv2gkeH+I/uy/8T2/UL++UVJCQJ5KGVVDqs7vabbJOiIik5bgkmVgetSQ/JiO ROs70oEPjJ7YXJ9ij97w8bj8g9FNqqevGU6wnviMQfqp0EepdVmAkCkmlx2yZ4peew/izf FnVO3IArFXqpL1PVDrnWo4Q/gFFjITs= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=gmail.com header.s=20221208 header.b=H5waO2lV; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf04.hostedemail.com: domain of lstoakes@gmail.com designates 209.85.221.48 as permitted sender) smtp.mailfrom=lstoakes@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1682360527; a=rsa-sha256; cv=none; b=KAWjfwzCTkP8Vr//5rBZWUl0LHJ1d8E2Rmkz7TQYV8oUU6PJE7RDRCfy2FGjMFDfVZ5iRe Pii2+urqbbN7LcMix4Dsz5d0vAijSvs4OArCQ/VhDX7x6p5g9GJym1ob9IeLdmisWWTWS2 uYkTAYkZXPJqjvZf86tQXX/6E9t5zVk= Received: by mail-wr1-f48.google.com with SMTP id ffacd0b85a97d-2f8405b3dc1so2885764f8f.3 for ; Mon, 24 Apr 2023 11:22:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682360526; x=1684952526; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=GNWb62e8CZIjs8fCUmW4pdVL9gTqXJEWDD+orJ1zuz0=; b=H5waO2lVV3WBPBob6qcwDjzXxuUC5G8iugaCsakCau25e2nQVZkCEflYqfjCA79/+y NPM55qPl5re3i0yMT/YrYCQH9VeeIYZQYU8OJJtaglvYTDa5raa6jLqgPkNeeN3oT7wa P14wmAxZ2C2upU4ckUa+UiOKhgQv5ylRFql5AedoiuiJpk3cvv3kthNbfSPcBzdfOjLw LFUmc0hsGAouMZd5Bq+mYaqFJspu6z4HesNUuf0ImsN7FEwgKhYb0QjwGwbr13jrAg9B GAHkLUSMmAK1tNQwgf0vGKwQWwvZdAKrZS+YsNwcA/7TxUctioZnm0lMHRwQdhNuulVT sJDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682360526; x=1684952526; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=GNWb62e8CZIjs8fCUmW4pdVL9gTqXJEWDD+orJ1zuz0=; b=Y6sCmyx5jpeTydt3/BcAnOBlLavGurrpR9L0zs4Xsvoq+itt9tL7IG2yVnUydF+mj5 y/SZDwCTAXZAxfR/x469JhfL10oK/jy8h69Qu7Df1T7Rl0VQ4pE0eTEsUjVI6WuBZhhW SUpvbMb8hViM8JjMHXApzbGA9bZ8S/TLds0qLbVVea/Qa3Kk+niyPBjHlt3SVhA1LRJE 2PVEBi2VDTo7tjyunWyUQPc0K6NQRQqJchZFYj29ra98VW2PioVu8WFYb6FS4AEmAbyN ATGzdDcD1+xq/MrhYAW4nxZS+WwrLltOynQSWEhtyLQs5cRUjw2DKkuZncVeXloPw++5 i8yQ== X-Gm-Message-State: AAQBX9dMI7PFNeviU5TRIgJL2AOz0hKsv6J6iwVJjhELowt4G1y66YQo NooXDV8I+VY2pQERwYbW61s= X-Google-Smtp-Source: AKy350axh1bla12sBBL0jXPnMeWce8zQbehX+yTZ5r+1QdjTUe4lwDcOG4wov94gQPDhdmEZFp/48w== X-Received: by 2002:adf:f983:0:b0:2ef:ba4f:c821 with SMTP id f3-20020adff983000000b002efba4fc821mr8354283wrr.36.1682360525728; Mon, 24 Apr 2023 11:22:05 -0700 (PDT) Received: from localhost (host86-156-84-164.range86-156.btcentralplus.com. [86.156.84.164]) by smtp.gmail.com with ESMTPSA id z18-20020adfe552000000b002f3e1122c1asm11316412wrm.15.2023.04.24.11.22.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Apr 2023 11:22:05 -0700 (PDT) Date: Mon, 24 Apr 2023 19:22:03 +0100 From: Lorenzo Stoakes To: Jason Gunthorpe Cc: Christoph Hellwig , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Jens Axboe , Matthew Wilcox , Dennis Dalessandro , Leon Romanovsky , Christian Benvenuti , Nelson Escobar , Bernard Metzler , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Ian Rogers , Adrian Hunter , Bjorn Topel , Magnus Karlsson , Maciej Fijalkowski , Jonathan Lemon , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Christian Brauner , Richard Cochran , Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer , John Fastabend , linux-fsdevel@vger.kernel.org, linux-perf-users@vger.kernel.org, netdev@vger.kernel.org, bpf@vger.kernel.org, Oleg Nesterov Subject: Re: [PATCH v2] mm/gup: disallow GUP writing to file-backed mappings by default Message-ID: References: <90a54439-5d30-4711-8a86-eba816782a66@lucifer.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 835714001E X-Stat-Signature: j4ums9u8ebfqqjedoibzbinnb7ds6g3p X-HE-Tag: 1682360527-663455 X-HE-Meta: U2FsdGVkX1/9CcQNz03ME3LaRssz6eH3lGnWgSjOdvej4oGrrv5WRMyFAcDmY+w1mYcuUoIg5A6+mHNo+em5+k94J6taw2UHlLd5QxCpd5u5bhpw+dwweaPAihR4ABg4fd3EMOp4pA8M1G86H1JyXb4MHjFHUf3MZ0X9QHyMWttcIaU2t42dvvvIoBI3dhTfpweX6K/9IwpIsoqE/7QRVZWCl0QoednaV0VgenGEl78jhG3N9oxV7uVHd6l5E0imocXDD3jrb+OtnVV7Oq3xVJ4GdUp5EI3mkEURTR9pdhect0tpuA0eu6doTGLa6B//fcJszcOnscCw31AAGNX30W3wFRS/1hcNEgGKmXFKoyhcc+M9ce+lUYIyBCVHh27z3c7dTloQ1VcIUdWQphZZ86llRDZSNYYMNEaensKLjq1TCXb921a8TC/7hTUhGPXto3NabT0xnIv32J/Qv/thZXgs6XwUvpm5pB6uZFJwO7NWMzJtdQWbsr61qsrkLJRFew9aWW9MTdpc6Tky244nOjwU9A2lwYDL8rV2LFcUFdy6dmhJaOsUAOeEWyV+oVdBsA8WhpERVS0um8SmHQ1kzJgUfq0kOJra3UxEJ8fzUc+VURyKpY68fmWionjLIEybi+xGn45feI/3scBTSvyk45r2MpRrLXvaueNre34ZV511GUXUhSbWCOiGVTa1ZFWoV3VjeJ4wYX6AqLlKNmdPv3vHgQ2ORSUK2gXm3d5sziTqXYXdLRlGjl6hRrON2Du/0THm9P/WfhZYtvToQq8QQRmbGpxjnZB+JMjU+BL0VjQxGHiTt16fJDYPM0TcJyq4XdCG9uflRb6wvzgtjOr1ZQXIXTF5k0E3eFBk4SyAFcDJZotyPCURfXIziI3whxn0Ks5mP/Jvyvaxh6VT4sLxOi+vF9qB60cSlMzK2Qcj4j9WbMnp+GvBYq9Gde3T/XTsHgZo0K0DmDOd75I0KR9 WOPSiSFS 02dbtRWo2M3y/LQNVpkLdyOyr5+qNRvHRyfBRZRBYbGgn2YALWHCD6GMFCJhbOODuT20vV7BXlxWg10ywPBPM4UqKr4ovAndu3NbSF7yQ220EkaPvk6yYmnlQ/VJR/dSZ8nt0OzcIvE5y+uVLXdPcsuGaWlwdSE+oieYCQJ0szUeChFLm/B5Ie31OgKGfJvdBCkcF+ORSFH5UxEQUHbXeQofh6kB1ToleuwbcuADJX2ECJRkG17Dj/JPYDnzVqLgPYN2/M7qXpNVDMTxPZcptuj7rbADw2maf8kB2b7sDejDBqF4Cor43dS9rWRFVv5zo9S5JzvkK38y6wkzFtNNFo/PK038SEpm2AUqKmLgEkiWkiRtBNmzVvmPEp9Zd0Sn4jVoKTay476jvkXSwbHDkCDoZ6mXdWK5l/MhR5Yi20Wjz7QP41nfzCckFTV7W3leYJVwTZfUdHyff6fYKDfy3yx3g4A== 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 Mon, Apr 24, 2023 at 02:36:47PM -0300, Jason Gunthorpe wrote: > On Mon, Apr 24, 2023 at 03:29:57PM +0100, Lorenzo Stoakes wrote: > > On Mon, Apr 24, 2023 at 10:39:25AM -0300, Jason Gunthorpe wrote: > > > On Mon, Apr 24, 2023 at 01:38:49PM +0100, Lorenzo Stoakes wrote: > > > > > > > I was being fairly conservative in that list, though we certainly need to > > > > set the flag for /proc/$pid/mem and ptrace to avoid breaking this > > > > functionality (I observed breakpoints breaking without it which obviously > > > > is a no go :). I'm not sure if there's a more general way we could check > > > > for this though? > > > > > > More broadly we should make sure these usages of GUP safe somehow so > > > that it can reliably write to those types of pages without breaking > > > the current FS contract.. > > > > > > I forget exactly, but IIRC, don't you have to hold some kind of page > > > spinlock while writing to the page memory? > > > > > > > I think perhaps you're thinking of the mm->mmap_lock? Which will be held > > for the FOLL_GET cases and simply prevent the VMA from disappearing below > > us but not do much else. > > No not mmap_lock, I want to say there is a per-page lock that > interacts with the write protect, or at worst this needs to use the > page table spinlocks. > > > I wonder whether we should do this check purely for FOLL_PIN to be honest? > > As this indicates medium to long-term access without mmap_lock held. This > > would exclude the /proc/$pid/mem and ptrace paths which use gup_remote(). > > Everything is buggy. FOLL_PIN is part of a someday solution to solve > it. > > > That and a very specific use of uprobes are the only places that use > > FOLL_GET in this instance and each of them are careful in any case to > > handle setting the dirty page flag. > > That is actually the bug :) Broadly the bug is to make a page dirty > without holding the right locks to actually dirty it. > > Jason OK I guess you mean the folio lock :) Well there is unpin_user_pages_dirty_lock() and unpin_user_page_range_dirty_lock() and also set_page_dirty_lock() (used by __access_remote_vm()) which should avoid this. Also __access_remote_vm() which all the ptrace and /proc/$pid/mem use does set_page_dirty_lock() and only after the user actually writes to it (and with FOLL_FORCE of course). None of these are correctly telling a write notify filesystem about the change, however. We definitely need to keep ptrace and /proc/$pid/mem functioning correctly, and I given the privilege levels required I don't think there's a security issue there? I do think the mkwrite/write notify file system check is the correct one as these are the only ones to whom the page being dirty would matter to. So perhaps we can move forward with:- - Use mkwrite check rather than shmem/hugetlb. - ALWAYS enforce not write notify file system if FOLL_LONGTERM (that removes a lot of the changes here). - If FOLL_FORCE, then allow this to override the check. This is required for /proc/$pid/mem and ptrace and is a privileged operation anyway, so can not cause a security issue. - Add a FOLL_WILL_UNPIN_DIRTY flag to indicate that the caller will actually do so (required for process_vm_access cases). Alternatively we could implement something very cautious and opt-in, like a FOLL_CHECK_SANITY flag? (starting to feel like I need one of those myself :)