Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp1205419pxb; Sat, 9 Jan 2021 11:06:49 -0800 (PST) X-Google-Smtp-Source: ABdhPJw0c3zMsnTUH9HtDnNglHBejf9qIIRK6EAtli9RZgKCzyWExatE3M5XIG/Yq+CdHqhFdeb8 X-Received: by 2002:a50:c053:: with SMTP id u19mr9172709edd.109.1610219209523; Sat, 09 Jan 2021 11:06:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610219209; cv=none; d=google.com; s=arc-20160816; b=SHQb/aEekiQFea5ImByHHDVThM3Pd2Q0Ek8UqwM5KYPJhcBrulmFOSzQArm8tvkw9n dU6JM05qK0logYB/STGZeGQikjnmf8u5j/Hmb2jnCKYg0l/UfNkcvgYShBBKzg1PQfCX VZMKpH59vxr20q1GedjgtzgNDawq4XwKHjS/Yi8cKBH6a5H4eT3HvXU2bYfY6R2/H9+j wdfUwhYn1u9a+HKaXPvhtdT5keK8lRO+F6EbS5SahIcN9z+XSduPx5k8qYq3dd1DUvc+ XFw311cyjcLAxOkVnzHgbcGuNSVsf2LHYKvFvwviUp7qMTqlW7t1KKVVtl9eoX2sj9Lo njDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=CoIBo8+U3WoCyjNTquklijUduTZ2+oRbUnFXwG1wFLs=; b=eq3O3H7MQ4NpqQ7dX5mBFc1nI6t6nsEE13towYMhqSTe0KhFwnaSlFSAutxVvVnhXA BOM8qOUeEdfOkvNSEVBNk8m4ds5uCEAiYic7mqchGXD/r5TarPecPB+VSYbRQFFGowIk FxFGjJ13JU1KjceTdKpJDBerjDpITHkxjPTJg69PSW9pJkc7duTG/8N2Vyw1LUMCBymp ddoQq23QPL46qR+H79Gh5ur7HfttbhE9uilsFim2Mof1ruLOrJFbMZ6CIpTgs5KUKLjw iNWQNBNkJ+ieGocIeWKmLq6z0FhIrqFuLQqt65yI5sE6314hpejcC6VNrjncW5g+Ebsk v7+Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=DPsiQFZx; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u10si4742581ejm.606.2021.01.09.11.06.25; Sat, 09 Jan 2021 11:06:49 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=DPsiQFZx; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726210AbhAITET (ORCPT + 99 others); Sat, 9 Jan 2021 14:04:19 -0500 Received: from mail.kernel.org ([198.145.29.99]:48126 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726001AbhAITES (ORCPT ); Sat, 9 Jan 2021 14:04:18 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 642B02399C for ; Sat, 9 Jan 2021 19:03:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1610219017; bh=ffd/mc0gPcQXGXWeFlO/46TTv2fQp5rKnaxPu7uNZzk=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=DPsiQFZx04z7n/fUiAdVs5KhMDbhVOH4AU4tC/3vuXSO+hjfEnW7/lffN2CQA/aj6 U2wrtDFiQYdBOR3VyxV2tEeweZOBAfLzb5uAAL0755E5snjwlUSfqz4WkH009jT03R oRkW3T1noC5SkFpd7X5wJXYUxErnc7H+PRF3IZoEN6rinqdqRXNMv6bhIQ3wPgdxo2 plXR1Bh2/9Z7hFu6dgBKOstb3DhlqRwvHPbNehNnSSnyitzausOUSvaYX+5IshHKvn 5+8PdmLz7IfLvNOpf+LBucWKSHLavrnLx3QPKmPMlST4n7klQekRENSn0fP6qeh2np m1U/Jax+O5f2w== Received: by mail-ed1-f50.google.com with SMTP id c7so14617552edv.6 for ; Sat, 09 Jan 2021 11:03:37 -0800 (PST) X-Gm-Message-State: AOAM530RS1gAYNJWmC7mjqdMcjjWbb/3FdePaOIUwD/sdbacL5JtElLV 3drxtIxBFIA6i902qh7M4YZRJfnRq/Vbo5V9i/82BA== X-Received: by 2002:a05:6402:229b:: with SMTP id cw27mr9132586edb.23.1610219015935; Sat, 09 Jan 2021 11:03:35 -0800 (PST) MIME-Version: 1.0 References: <20210107200402.31095-1-aarcange@redhat.com> <20210107202525.GD504133@ziepe.ca> <20210108133649.GE504133@ziepe.ca> <20210108181945.GF504133@ziepe.ca> In-Reply-To: From: Andy Lutomirski Date: Sat, 9 Jan 2021 11:03:23 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 0/2] page_count can't be used to decide when wp_page_copy To: Andrea Arcangeli Cc: Andy Lutomirski , Jason Gunthorpe , Linux-MM , LKML , Yu Zhao , Peter Xu , Pavel Emelyanov , Mike Kravetz , Mike Rapoport , Minchan Kim , Will Deacon , Peter Zijlstra , Linus Torvalds , Hugh Dickins , "Kirill A. Shutemov" , Matthew Wilcox , Oleg Nesterov , Jann Horn , Kees Cook , John Hubbard , Leon Romanovsky , Jan Kara , Kirill Tkhai Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Jan 8, 2021, at 3:34 PM, Andrea Arcangeli wrote: > > =EF=BB=BFOn Fri, Jan 08, 2021 at 10:31:24AM -0800, Andy Lutomirski wrote: >> Can we just remove vmsplice() support? We could make it do a normal > >> copy, thereby getting rid of a fair amount of nastiness and potential >> attacks. Even ignoring issues relating to the length of time that the >> vmsplice reference is alive, we also have whatever problems could be >> caused by a malicious or misguided user vmsplice()ing some memory and >> then modifying it. > > Sorry to ask but I'm curious, what also goes wrong if the user > modifies memory under GUP pin from vmsplice? That's not obvious to > see. It breaks the otherwise true rule that the data in pipe buffers is immutable. Even just quoting the manpage: SPLICE_F_GIFT The user pages are a gift to the kernel. The application = may not modify this memory ever, otherwise the page cache and = on- disk data may differ. That's no good. I can also imagine use cases in which modified vmsplice() pages that end up in various parts of the network stack could be problematic. For example, if you can arrange for TCP or, worse, TLS to transmit data and then retransmit modified data, you might get odd results. In the latter case, some security properties of TLS might be broken. --Andy