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 80C0BC433E6 for ; Mon, 21 Dec 2020 23:38:00 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 484EE22B2D for ; Mon, 21 Dec 2020 23:38:00 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726292AbgLUXhs (ORCPT ); Mon, 21 Dec 2020 18:37:48 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43940 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725881AbgLUXhr (ORCPT ); Mon, 21 Dec 2020 18:37:47 -0500 Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EC414C0613D3 for ; Mon, 21 Dec 2020 15:37:06 -0800 (PST) Received: by mail-lf1-x12d.google.com with SMTP id m25so27651106lfc.11 for ; Mon, 21 Dec 2020 15:37:06 -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=XEUwJ1B3pcWLfpPQa7kvc+ABD9Wxu3JslOygXEvY+B8=; b=bCl/WjkG/28ydsHCZmu2DitVaP/UIuwhWRUv8tqqH3u57qnFChPk7QRY0Gm/j0xM+l QXIwccH+sYgnsJnnIQRTGBvSqky0hhZ+Wyg74kg3WSEgQ9Kgpb60E8qMgykEKt/a7ynR 5O+oTVRihSdPgZEpioYQ+5DuwGB1Vxz7Yi8OE= 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=XEUwJ1B3pcWLfpPQa7kvc+ABD9Wxu3JslOygXEvY+B8=; b=Cad8o2K9NZyAr2/UMetCifLCjzap7XfutzWIv5hO3ELsenLmp/chHfCCBqCJ0bKd45 X6hs6inUp6LJy8I9gnSBkdKDVzKdYYM9UkHWi/f48fkpMUJHdPwFOmgPe00smuDzcT4T EVpnvmLSPrU+vNSTV8TaIpB4J/kcS1E9/SQbT1i2x+k38G+6DpOw56ZbE+PrEY7z95rd 9RTA95+AorpCRNQ0y5iAtnG/dKW+aFRNLyp80m9cY9fOW1weZN41aCMt3rKAbWj5gNxM 1qX22+rqC+IijnC9dViHtJbQiS4ycOI9CjYc4L4/BJWRSBoG6CtfpsrhvICT1xcxwcmA WXCg== X-Gm-Message-State: AOAM5320PQm7WCDuqKM3lu48jvo7FquHgBO95dfyztMC4LXwC6cD7Wc0 ulIv5j2bYrZaBsWKzEnmAOxwdei4T39e/A== X-Google-Smtp-Source: ABdhPJy7eb9kPNDGW6Qt9UWt68dKOfjpv+8jc53ZFKdEk/rq2+tQbp2tdyBIVYB/gu2MuTcg+Hxl+w== X-Received: by 2002:ac2:58dc:: with SMTP id u28mr6769572lfo.332.1608593825218; Mon, 21 Dec 2020 15:37:05 -0800 (PST) Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com. [209.85.167.43]) by smtp.gmail.com with ESMTPSA id w14sm2285079lfn.169.2020.12.21.15.37.04 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Dec 2020 15:37:04 -0800 (PST) Received: by mail-lf1-f43.google.com with SMTP id o17so27771097lfg.4 for ; Mon, 21 Dec 2020 15:37:04 -0800 (PST) X-Received: by 2002:ac2:4987:: with SMTP id f7mr7298452lfl.41.1608593446798; Mon, 21 Dec 2020 15:30:46 -0800 (PST) MIME-Version: 1.0 References: <20201221172711.GE6640@xz-x1> <76B4F49B-ED61-47EA-9BE4-7F17A26B610D@gmail.com> <9E301C7C-882A-4E0F-8D6D-1170E792065A@gmail.com> <1FCC8F93-FF29-44D3-A73A-DF943D056680@gmail.com> <20201221223041.GL6640@xz-x1> In-Reply-To: From: Linus Torvalds Date: Mon, 21 Dec 2020 15:30:30 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect To: Nadav Amit Cc: Peter Xu , Yu Zhao , Andrea Arcangeli , linux-mm , lkml , Pavel Emelyanov , Mike Kravetz , Mike Rapoport , stable , Minchan Kim , Andy Lutomirski , Will Deacon , Peter Zijlstra Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Dec 21, 2020 at 2:55 PM Nadav Amit wrote: > > So as an alternative solution, I can do copying under the PTL after > flushing, which seems to solve the problem. I think that's a valid model, but note that we do the "re-check ptl" in a (*completely(* different part than we do the actual PTE install. Note that the "Re-validate under PTL" code in cow_user_page() is *not* the "now we are installing the copy". No, that's actually for the "uhhuh, the copy using the virtual address outside the ptl failed, now we need to do something special". The real "we hold teh ptl" actually happens in wp_page_copy(), after cow_user_page() has already returned. So you'd have to change how all of that works. And honestly, I'm not sure it's worth it - if this was the *only* case, then yes. But that whole "we load the original pte first, then we do whatever we _think_ we will need to do, and then we install the final pte after checking" is actually the case for every other page fault handling case too. So are we sure the COW case is so special? I really think this is clearly just a userfaultfd bug that we hadn't realized until now, and had possibly been hidden by timings or other random stuff before. Linus 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 9E033C433DB for ; Mon, 21 Dec 2020 23:30:52 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0B3FD20791 for ; Mon, 21 Dec 2020 23:30:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0B3FD20791 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 4D37A6B0068; Mon, 21 Dec 2020 18:30:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 483866B006C; Mon, 21 Dec 2020 18:30:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 37A206B006E; Mon, 21 Dec 2020 18:30:51 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0024.hostedemail.com [216.40.44.24]) by kanga.kvack.org (Postfix) with ESMTP id 18EB66B0068 for ; Mon, 21 Dec 2020 18:30:51 -0500 (EST) Received: from smtpin03.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id CF7E5181AF5C2 for ; Mon, 21 Dec 2020 23:30:50 +0000 (UTC) X-FDA: 77618886660.03.tin25_3605caf2745b Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin03.hostedemail.com (Postfix) with ESMTP id A8F9A28A4E8 for ; Mon, 21 Dec 2020 23:30:50 +0000 (UTC) X-HE-Tag: tin25_3605caf2745b X-Filterd-Recvd-Size: 5273 Received: from mail-lf1-f53.google.com (mail-lf1-f53.google.com [209.85.167.53]) by imf43.hostedemail.com (Postfix) with ESMTP for ; Mon, 21 Dec 2020 23:30:50 +0000 (UTC) Received: by mail-lf1-f53.google.com with SMTP id h205so27702685lfd.5 for ; Mon, 21 Dec 2020 15:30:50 -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=XEUwJ1B3pcWLfpPQa7kvc+ABD9Wxu3JslOygXEvY+B8=; b=bCl/WjkG/28ydsHCZmu2DitVaP/UIuwhWRUv8tqqH3u57qnFChPk7QRY0Gm/j0xM+l QXIwccH+sYgnsJnnIQRTGBvSqky0hhZ+Wyg74kg3WSEgQ9Kgpb60E8qMgykEKt/a7ynR 5O+oTVRihSdPgZEpioYQ+5DuwGB1Vxz7Yi8OE= 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=XEUwJ1B3pcWLfpPQa7kvc+ABD9Wxu3JslOygXEvY+B8=; b=X1VWOW021b1WLfxyKitW7rwcpYKfxqaaZSqAXFZOzAkP2jnjjaydWVqCaB7UAIXG/w zC2mCNyJMIp8nG0Re12xbDBB4UGHh4XOq5w0sPVGpXDWreoahc3eF9c2z0o1JQnARdSX 7+b47EwDEQhL5hdKjuVA7A1YF4RKZFVr78FG06QQBUy41A7JIKVI40tYeFIzc/i6lZ1X cECHiGNiYuY1CRtGJ24BReQaVsdVZXruBJAyarRIaoP4bV9PfMYdRioE7HSRNBfzhvBg ZWn/pNjBuxz3miLtQvETm6XxltwWeHyLtj5DraBubZNYvKXIhM4poWXqbaRQe4k1UmgC KotA== X-Gm-Message-State: AOAM530Et7dkyj3RqvVT1k87jFyoa50iy3ZN3YKZ+wCqX7rzYh4MlVYa gcYarRsyl+8aoX7nS2/9rVWnkHBJ9xkYbQ== X-Google-Smtp-Source: ABdhPJxcyKp++/wPUwn096iCqPCvyDCVAVB9YsLXsX0V33L0lRIFKIjM+qy0Xg4SGi4e+BUjHpYIqQ== X-Received: by 2002:ac2:5b03:: with SMTP id v3mr7694190lfn.634.1608593448510; Mon, 21 Dec 2020 15:30:48 -0800 (PST) Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com. [209.85.167.44]) by smtp.gmail.com with ESMTPSA id 195sm2210289lfk.109.2020.12.21.15.30.47 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Dec 2020 15:30:47 -0800 (PST) Received: by mail-lf1-f44.google.com with SMTP id m25so27624120lfc.11 for ; Mon, 21 Dec 2020 15:30:47 -0800 (PST) X-Received: by 2002:ac2:4987:: with SMTP id f7mr7298452lfl.41.1608593446798; Mon, 21 Dec 2020 15:30:46 -0800 (PST) MIME-Version: 1.0 References: <20201221172711.GE6640@xz-x1> <76B4F49B-ED61-47EA-9BE4-7F17A26B610D@gmail.com> <9E301C7C-882A-4E0F-8D6D-1170E792065A@gmail.com> <1FCC8F93-FF29-44D3-A73A-DF943D056680@gmail.com> <20201221223041.GL6640@xz-x1> In-Reply-To: From: Linus Torvalds Date: Mon, 21 Dec 2020 15:30:30 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect To: Nadav Amit Cc: Peter Xu , Yu Zhao , Andrea Arcangeli , linux-mm , lkml , Pavel Emelyanov , Mike Kravetz , Mike Rapoport , stable , Minchan Kim , Andy Lutomirski , Will Deacon , Peter Zijlstra 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 Mon, Dec 21, 2020 at 2:55 PM Nadav Amit wrote: > > So as an alternative solution, I can do copying under the PTL after > flushing, which seems to solve the problem. I think that's a valid model, but note that we do the "re-check ptl" in a (*completely(* different part than we do the actual PTE install. Note that the "Re-validate under PTL" code in cow_user_page() is *not* the "now we are installing the copy". No, that's actually for the "uhhuh, the copy using the virtual address outside the ptl failed, now we need to do something special". The real "we hold teh ptl" actually happens in wp_page_copy(), after cow_user_page() has already returned. So you'd have to change how all of that works. And honestly, I'm not sure it's worth it - if this was the *only* case, then yes. But that whole "we load the original pte first, then we do whatever we _think_ we will need to do, and then we install the final pte after checking" is actually the case for every other page fault handling case too. So are we sure the COW case is so special? I really think this is clearly just a userfaultfd bug that we hadn't realized until now, and had possibly been hidden by timings or other random stuff before. Linus