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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A57F7C19F2D for ; Tue, 9 Aug 2022 20:06:31 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DAE368E0003; Tue, 9 Aug 2022 16:06:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D5DF48E0001; Tue, 9 Aug 2022 16:06:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BFE3D8E0003; Tue, 9 Aug 2022 16:06:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id AA2058E0001 for ; Tue, 9 Aug 2022 16:06:30 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 5A03012111C for ; Tue, 9 Aug 2022 20:06:30 +0000 (UTC) X-FDA: 79781136540.17.542FBF7 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf21.hostedemail.com (Postfix) with ESMTP id E086C1C005E for ; Tue, 9 Aug 2022 20:06:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1660075589; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=tnFi6UtyTY9WNAK3ojJYdk14zblLhZ4ZNfoakUrtm+A=; b=FTExnaDtg0H7wCUAB0O5izMLmaE0iiT48FCuAG2gSijDPoIniQEPMUGx/jynTdFTccTleZ JWBJIj9+a8ZyUMRuzp3fOviNmIPRBkK+p5TNHWx8PAbLHj6VuHdyZV8wXomjFIW9QqRdem FvN/YEtRdrvdv1vr+BKr0lQ9WKt1Dug= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-127-bZwrpIYoPmqHvpAKuuo4BQ-1; Tue, 09 Aug 2022 16:06:28 -0400 X-MC-Unique: bZwrpIYoPmqHvpAKuuo4BQ-1 Received: by mail-wr1-f70.google.com with SMTP id n7-20020adfc607000000b0021a37d8f93aso2017967wrg.21 for ; Tue, 09 Aug 2022 13:06:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:organization:from:references :cc:to:content-language:subject:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc; bh=tnFi6UtyTY9WNAK3ojJYdk14zblLhZ4ZNfoakUrtm+A=; b=KAtZ6Af3B/elFxueUMsZC2dpi8Q9KBYPYRydFTl58lxIComg9MfgoVotGHZuKZjAko KhiFm63he1YHfSucS2z5GTkTTQzSwQ2SvHSGTYiavBFyeTOQEA3tOHKqgR2ERAWyzX25 ShBs/PkqZfTuJ3p4BUgUYizE4t9UK1mX+Zhbl6roehiWxsPO/J1cpvytlsYXbEaYbwR0 vn3gwMjrCcxVFP25zV0OdK09ZB+IFZtxpOJMHmtRDS1kKXdyH/ihuy1CUas3W/SP6qDv 6EBQmkORu2Cc6WSPBbA7gP3uNLNfdoXF123PV6HdT5FfqkunNkVNcAN3plN60HukwO9s FXMQ== X-Gm-Message-State: ACgBeo05xDIgA1uix6acvTv+r4xveG/IX7+slpmVJtX8z117kJzKaxkE 5s8XivLPYnrlAoRbR2FVdDG52LflJdL+ac8m1918f7xN3OONaHgIruweKws+eA3zyNP6dEjsQnI ufm4zt2g0f5s= X-Received: by 2002:a05:600c:1c83:b0:3a3:1f70:25a5 with SMTP id k3-20020a05600c1c8300b003a31f7025a5mr96412wms.54.1660075587261; Tue, 09 Aug 2022 13:06:27 -0700 (PDT) X-Google-Smtp-Source: AA6agR66DZ40NogmO6UZUwoav9+z+Te4GfHYB3lGDXDsf01sUqvkBPwo8yj0Y6XaOnjGX9a867sFmQ== X-Received: by 2002:a05:600c:1c83:b0:3a3:1f70:25a5 with SMTP id k3-20020a05600c1c8300b003a31f7025a5mr96390wms.54.1660075586937; Tue, 09 Aug 2022 13:06:26 -0700 (PDT) Received: from ?IPV6:2003:cb:c705:3700:aed2:a0f8:c270:7f30? (p200300cbc7053700aed2a0f8c2707f30.dip0.t-ipconnect.de. [2003:cb:c705:3700:aed2:a0f8:c270:7f30]) by smtp.gmail.com with ESMTPSA id a7-20020a056000100700b0021f0c0c62d1sm14231325wrx.13.2022.08.09.13.06.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Aug 2022 13:06:26 -0700 (PDT) Message-ID: <92f5352e-c903-0413-6dea-9758222c79ad@redhat.com> Date: Tue, 9 Aug 2022 22:06:25 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH v1] mm/gup: fix FOLL_FORCE COW security issue and remove FOLL_COW To: Linus Torvalds Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, stable@vger.kernel.org, Andrew Morton , Greg Kroah-Hartman , Axel Rasmussen , Peter Xu , Hugh Dickins , Andrea Arcangeli , Matthew Wilcox , Vlastimil Babka , John Hubbard , Jason Gunthorpe References: <20220808073232.8808-1-david@redhat.com> From: David Hildenbrand Organization: Red Hat In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1660075590; a=rsa-sha256; cv=none; b=RDflefacktEsX1GFXQPu85vayvMORfD13a62SDtYxXy7Hm7ShCi4Dv9vWF4hcbTNt+igVQ e1h0c/3nifXOotoBgh8FhGfFTd61b3Q9elGfCInoAcaI1spfDtadzwCTsjyImXbXBYJg3d GKszfoqjgaQrWHaWZ1RPSxJTsH6OXYg= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=FTExnaDt; spf=pass (imf21.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1660075590; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=tnFi6UtyTY9WNAK3ojJYdk14zblLhZ4ZNfoakUrtm+A=; b=DBlFaGq5PMBcSAH0maJHCkB6oDdLjaBtylbCNyxIWXTbB6l1sDEme85dkCBFdwYmoXnOfO auMKm6vxLBLrGADxzoLVnm3or4mY2v0nYzHCS7BXAikJrU2w7nKAQocx8Gpy2tZqKA4DIz v69oEqdvxA8n27EX7dtk0ezpFJpCCN0= X-Stat-Signature: amuyiyfudd7ezu5rgtdmfrthtxawiwir X-Rspamd-Queue-Id: E086C1C005E Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=FTExnaDt; spf=pass (imf21.hostedemail.com: domain of david@redhat.com designates 170.10.129.124 as permitted sender) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1660075589-179194 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 09.08.22 22:00, Linus Torvalds wrote: > On Mon, Aug 8, 2022 at 12:32 AM David Hildenbrand wrote: >> > > So I've read through the patch several times, and it seems fine, but > this function (and the pmd version of it) just read oddly to me. > >> +static inline bool can_follow_write_pte(pte_t pte, struct page *page, >> + struct vm_area_struct *vma, >> + unsigned int flags) >> +{ >> + if (pte_write(pte)) >> + return true; >> + if (!(flags & FOLL_FORCE)) >> + return false; >> + >> + /* >> + * See check_vma_flags(): only COW mappings need that special >> + * "force" handling when they lack VM_WRITE. >> + */ >> + if (vma->vm_flags & VM_WRITE) >> + return false; >> + VM_BUG_ON(!is_cow_mapping(vma->vm_flags)); > > So apart from the VM_BUG_ON(), this code just looks really strange - > even despite the comment. Just conceptually, the whole "if it's > writable, return that you cannot follow it for a write" just looks so > very very strange. > > That doesn't make the code _wrong_, but considering how many times > this has had subtle bugs, let's not write code that looks strange. > > So I would suggest that to protect against future bugs, we try to make > it be fairly clear and straightforward, and maybe even a bit overly > protective. > > For example, let's kill the "shared mapping that you don't have write > permissions to" very explicitly and without any subtle code at all. > The vm_flags tests are cheap and easy, and we could very easily just > add some core ones to make any mistakes much less critical. > > Now, making that 'is_cow_mapping()' check explicit at the very top of > this would already go a long way: > > /* FOLL_FORCE for writability only affects COW mappings */ > if (!is_cow_mapping(vma->vm_flags)) > return false; I actually put the is_cow_mapping() mapping check in there because check_vma_flags() should make sure that we cannot possibly end up here in that case. But we can spell it out with comments, doesn't hurt. > > but I'd actually go even further: in this case that "is_cow_mapping()" > helper to some degree actually hides what is going on. > > So I'd actually prefer for that function to be written something like > > /* If the pte is writable, we can write to the page */ > if (pte_write(pte)) > return true; > > /* Maybe FOLL_FORCE is set to override it? */ > if (flags & FOLL_FORCE) > return false; > > /* But FOLL_FORCE has no effect on shared mappings */ > if (vma->vm_flags & MAP_SHARED) > return false; > > /* .. or read-only private ones */ > if (!(vma->vm_flags & MAP_MAYWRITE)) > return false; > > /* .. or already writable ones that just need to take a write fault */ > if (vma->vm_flags & MAP_WRITE) > return false; > > and the two first vm_flags tests above are basically doing tat > "is_cow_mapping()", and maybe we could even have a comment to that > effect, but wouldn't it be nice to just write it out that way? > > And after you've written it out like the above, now that > > if (!page || !PageAnon(page) || !PageAnonExclusive(page)) > return false; > > makes you pretty safe from a data sharing perspective: it's most > definitely not a shared page at that point. > > So if you write it that way, the only remaining issues are the magic > special soft-dirty and uffd ones, but at that point it's purely about > the semantics of those features, no longer about any possible "oh, we > fooled some shared page to be writable". > > And I think the above is fairly legible without any subtle cases, and > the one-liner comments make it all fairly clear that it's testing. > > Is any of this in any _technical_ way different from what your patch > did? No. It's literally just rewriting it to be a bit more explicit in > what it is doing, I think, and it makes that odd "it's not writable if > VM_WRITE is set" case a bit more explicit. > > Hmm? No strong opinion. I'm happy as long as it's fixed, and the fix is robust. -- Thanks, David / dhildenb