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=-2.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 2B181C433DB for ; Mon, 21 Dec 2020 18:32:10 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9D5D122D08 for ; Mon, 21 Dec 2020 18:32:09 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9D5D122D08 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id DD15A6B005C; Mon, 21 Dec 2020 13:32:08 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D82856B005D; Mon, 21 Dec 2020 13:32:08 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C977E6B0068; Mon, 21 Dec 2020 13:32:08 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0051.hostedemail.com [216.40.44.51]) by kanga.kvack.org (Postfix) with ESMTP id B2D176B005C for ; Mon, 21 Dec 2020 13:32:08 -0500 (EST) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 290051F06 for ; Mon, 21 Dec 2020 18:32:08 +0000 (UTC) X-FDA: 77618133936.12.house91_100ba6027459 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin12.hostedemail.com (Postfix) with ESMTP id 50E3818020603 for ; Mon, 21 Dec 2020 18:32:02 +0000 (UTC) X-HE-Tag: house91_100ba6027459 X-Filterd-Recvd-Size: 6784 Received: from mail-pf1-f173.google.com (mail-pf1-f173.google.com [209.85.210.173]) by imf17.hostedemail.com (Postfix) with ESMTP for ; Mon, 21 Dec 2020 18:32:01 +0000 (UTC) Received: by mail-pf1-f173.google.com with SMTP id c12so6908712pfo.10 for ; Mon, 21 Dec 2020 10:32:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HCY8w6wAd8FcQcRYUZs1swNNxWTGmV4HkMU4xhZmf5g=; b=PfmrzFqttYHr+qoFvUFefQjYiMHfeA+60gzbWd15gpG17mHkTC9KsHiFQdIuIjtj6c yewrJepM7uUGnPB5TpGejklEnCzxA3Ey0OO8Wse6VqTzWCNvXMTIZkmvYFRqHYdSfoJk N0CNw0vycja9C1HqyLM6TWWPEyMHxcFy2ch5QioPDVYLTqaaDWxZrKP3tU7mUqt3Noz8 1YlnP2pbrQzrrIfC6g5culARrcmSRbYdEfpYx+8J/uSz4hXM88DWhw3tMEIvon/csl9j piXUzoLub2Zqmzq4F215ZNxDWchtEB4LQs1Tvve1QX+zqLBNtU3RjsviIfkTsxycZfOV CwtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HCY8w6wAd8FcQcRYUZs1swNNxWTGmV4HkMU4xhZmf5g=; b=LkXpDWwpf+sQXH7tubqn9zY+br34idqLnpnW+Kv1pGHsctHpos8dNpvUU7umaNul4Q 7jxBTFefF+svV1eAKQuM9+AF8/sfWEdCY0RfGlgJ2PqVEp/Kri0G1g8KnQ+wJQYfVrcq hwPIh8pS1aZ0w5CHv8071Fr3ShdWYX8Notq5Tp6BpbcvJXJCvN2q/iB7FdruNzTCXL+F Trvs+6+929T5sEOqrwSQKCVS4iQ6N1dxet7L+YfBqz74di7ybXhzPrUxM0eLkh1gzTZa gijrAF5kPQBcI9IAGmP5hkqG7YtqLVuTf0NDocf696WiT3otah0DvWQbbpfr8obwDidK q/tg== X-Gm-Message-State: AOAM5324tpD3HNIPE2Z0ctcMXGo7a1R1Yf+sXLuq0iKotmXGyV8YHOpa CXAlAi/h96jdTb3cw8EExDo= X-Google-Smtp-Source: ABdhPJzDuUUuKqtLU7584aeLXqn4qvLTbBvwOuj3NGYyNc7XzZ5zLZRRkrrvAtr+sUMza55iYtZriw== X-Received: by 2002:a63:1d12:: with SMTP id d18mr16202857pgd.314.1608575520652; Mon, 21 Dec 2020 10:32:00 -0800 (PST) Received: from ?IPv6:2601:647:4700:9b2:104c:8d35:de28:b8dc? ([2601:647:4700:9b2:104c:8d35:de28:b8dc]) by smtp.gmail.com with ESMTPSA id k21sm16041734pfu.7.2020.12.21.10.31.58 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 21 Dec 2020 10:31:59 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Subject: Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect From: Nadav Amit In-Reply-To: <20201221172711.GE6640@xz-x1> Date: Mon, 21 Dec 2020 10:31:57 -0800 Cc: Yu Zhao , Andrea Arcangeli , linux-mm , lkml , Pavel Emelyanov , Mike Kravetz , Mike Rapoport , stable@vger.kernel.org, minchan@kernel.org, Andy Lutomirski , Will Deacon , Peter Zijlstra Content-Transfer-Encoding: quoted-printable Message-Id: <76B4F49B-ED61-47EA-9BE4-7F17A26B610D@gmail.com> References: <20201219043006.2206347-1-namit@vmware.com> <20201221172711.GE6640@xz-x1> To: Peter Xu X-Mailer: Apple Mail (2.3608.120.23.2.4) 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 Dec 21, 2020, at 9:27 AM, Peter Xu wrote: >=20 > Hi, Nadav, >=20 > On Sun, Dec 20, 2020 at 12:06:38AM -0800, Nadav Amit wrote: >=20 > [...] >=20 >> So to correct myself, I think that what I really encountered was = actually >> during MM_CP_UFFD_WP_RESOLVE (i.e., when the protection is removed). = The >> problem was that in this case the =E2=80=9Cwrite=E2=80=9D-bit was = removed during unprotect. >> Sorry for the strange formatting to fit within 80 columns: >=20 > I assume I can ignore the race mentioned in the commit message but = only refer > to this one below. However I'm still confused. Please see below. >=20 >> [ Start: PTE is writable ] >>=20 >> cpu0 cpu1 cpu2 >> ---- ---- ---- >> [ Writable PTE=20= >> cached in TLB = ] >=20 > Here cpu2 got writable pte in tlb. But why? >=20 > If below is an unprotect, it means it must have been protected once by > userfaultfd, right? If so, the previous change_protection_range() = which did > the wr-protect should have done a tlb flush already before it returns = (since > pages>0 - we protected one pte at least). Then I can't see why cpu2 = tlb has > stall data. Thanks, Peter. Just as you can munprotect() a region which was not = protected before, you can ufff-unprotect a region that was not protected before. = It might be that the user tried to unprotect a large region, which was partially protected and partially unprotected. The selftest obviously blindly unprotect some regions to check for bugs. So to your question - it was not write-protected (think about initial = copy without write-protecting). > If I assume cpu2 doesn't have that cached tlb, then "write to old = page" won't > happen either, because cpu1/cpu2 will all go through the cow path and = pgtable > lock should serialize them. >=20 >> userfaultfd_writeprotect() =09 >> [ write-*unprotect* ] >> mwriteprotect_range() >> mmap_read_lock() >> change_protection() >>=20 >> change_protection_range() >> ... >> change_pte_range() >> [ *clear* =E2=80=9Cwrite=E2=80=9D-bit ] >> [ defer TLB flushes] >> [ page-fault ] >> =E2=80=A6 >> wp_page_copy() >> cow_user_page() >> [ copy page ] >> [ write to old >> page ] >> =E2=80=A6 >> set_pte_at_notify() >>=20 >> [ End: cpu2 write not copied form old to new page. ] >=20 > Could you share how to reproduce the problem? I would be glad to give = it a > shot as well. You can run the selftests/userfaultfd with my small patch [1]. I ran it = with the following parameters: =E2=80=9C ./userfaultfd anon 100 100 =E2=80=9C. = I think that it is more easily reproducible with =E2=80=9Cmitigations=3Doff idle=3Dpoll=E2=80= =9D as kernel parameters. [1] https://lore.kernel.org/patchwork/patch/1346386/ >=20 >> [1] https://lore.kernel.org/patchwork/patch/1346386 >=20 > PS: Sorry to not have read the other series of yours. It seems to = need some > chunk of time so I postponed it a bit due to other things; but I'll = read at > least the fixes very soon. Thanks again, I will post RFCv2 with some numbers soon.