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 4741EC4708E for ; Wed, 7 Dec 2022 15:59:40 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AFACD8E0003; Wed, 7 Dec 2022 10:59:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AAA7E8E0001; Wed, 7 Dec 2022 10:59:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 973108E0003; Wed, 7 Dec 2022 10:59:39 -0500 (EST) 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 8998F8E0001 for ; Wed, 7 Dec 2022 10:59:39 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 5CB6B40AB6 for ; Wed, 7 Dec 2022 15:59:39 +0000 (UTC) X-FDA: 80215970478.02.5FEE60D Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf08.hostedemail.com (Postfix) with ESMTP id 33233160016 for ; Wed, 7 Dec 2022 15:59:38 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=ZQooae21; spf=pass (imf08.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1670428778; 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=3ds86l2H1ZNflWHy4/S2aLn7l+F5D9ot2q/ERt4zH3Q=; b=ar19JXNoyAnxoypnqCwu4YkGahM62Pj88veVkMt7hhFjm9YCzV+ohqLKgQBUNm0NGnokOJ Iw0L0Sn+1b2WALzTgifTuG+0bZK+s7RJlk+/RoajpPz6JjEAjyM1zdbKYeQ6cLbMSYOjL0 ZV3XQsWu6m4FyiLTbUTRqV2FMGcXmGQ= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=ZQooae21; spf=pass (imf08.hostedemail.com: domain of peterx@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=peterx@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1670428778; a=rsa-sha256; cv=none; b=244aeOsBZ18lR1wqc4TX4pd2HDR4Z9RKTBxQsl9l4xzEjYBMyuVLGV/I6wqU5eBUjQOrSe eF18pOwyj32UVUWqj1jOFuB1ea3hcSIUNe1rpuK0ZGoiXyJ1m0Lgw+ItWRKvP3N/gOqnCD wh5Koe6STXnWC7MnFJ6q20CVgo04p48= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1670428777; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=3ds86l2H1ZNflWHy4/S2aLn7l+F5D9ot2q/ERt4zH3Q=; b=ZQooae21RRhNfwRs8sP1Y+zABPdUBxfmG1+4kKBy848nEJIhQxT/fUko4F7Oi+FSk3Qjmd ypSHeVE9nMF+QI5EmYUwsqW0DDkbaBoWCzMZKhdYqGGeI72M9A8kVHUIZiN4SDIhWV1ZDO rSn0tohQh+t4+vFM7pTuXs/FwXHSlkU= Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-102-qGSBzZj3Ndq2yZdel44dLA-1; Wed, 07 Dec 2022 10:59:36 -0500 X-MC-Unique: qGSBzZj3Ndq2yZdel44dLA-1 Received: by mail-qt1-f198.google.com with SMTP id fz10-20020a05622a5a8a00b003a4f466998cso39047060qtb.16 for ; Wed, 07 Dec 2022 07:59:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=3ds86l2H1ZNflWHy4/S2aLn7l+F5D9ot2q/ERt4zH3Q=; b=sJJ0ZsCWJjo5w6sLG+4YfeY34OiGnBXPtPzT3WpCw8+o6016QL+pYnA5dT7X4PQ4QS QBYqH/qjRdYo6Nli5oxAIyokNQ3e/4H1qcHlv/Q0q1qMlOoVrI21BjFW9jlKqJQ3b2bQ Mq4K9bdkWQ3Xvu15IGbVkEXUANkRFVe7hhdzHfi8zxBOiltKkIJ6aHOgMof/4MMpACsW 9/vtjCkDk4Bc9p2Sm9ibHFjFaBbeI1VABKMruooMvjdVYQa3/vIBSawHcUZq7YX2aTwZ +ie5AwYL1LyzKnfdzruCuRAmfrBbUjO2NzV55HGqBgHpGUURP0cjiZEfo1drRqIlxAW8 j0Pg== X-Gm-Message-State: ANoB5pl53qWxndaCaZ1ZNq9P05AgqmL8IAxXihTKCk0vutAMCMoyZ+OY bVlfyKoS30idUBrrxrVw+EuwW036aIXFQaDdCvjRuOSGYjpgFAJSupPdNiaC+CFgEkmQsMbgKzy HVBZVC2YDTv4= X-Received: by 2002:a05:6214:2b97:b0:4c7:734a:9047 with SMTP id kr23-20020a0562142b9700b004c7734a9047mr1202642qvb.50.1670428776080; Wed, 07 Dec 2022 07:59:36 -0800 (PST) X-Google-Smtp-Source: AA0mqf56ieISDBHezYDAzZ+VpWdZ5V6o2u1bx+Hff3p4ac7yFjt3BUL6MXewhOVSKr+NI9MhWdKWhA== X-Received: by 2002:a05:6214:2b97:b0:4c7:734a:9047 with SMTP id kr23-20020a0562142b9700b004c7734a9047mr1202631qvb.50.1670428775800; Wed, 07 Dec 2022 07:59:35 -0800 (PST) Received: from x1n (bras-base-aurron9127w-grc-46-70-31-27-79.dsl.bell.ca. [70.31.27.79]) by smtp.gmail.com with ESMTPSA id bj7-20020a05620a190700b006cfc1d827cbsm17170597qkb.9.2022.12.07.07.59.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Dec 2022 07:59:35 -0800 (PST) Date: Wed, 7 Dec 2022 10:59:34 -0500 From: Peter Xu To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Ives van Hoorne , stable@vger.kernel.org, Andrew Morton , Hugh Dickins , Alistair Popple , Mike Rapoport , Nadav Amit , Andrea Arcangeli Subject: Re: [PATCH RFC] mm/userfaultfd: enable writenotify while userfaultfd-wp is enabled for a VMA Message-ID: References: <20221202122748.113774-1-david@redhat.com> <690afe0f-c9a0-9631-b365-d11d98fdf56f@redhat.com> <19800718-9cb6-9355-da1c-c7961b01e922@redhat.com> <92173bad-caa3-6b43-9d1e-9a471fdbc184@redhat.com> <5a626d30-ccc9-6be3-29f7-78f83afbe5c4@redhat.com> MIME-Version: 1.0 In-Reply-To: <5a626d30-ccc9-6be3-29f7-78f83afbe5c4@redhat.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 33233160016 X-Stat-Signature: fbbibshkzxz35qydzdojuu4ie4arzatu X-Spamd-Result: default: False [-0.90 / 9.00]; BAYES_HAM(-6.00)[100.00%]; SORBS_IRL_BL(3.00)[209.85.160.198:received]; SUSPICIOUS_RECIPS(1.50)[]; MID_RHS_NOT_FQDN(0.50)[]; MIME_GOOD(-0.10)[text/plain]; BAD_REP_POLICIES(0.10)[]; RCVD_NO_TLS_LAST(0.10)[]; DKIM_TRACE(0.00)[redhat.com:+]; RCPT_COUNT_SEVEN(0.00)[11]; FROM_EQ_ENVFROM(0.00)[]; DMARC_POLICY_ALLOW(0.00)[redhat.com,none]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; PREVIOUSLY_DELIVERED(0.00)[linux-mm@kvack.org]; R_DKIM_ALLOW(0.00)[redhat.com:s=mimecast20190719]; ARC_NA(0.00)[]; ARC_SIGNED(0.00)[hostedemail.com:s=arc-20220608:i=1]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(0.00)[+ip4:170.10.133.0/24]; TO_DN_SOME(0.00)[]; TAGGED_RCPT(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[] X-Rspam-User: X-HE-Tag: 1670428778-230206 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 Wed, Dec 07, 2022 at 02:33:58PM +0100, David Hildenbrand wrote: > On 06.12.22 22:27, Peter Xu wrote: > > On Tue, Dec 06, 2022 at 05:28:07PM +0100, David Hildenbrand wrote: > > > > If no one is using mprotect() with uffd-wp like that, then the reproducer > > > > may not be valid - the reproducer is defining how it should work, but does > > > > that really stand? That's why I said it's ambiguous, because the > > > > definition in this case is unclear. > > > > > > There are interesting variations like: > > > > > > mmap(PROT_READ, MAP_POPULATE|MAP_SHARED) > > > uffd_wp() > > > mprotect(PROT_READ|PROT_WRITE) > > > > > > Where we start out with all-write permissions before we enable selective > > > write permissions. > > > > Could you elaborate what's the difference of above comparing to: > > > > mmap(PROT_READ|PROT_WRITE, MAP_POPULATE|MAP_SHARED) > > uffd_wp() > > > > ? > > That mapping would temporarily allow write access. I'd imagine that > something like that might be useful when atomically replacing an existing > mapping (MAP_FIXED), and the VMA might already be in use by other threads. > or when you really want to catch any possible write access. > > For example, libvhost-user.c in QEMU uses for ordinary postcopy: > > /* > * In postcopy we're using PROT_NONE here to catch anyone > * accessing it before we userfault. > */ > mmap_addr = mmap(0, dev_region->size + dev_region->mmap_offset, > PROT_NONE, MAP_SHARED | MAP_NORESERVE, > vmsg->fds[0], 0); I assume this is for missing mode only. More on wr-protect mode below. Personally I don't see immediately on whether this is needed. If the process itself is trusted then it should be under control of anyone who will be accessing the pages.. If the other threads are not trusted, then there's no way to stop anyone from mprotect(RW) after mprotect(NONE) anyway.. So I may not really get the gut of it. Another way to make sure no one access it is right after receiving the memory range from QEMU (VhostUserMemoryRegion), if VuDev.postcopy_listening is set, then we register the range with UFFD missing immediately. After all if postcopy_listening is set it means we passed the advise phase already (VHOST_USER_POSTCOPY_ADVISE). Any potential access will be blocked until QEMU starts to read on that uffd. > > I'd imagine, when using uffd-wp (VM snapshotting with shmem?) one might use > PROT_READ instead before the write-protection is properly set. Because read > access would be fine in the meantime. It'll be different for wr-protect IIUC, because unlike missing protections, we don't worry about writes happening before UFFDIO_WRITEPROTECT. IMHO the solo thing the vhost-user proc needs to do is one UFFDIO_WRITEPROTECT for each of the range when QEMU tells it to, then it'll be fine. Pre-writes are fine. Sorry I probably went a bit off-topic. I just want to make sure I don't miss any real use case of having mprotect being useful for uffd-wp being there, because that used to be a grey area for me. > > But I'm just pulling use cases out of my magic hat ;) Nothing stops user > space from doing things that are not clearly forbidden (well, even then > users might complain, but that's a different story). Yes, I think those are always fine but the user just cannot assume it'll work as they assumed how it will work. If "doing things that are not clearly forbidden" triggers a host warning or crash that's a bug, OTOH if the outcome is limited to the process itself then from kernel pov I think we're good. I used to even thought about forbid mprotect() on uffd-wp but I'm not sure whether it's good idea either. Let's see whether I missed something above, if so I'll rethink. Thanks, -- Peter Xu