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.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 B3000C433ED for ; Wed, 7 Apr 2021 13:21:59 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1C762613CC for ; Wed, 7 Apr 2021 13:21:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1C762613CC Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.cz Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8E41F6B007E; Wed, 7 Apr 2021 09:21:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8BA9F6B0080; Wed, 7 Apr 2021 09:21:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 75B6D6B0081; Wed, 7 Apr 2021 09:21:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0219.hostedemail.com [216.40.44.219]) by kanga.kvack.org (Postfix) with ESMTP id 585E66B007E for ; Wed, 7 Apr 2021 09:21:58 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 14C4F8248047 for ; Wed, 7 Apr 2021 13:21:58 +0000 (UTC) X-FDA: 78005633916.28.FC4EE23 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf29.hostedemail.com (Postfix) with ESMTP id ECFC4DC for ; Wed, 7 Apr 2021 13:21:55 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 2220AB08C; Wed, 7 Apr 2021 13:21:56 +0000 (UTC) To: Linus Torvalds , Suren Baghdasaryan , Peter Xu Cc: stable , Greg Kroah-Hartman , Jann Horn , Kirill Tkhai , Shaohua Li , Nadav Amit , Linux-MM , Linux Kernel Mailing List , Android Kernel Team , Andrea Arcangeli , David Hildenbrand , Jason Gunthorpe References: <20210401181741.168763-1-surenb@google.com> From: Vlastimil Babka Subject: Re: [PATCH 0/5] 4.14 backports of fixes for "CoW after fork() issue" Message-ID: Date: Wed, 7 Apr 2021 15:21:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: ECFC4DC X-Stat-Signature: 8dqrnphbo65nyeoxioxnkqubf7dp8ros Received-SPF: none (suse.cz>: No applicable sender policy available) receiver=imf29; identity=mailfrom; envelope-from=""; helo=mx2.suse.de; client-ip=195.135.220.15 X-HE-DKIM-Result: none/none X-HE-Tag: 1617801715-299976 Content-Transfer-Encoding: quoted-printable 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 4/1/21 8:59 PM, Linus Torvalds wrote: > On Thu, Apr 1, 2021 at 11:17 AM Suren Baghdasaryan = wrote: Thanks Suren for bringing this up! >> We received a report that the copy-on-write issue repored by Jann Horn= in >> https://bugs.chromium.org/p/project-zero/issues/detail?id=3D2045 is st= ill >> reproducible on 4.14 and 4.19 kernels (the first issue with the reprod= ucer >> coded in vmsplice.c). Note that even upstream AFAIK still has the issue unfixed when Jann's rep= roducer is converted to use THPs, as Andrea has shown in https://lore.kernel.org/linux-mm/X%2FjgLGPgPb+Xms1t@redhat.com/ > Gaah. >=20 >> I confirmed this and also that the issue was not >> reproducible with 5.10 kernel. I tracked the fix to the following patc= h >> introduced in 5.9 which changes the do_wp_page() logic: >> >> 09854ba94c6a 'mm: do_wp_page() simplification' >=20 > The problem here is that there's a _lot_ more patches than the few you > found that fixed various other cases (THP etc). >=20 >> I backported this patch (#2 in the series) along with 2 prerequisite p= atches >> (#1 and #4) that keep the backports clean and two followup fixes to th= e main >> patch (#3 and #5). I had to skip the following fix: >> >> feb889fb40fa 'mm: don't put pinned pages into the swap cache' >> >> because it uses page_maybe_dma_pinned() which does not exists in earli= er >> kernels. Because pin_user_pages() does not exist there as well, I *thi= nk* >> we can safely skip this fix on older kernels, but I would appreciate i= f >> someone could confirm that claim. >=20 > Hmm. I think this means that swap activity can now break the > connection to a GUP page (the whole pre-pinning model), but it > probably isn't a new problem for 4.9/4.19. >=20 > I suspect the test there should be something like >=20 > /* Single mapper, more references than us and the map? */ > if (page_mapcount(page) =3D=3D 1 && page_count(page) > 2) > goto keep_locked; >=20 > in the pre-pinning days. >=20 > But I really think that there are a number of other commits you're > missing too, because we had a whole series for THP fixes for the same > exact issue. >=20 > Added Peter Xu to the cc, because he probably tracked those issues > better than I did. Let me shamelessly plug these links for illustrating what kind of minefie= ld we would be going into backporting this. Also for references what not to mis= s, and what may still become broken afterwards: https://lwn.net/Articles/849638/ https://lwn.net/Articles/849876/ > So NAK on this for now, I think this limited patch-set likely > introduces more problems than it fixes. I personally think there are only two options safe enough for stable back= ports (so that not more harm is caused than actually prevented). 1) Ignore the issue (outside of Android at least). The security model of = zygote is unusual. Where else a parent of fork() doesn't trust the child, which = is the same binary? BTW, I think the CVE description is very misleading: https://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2020-29374 "does not properly consider the semantics of read operations and therefor= e can grant unintended write access" - the bug was never about an unintended wr= ite access, but about an info leak from parent to child, no? 2) For backports go with the original approach of 17839856fd58 ("gup: doc= ument and work around "COW can break either way" issue"), thus break COW during= the GUP. But only for vmplice() so that nothing else gets broken. I think 5.4= stable (another LTS) actually backported only 17839856fd58 out of everything els= e, so it should have even the THP case covered, but its userfaultfd() is now pr= obably broken... > Linus >=20