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=-6.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 D0A1EC433DB for ; Tue, 22 Dec 2020 20:19:28 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 458F0229C5 for ; Tue, 22 Dec 2020 20:19:28 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 458F0229C5 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B68A26B0098; Tue, 22 Dec 2020 15:19:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AF1D16B009E; Tue, 22 Dec 2020 15:19:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9E1C48D0003; Tue, 22 Dec 2020 15:19:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0177.hostedemail.com [216.40.44.177]) by kanga.kvack.org (Postfix) with ESMTP id 847776B0098 for ; Tue, 22 Dec 2020 15:19:27 -0500 (EST) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 40C94181AC544 for ; Tue, 22 Dec 2020 20:19:27 +0000 (UTC) X-FDA: 77622033174.12.mist59_550c3f327462 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin12.hostedemail.com (Postfix) with ESMTP id 23A4218026C29 for ; Tue, 22 Dec 2020 20:19:27 +0000 (UTC) X-HE-Tag: mist59_550c3f327462 X-Filterd-Recvd-Size: 5245 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf15.hostedemail.com (Postfix) with ESMTP for ; Tue, 22 Dec 2020 20:19:26 +0000 (UTC) Received: by mail.kernel.org (Postfix) with ESMTPSA id 6551022D57 for ; Tue, 22 Dec 2020 20:19:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1608668365; bh=mXrauKSE9SR6fvVV4uNsc75DoOCwPZAdIHnBX7if57M=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=aEwxO/bFWk3IH/MxTKqrjzFlAnchKQNCXcXVz5B529HTN4x2fmzTXjf8xJjN/uldl fc6EX/84JFTXxFGnzli6OAL5KavuHZl4veW5AfmtlXBezn+bKB3HHxXuXFkBULbvoo lx1pw4beDG9SeRmTML1dMDFWKYKFeiBSsYldq7oDaqgSP7zW3V9TlmsfwnizhkbF2f eNvQAc0HQ5U8YQ7xd7N7MmPa9FKBZ27KEWNYTc5vxqm/iJq+wyhTHjeSIkS8RE9JGo itH9HPZONETy9Ntd6nUgZFl3qeQIALwVfTFef6C4QzYKPwo2PnFqUKV7vvPlttK09t t9JSRb6eGVYOQ== Received: by mail-wr1-f44.google.com with SMTP id i9so15861125wrc.4 for ; Tue, 22 Dec 2020 12:19:25 -0800 (PST) X-Gm-Message-State: AOAM5300j4RhdkTae63du4RQeyw8rWB4NVCZNxMWU/9orYdn9ctGufjf a9EeoI+qGN4g7Al0wtfbL9lmGedq02NmHEPFTN/WgQ== X-Google-Smtp-Source: ABdhPJz6jcNMaCJEbA/qYO2R4S8Dxtkj7kmxvWhr/9NQt2mGn5LTdId4WdOeqrSgFEr9UzhLFIEXP10x0wfqWAT6xLI= X-Received: by 2002:adf:e64b:: with SMTP id b11mr25822587wrn.257.1608668363950; Tue, 22 Dec 2020 12:19:23 -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: Andy Lutomirski Date: Tue, 22 Dec 2020 12:19:11 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect To: Linus Torvalds Cc: Andy Lutomirski , Peter Xu , Nadav Amit , Yu Zhao , Andrea Arcangeli , linux-mm , lkml , Pavel Emelyanov , Mike Kravetz , Mike Rapoport , stable , Minchan Kim , 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 8:16 PM Linus Torvalds wrote: > > On Mon, Dec 21, 2020 at 7:19 PM Andy Lutomirski wrote: > > > > Ugh, this is unpleasantly complicated. > > What I *should* have said is that *because* userfaultfd is changing > the VM layout, it should always act as if it had to take the mmap_sem > for writing, and that the RW->RO change is an example of when > downgrading that write-lock to a read lock is simply not valid - > because it basically breaks the rules about what a lookup (ie a read) > can do. > > A lookup can never turn a writable page non-writable. A lookup - > through COW - _can_ turn a read-only page writable. So that's why > "RO->RW" can be ok under the read lock, but RW->RO is not. > > Does that clarify the situation when I phrase it that way instead? It's certainly more clear, but I'm still not thrilled with a bunch of functions in different files maintained by different people that cooperate using an undocumented lockless protocol. It makes me nervous from a maintainability standpoint even if the code is, in fact, entirely correct. But I didn't make my question clear either: when I asked about mark_screen_rdonly(), I wasn't asking about locking or races at all. mark_screen_rdonly() will happily mark *any* PTE readonly. I can easily believe that writable mappings of non-shared mappings all follow the same CoW rules in the kernel and that, assuming all the locking is correct, marking them readonly is conceptually okay. But shared mappings are a whole different story. Is it actually the case that all, or even most, drivers and other sources of shared mappings will function correctly if one of their PTEs becomes readonly behind their back? Or maybe there are less bizarre ways for this to happen without vm86 shenanigans and this is completely safe after all. P.S. This whole mess reminds me that I need to take a closer look at the upcoming SHSTK code. Shadow stack pages violate all common sense about how the various PTE bits work.