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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 CC47EC433DB for ; Fri, 8 Jan 2021 18:19:50 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3AED823A7A for ; Fri, 8 Jan 2021 18:19:50 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3AED823A7A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ziepe.ca Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 6FF588D018F; Fri, 8 Jan 2021 13:19:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 687948D0156; Fri, 8 Jan 2021 13:19:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 529E88D018F; Fri, 8 Jan 2021 13:19:49 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0080.hostedemail.com [216.40.44.80]) by kanga.kvack.org (Postfix) with ESMTP id 366DC8D0156 for ; Fri, 8 Jan 2021 13:19:49 -0500 (EST) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id E8F28181AEF31 for ; Fri, 8 Jan 2021 18:19:48 +0000 (UTC) X-FDA: 77683421256.04.egg38_4b01665274f4 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin04.hostedemail.com (Postfix) with ESMTP id C6639800C88F for ; Fri, 8 Jan 2021 18:19:48 +0000 (UTC) X-HE-Tag: egg38_4b01665274f4 X-Filterd-Recvd-Size: 7662 Received: from mail-qt1-f172.google.com (mail-qt1-f172.google.com [209.85.160.172]) by imf11.hostedemail.com (Postfix) with ESMTP for ; Fri, 8 Jan 2021 18:19:48 +0000 (UTC) Received: by mail-qt1-f172.google.com with SMTP id h19so7129548qtq.13 for ; Fri, 08 Jan 2021 10:19:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ziepe.ca; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=eRLIK07R5/k0ZbmMrIsckpNA62/b6A5anKQsmHzEdBY=; b=R+475cboSKr58vv5Hxs0z9t7POpKNf/xhofVv4JdASVwAwEsgcjZcJmwpLBGtHnbMI /y4gV0jyoiWjSN+CQcuhmyl+l+hLgRJ3n8luhxBPOfykD4a0qw0AlPCE+FB4nejDX9TQ QUPNKenHeiKIbLHyyFjs0Y9mS8tSfEEDX5GAJd+nbuvh94vxkaM9mxkv8owrl/qYzi7a Nyx3g4KNCyekZ5JMFw6Kwpc8DJzsP6J/gwh7eXiQJSpg/QozsRrR7jGcpij+crgr5dgc FE0j4XH2c76AMTWuGgMUuekYV/I9iVmGyjf7w7wbSoo8Jk46wn2VMC7AMes4ngH5Q9oE cSTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=eRLIK07R5/k0ZbmMrIsckpNA62/b6A5anKQsmHzEdBY=; b=uF/vuWpW/X0X3C3/jiOk3p/TMXQpUKucWzBn/6eUq5khxxY5VtL9dF0J98E/rzrc3k KDsx8Iq3IzcCx8CsDd5hmWAiCzPYZJN3PtwdgPP6KiOutg0UdZ9bPBC+uIoaNPuZ13NL n8TRTkxmcySqds5LvXS9Khn4PFuIFJGAOZCUUv+uQJlMgczlM+NvrU/QrylkuBRnLfxc z2PPbml7UdNVakX4Wkhap7c4TxRZMvlPWk06+q0Op8mDzArRsmQfHLvvPGDPSC2OkjX/ PQ8J9qa7r1zwpIQj1o3Cvz4hA3QxkPQazQSVqi0kXajNJsZfs0i8QTQH+IYkWa6oXpiI GXsw== X-Gm-Message-State: AOAM5307XMvTLkOHBAIy3JumdNYiEF4KYTbgy7deyTX9xotFa4ruCuli Qewz4CFulAOBAABQXeoWoVbfjQ== X-Google-Smtp-Source: ABdhPJyuOfC07l6KISbB7sKwd+cR+1B6S/d4qwAz+y56h3RO8A4CD+ubqr00QYTycwUsBN9/P8hF7w== X-Received: by 2002:ac8:7a81:: with SMTP id x1mr4591721qtr.373.1610129987552; Fri, 08 Jan 2021 10:19:47 -0800 (PST) Received: from ziepe.ca (hlfxns017vw-142-162-115-133.dhcp-dynamic.fibreop.ns.bellaliant.net. [142.162.115.133]) by smtp.gmail.com with ESMTPSA id d46sm4848135qtc.76.2021.01.08.10.19.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Jan 2021 10:19:46 -0800 (PST) Received: from jgg by mlx with local (Exim 4.94) (envelope-from ) id 1kxwMT-004IpK-Ik; Fri, 08 Jan 2021 14:19:45 -0400 Date: Fri, 8 Jan 2021 14:19:45 -0400 From: Jason Gunthorpe To: Andrea Arcangeli Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Yu Zhao , Andy Lutomirski , 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 Subject: Re: [PATCH 0/2] page_count can't be used to decide when wp_page_copy Message-ID: <20210108181945.GF504133@ziepe.ca> References: <20210107200402.31095-1-aarcange@redhat.com> <20210107202525.GD504133@ziepe.ca> <20210108133649.GE504133@ziepe.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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, Jan 08, 2021 at 12:00:36PM -0500, Andrea Arcangeli wrote: > > The majority cannot be converted to notifiers because they are DMA > > based. Every one of those is an ABI for something, and does not expect > > extra privilege to function. It would be a major breaking change to > > have pin_user_pages require some cap. > > ... what makes them safe is to be transient GUP pin and not long > term. > > Please note the "long term" in the underlined line. Many of them are long term, though only 50 or so have been marked specifically with FOLL_LONGTERM. I don't see how we can make such a major ABI break. Looking at it, vmsplice() is simply wrong. A long term page pin must use pin_user_pages(), and either FOLL_LONGTERM|FOLL_WRITE (write mode) FOLL_LONGTERM|FOLL_FORCE|FOLL_WRITE (read mode) ie it must COW and it must reject cases that are not longterm safe, like DAX and CMA and so on. These are the well established rules, vmsplice does not get a pass simply because it is using the CPU to memory copy as its "DMA". > speaking in practice. io_uring has similar concern but it can use mmu > notifier, so it can totally fix it and be 100% safe from this. IIRC io_uring does use FOLL_LONGTERM and FOLL_WRITE.. > The scheduler disclosure date was 2020-08-25 so I can freely explain > the case that motivated all these changes. > > case A) > > if !fork() { > // in child > mmap one page > vmsplice takes gup pin long term on such page > munmap one page > // mapcount == 1 (parent mm) > // page_count == 2 (gup in child, and parent mm) > } else { > parent writes to the page > // mapcount == 1, wp_page_reuse > } > > parent did a COW with mapcount == 1 so the parent will take over a > page that is still GUP pinned in the child. Sorry, I missed something, how does mmaping a fresh new page in the child impact the parent? I guess the issue is not to mmap but to GUP a shared page in a way that doesn't trigger COW during GUP and then munmap that page so a future parent COW does re-use, leaking access. It seems enforcing FOLL_WRITE to always COW on GUP closes this, right? This is what all correct FOLL_LONGTERM users do today, it is required for many other reasons beyond this interesting security issue. > However, you know full well in the second case it is a feature and not > a bug, that wp_page_reuse is called instead, and in fact it has to be > called or it's a bug (and that's the bug page_count in do_wp_page > introduces). 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. 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. 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. 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. Any other place doing write protect must also follow these same rules. 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. Thus write protect of pages under DMA must be forbidden, as a matter of security. Jason