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 91C0FC433DB for ; Sat, 9 Jan 2021 19:16:07 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 222172333E for ; Sat, 9 Jan 2021 19:16:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 222172333E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 4B7576B01A2; Sat, 9 Jan 2021 14:16:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 466FC8D000C; Sat, 9 Jan 2021 14:16:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 37DC18D0002; Sat, 9 Jan 2021 14:16:06 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0117.hostedemail.com [216.40.44.117]) by kanga.kvack.org (Postfix) with ESMTP id 1FDB06B01A2 for ; Sat, 9 Jan 2021 14:16:06 -0500 (EST) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id DB671180AD80F for ; Sat, 9 Jan 2021 19:16:05 +0000 (UTC) X-FDA: 77687191890.30.dime08_0c05fb7274fd Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin30.hostedemail.com (Postfix) with ESMTP id A95DC180B3AB8 for ; Sat, 9 Jan 2021 19:16:05 +0000 (UTC) X-HE-Tag: dime08_0c05fb7274fd X-Filterd-Recvd-Size: 6441 Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.54]) by imf06.hostedemail.com (Postfix) with ESMTP for ; Sat, 9 Jan 2021 19:16:05 +0000 (UTC) Received: by mail-lf1-f54.google.com with SMTP id v67so2930519lfa.0 for ; Sat, 09 Jan 2021 11:16:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Xj+wdM4M3lEcvuGtKhWJM/1JZgF4kFJC8VcvB5NhKwQ=; b=Js+UCVunDyRvtAD/Vi2SOxakMOjEVHtBYDli/CvLZL9N2kyfy6Mh2BfhkGbmgvwG7d wVAed4qYoC9/strnC4F+u2fujRHgacUGXv0S+xOUtds7NRHfC3EqtIhxPvNnFM/po6Ea G207De9kWt0PKqoSbstfEKMde392XapWvBOaE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Xj+wdM4M3lEcvuGtKhWJM/1JZgF4kFJC8VcvB5NhKwQ=; b=Nk9k1PIDYLvAmKmpQwAD3/HlUycF1h67eyJCikIw0aAzVD7ISC77dgh5e1x6Jg78Wi Yx5ukqlklkJv4Xu2pJLgeF4ueYsBA9wMBAuytrk/ZO6WJq8jQ8LIaqjTJnXWqsGOMQZw 0Co8NpOX5TBEOHsaT5neAeRb92JBhjaw8lF6udLMSHOZtdtjeV7JEvjUndcuBg9uwPwo d2qmD+cWNqo3mvh28sm94snOKVNV4l6yXjIiyHxwD3x1cu9DGlaK/+takghC4dlkjJDV 7/P+jpwi+0bxIvhNFjf0fBKd8aL13imQqsMwOk7xNIBzUxDozlueGgLiSJ7dKPtTEJAk i06A== X-Gm-Message-State: AOAM53399KgxGTHHfTHrJKVlnKlNtkzFr4QHv4fSSBG+UuMkNvxCvOB9 GxXhoqiO+0ZABvHf4uXJ8xvjdQV00sILSQ== X-Google-Smtp-Source: ABdhPJxSv/KtX1KTpp4ONzyY6hXWrY7nAfFPlmDpfq3OzEf/S0llE5NCO0tDqIYOH9B8/MA54mJ7xA== X-Received: by 2002:a05:6512:3305:: with SMTP id k5mr3757995lfe.35.1610219762973; Sat, 09 Jan 2021 11:16:02 -0800 (PST) Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com. [209.85.167.53]) by smtp.gmail.com with ESMTPSA id j20sm2711015ljc.47.2021.01.09.11.16.01 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 09 Jan 2021 11:16:01 -0800 (PST) Received: by mail-lf1-f53.google.com with SMTP id a12so31190501lfl.6 for ; Sat, 09 Jan 2021 11:16:01 -0800 (PST) X-Received: by 2002:a2e:3211:: with SMTP id y17mr3877771ljy.61.1610219761030; Sat, 09 Jan 2021 11:16:01 -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: Linus Torvalds Date: Sat, 9 Jan 2021 11:15:45 -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: Andy Lutomirski Cc: Andrea Arcangeli , Jason Gunthorpe , Linux-MM , LKML , Yu Zhao , Peter Xu , Pavel Emelyanov , Mike Kravetz , Mike Rapoport , Minchan Kim , Will Deacon , Peter Zijlstra , 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" 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 Sat, Jan 9, 2021 at 11:03 AM Andy Lutomirski wrote: > > > > > 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. Note that this continued harping on vmsplice() is entirely misguided. Anything using GUP has the same issues. This really has nothing to do with vmsplice() per se. In many ways, vmsplice() might be the least of your issues, because it's fairly easy to just limit that for untrusted use. And no, that does not mean "we should make vmsplice root-only" kind of limiting. There are no security issues in any normal situation. Again, it's mainly about things that don't trust each other _despite_ running in similar contexts as far as the kernel is concerned. IOW, exactly that "zygote" kind of situation. If you are a JIT (whether Zygote or a web browser), you basically need to limit the things the untrusted JIT'ed code can do. And that limiting may include vmsplice(). But note the "include" part of "include vmsplice()". Any other GUP user really does have the same issues, it may just be less obvious and have very different timings (or depend on access to devices etc). Absolutely nothing cares about "data in pipe buffers changing" in any other case. You can already write any data you want to a pipe, it doesn't matter if it changes after the write or not. (In many ways, "data in the page cache" is a *much* more difficult issue for the kernel, and it's fundamental to any shared mmap. It's much more difficult because that data is obviously very much also accessible for DMA etc for writeout, and if you have something like "checksums are calculated separately and non-atomically from the actual DMA accesses", you will potentially get checksum errors where the actual disk contents don't match your separately calculated checksums until the _next_ write. This can actually be a feature - seeing "further modifications were concurrent to the write" - but most people end up considering it a bug). Linus