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 2B397C43461 for ; Mon, 10 May 2021 14:55:54 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3B5B961490 for ; Mon, 10 May 2021 14:55:53 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3B5B961490 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ffwll.ch Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id AD56F6B0072; Mon, 10 May 2021 10:55:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A84876B0073; Mon, 10 May 2021 10:55:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9265F6B0074; Mon, 10 May 2021 10:55:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0003.hostedemail.com [216.40.44.3]) by kanga.kvack.org (Postfix) with ESMTP id 774CB6B0072 for ; Mon, 10 May 2021 10:55:52 -0400 (EDT) Received: from smtpin34.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 2F65B9079 for ; Mon, 10 May 2021 14:55:52 +0000 (UTC) X-FDA: 78125620944.34.9CF1233 Received: from mail-oi1-f178.google.com (mail-oi1-f178.google.com [209.85.167.178]) by imf28.hostedemail.com (Postfix) with ESMTP id 636B62000241 for ; Mon, 10 May 2021 14:55:50 +0000 (UTC) Received: by mail-oi1-f178.google.com with SMTP id i81so16044194oif.6 for ; Mon, 10 May 2021 07:55:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ffwll.ch; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AS9nf1QYyUIyVs6RoQO80MpiosKSnnivAT6Yx1y7KWk=; b=hmsr1/zRUNvK9mnHaZO5y60A+AHPfdNmIzBpb36meUCTFqPyF8BCSJoWzz+dwjMUBf sOjdtYrpYb+U2KZI8AgQCSNXM2B/sYEWnAXVW22VgufrTpS6Oub6U+k8pKNHLR9od9pY 2JvWfGFLyMOvQgqNRMzpvCJTe8mmXm86mDSsk= 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=AS9nf1QYyUIyVs6RoQO80MpiosKSnnivAT6Yx1y7KWk=; b=pwdBlaSBo0mRqV8OG4TEbB9OSAijmv2RTciWPUHcIaZ0N07ddjACSqRkr+xfmeFcjC uIsazLII+3U3wP36f83OwJnR5NhYFf+vx3zHEZ7UchmKqlzvarC2MEaRxioeVFUllE3N hcAwgSVNCmlJ6B675hys9YmJM/JYGgWxXWjglfDlG01eup/Ulk58wNjuMNKFOyoQTYyw x/JBjCtFUQV88BTyuAGxFv2m6GrFAizXi6nJktd0by8LZk8CsSmWKaRonXjdTlOdMLjJ T6TGSfEOi6AhlMsBOYTxBIjm3K1uACQSrNTUSEeO+IOVZ+fQUVApPACqlMR+jGJSqy2M m2CQ== X-Gm-Message-State: AOAM530zrUMRGyfIjUDZPwid9d5V1CQE17oT+S4NwMRDHjb0A0ktn9nS i7PaSWxXQ8Pq4hMoeDkKd1HyStRDj8pQxlv7NSabdw== X-Google-Smtp-Source: ABdhPJwfEDQZPJA0WzNIzsQAkshxoJAbrMEAjUNsMGt80dwxzz47vaaAr7fiCJX7iaqPc8WdsMULsSopfEIfRAdTCGQ= X-Received: by 2002:aca:df87:: with SMTP id w129mr18413978oig.128.1620658550366; Mon, 10 May 2021 07:55:50 -0700 (PDT) MIME-Version: 1.0 References: <20210510135031.GF2047089@ziepe.ca> In-Reply-To: <20210510135031.GF2047089@ziepe.ca> From: Daniel Vetter Date: Mon, 10 May 2021 16:55:39 +0200 Message-ID: Subject: Re: [PULL] topic/iomem-mmap-vs-gup To: Jason Gunthorpe Cc: Linus Torvalds , Tomasz Figa , Marek Szyprowski , Mauro Carvalho Chehab , DRI Development , LKML , Linux-MM , Linux ARM , Linux Media Mailing List , linux-samsung-soc Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam01 Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=ffwll.ch header.s=google header.b="hmsr1/zR"; spf=none (imf28.hostedemail.com: domain of daniel.vetter@ffwll.ch has no SPF policy when checking 209.85.167.178) smtp.mailfrom=daniel.vetter@ffwll.ch; dmarc=none X-Stat-Signature: oybggggi1zywp115outg4gzpazsmdzsz X-Rspamd-Queue-Id: 636B62000241 Received-SPF: none (ffwll.ch>: No applicable sender policy available) receiver=imf28; identity=mailfrom; envelope-from=""; helo=mail-oi1-f178.google.com; client-ip=209.85.167.178 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1620658550-163616 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, May 10, 2021 at 3:50 PM Jason Gunthorpe wrote: > > On Sat, May 08, 2021 at 09:46:41AM -0700, Linus Torvalds wrote: > > > I think follow_pfn() is ok for the actual "this is not a 'struct page' > > backed area", and disabling that case is wrong even going forward. > > Every place we've audited using follow_pfn() has been shown to have > some use-after-free bugs like Daniel describes, and a failure to check > permissions bug too. > > All the other follow_pfn() users were moved to follow_pte() to fix the > permissions check and this shifts the use-after-free bug away from > being inside an MM API and into the caller mis-using the API by, say, > extracting and using the PFN outside the pte lock. > > eg look at how VFIO wrongly uses follow_pte(): > > static int follow_fault_pfn() > ret = follow_pte(vma->vm_mm, vaddr, &ptep, &ptl); > *pfn = pte_pfn(*ptep); > pte_unmap_unlock(ptep, ptl); > > // no protection that pte_pfn() is still valid! > use_pfn(*pfn) > > v4l is the only user that still has the missing permissions check > security bug too - so there is no outcome that should keep > follow_pfn() in the tree. > > At worst v4l should change to follow_pte() and use it wrongly like > VFIO. At best we should delete all the v4l stuff. yeah vfio is still broken for the case I care about. I think there's also some questions open still about whether kvm really uses mmu_notifier in all cases correctly, but iirc the one exception was s390, which didn't have pci mmap and that's how it gets away with that specific problem. > Daniel I suppose we missed this relation to follow_pte(), so I agree > that keeping a unsafe_follow_pfn() around is not good. tbh I never really got the additional issue with the missing write checks. That users of follow_pfn (or well follow_pte + immediate lock dropping like vfio) don't subscribe to the pte updates in general is the bug I'm seeing. That v4l also glosses over the read/write access stuff is kinda just the icing on the cake :-) It's pretty well broken even if it would check that. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch