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 X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D03F8C433DB for ; Sat, 9 Jan 2021 03:50:28 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0CFCF2371F for ; Sat, 9 Jan 2021 03:50:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0CFCF2371F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=sina.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 2E8C88D01CC; Fri, 8 Jan 2021 22:50:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 299678D01B7; Fri, 8 Jan 2021 22:50:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1AFB68D01CC; Fri, 8 Jan 2021 22:50:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0169.hostedemail.com [216.40.44.169]) by kanga.kvack.org (Postfix) with ESMTP id 017EF8D01B7 for ; Fri, 8 Jan 2021 22:50:26 -0500 (EST) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id BB69B4DAD for ; Sat, 9 Jan 2021 03:50:26 +0000 (UTC) X-FDA: 77684859252.23.van30_3610df4274f8 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin23.hostedemail.com (Postfix) with ESMTP id 99C9037608 for ; Sat, 9 Jan 2021 03:50:26 +0000 (UTC) X-HE-Tag: van30_3610df4274f8 X-Filterd-Recvd-Size: 2574 Received: from r3-22.sinamail.sina.com.cn (r3-22.sinamail.sina.com.cn [202.108.3.22]) by imf02.hostedemail.com (Postfix) with SMTP for ; Sat, 9 Jan 2021 03:50:21 +0000 (UTC) Received: from unknown (HELO localhost.localdomain)([123.112.55.66]) by sina.com with ESMTP id 5FF927F000005E6D; Sat, 9 Jan 2021 11:50:15 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 981910628820 From: Hillf Danton To: Jason Gunthorpe Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Yu Zhao , Andy Lutomirski , Peter Xu , Jann Horn Subject: Re: [PATCH 0/2] page_count can't be used to decide when wp_page_copy Date: Sat, 9 Jan 2021 11:49:58 +0800 Message-Id: <20210109034958.6928-1-hdanton@sina.com> In-Reply-To: <20210108181945.GF504133@ziepe.ca> References: <20210107200402.31095-1-aarcange@redhat.com> <20210107202525.GD504133@ziepe.ca> <20210108133649.GE504133@ziepe.ca> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000838, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Fri, 8 Jan 2021 14:19:45 -0400 Jason Gunthorpe wrote: >=20 > What I was trying to explain below, is I think we agreed that a page > under active FOLL_LONGTERM pin *can not* be write protected. >=20 > Establishing the FOLL_LONGTERM pin (for read or write) must *always* > break the write protection and the VM *cannot* later establish a new > write protection on that page while the pin is active. >=20 > Indeed, it is complete nonsense to try and write protect a page that > has active DMA write activity! Changing the CPU page protection bits > will not stop any DMA! Doing so will inevitably become a security > problem with an attack similar to what you described. >=20 > So this is what was done during fork() - fork will no longer write > protect pages under FOLL_LONGTERM to make them COWable, instead it > will copy them at fork time. Is it, in a step forward, unlikely for DMA write activity to happen during page copy at fork? >=20 > Any other place doing write protect must also follow these same > rules. >=20 > I wasn't aware this could be used to create a security problem, but it > does make sense. write protect really must mean writes to the memory > must stop and that is fundementally incompatible with active DMA. >=20 > Thus write protect of pages under DMA must be forbidden, as a matter > of security. >=20 > Jason