From patchwork Wed Apr 10 15:55:27 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Hildenbrand X-Patchwork-Id: 13624778 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 8EC2ECD11C2 for ; Wed, 10 Apr 2024 15:56:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 973D76B00A5; Wed, 10 Apr 2024 11:56:12 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 924A26B00A6; Wed, 10 Apr 2024 11:56:12 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7EAE46B00A7; Wed, 10 Apr 2024 11:56:12 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 5F1C16B00A5 for ; Wed, 10 Apr 2024 11:56:12 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 20F641C0C17 for ; Wed, 10 Apr 2024 15:56:11 +0000 (UTC) X-FDA: 81994073742.08.6F72A58 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf02.hostedemail.com (Postfix) with ESMTP id 98DC08001A for ; Wed, 10 Apr 2024 15:56:09 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=dkZh4oMv; spf=pass (imf02.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=1712764569; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=P8ZsNI89NzeHBwo5bvI1yofxYUq5jUxcvm+li/FE14A=; b=lja1BZTL6tcC9yDYDWyEAlUG/3OXN4P02jfzC9cY6+xAEL8SLwmwho3L/FJI+Ay7QPw/Vn Tovch3sSG6EYt1fb32LJnbDCjSW2eyimuS2nFVGhv7JpWRt2eJVi0q6nSzh4W9Ujru5naA dv8TwxdckyrqtltaAH7aZqdKzCKJZXw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712764569; a=rsa-sha256; cv=none; b=7pXGprCcJshWrZtqpkDujcH/mHMqkmBiHc9X1QO/LUH14xWIg/cHP0QoFuWHoWWIR0ZsO9 pvb+RAokE/lxjJXdWg85adIVNeojSC1G2fXhYjucwlVeJyuIy7iEzzux6xrbjabYmoJgz3 SKQbJVl27tKIhQikC4CJwN0QDdj5TfQ= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=dkZh4oMv; spf=pass (imf02.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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1712764568; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=P8ZsNI89NzeHBwo5bvI1yofxYUq5jUxcvm+li/FE14A=; b=dkZh4oMv/vf3Q67wIKopWjS53RoA1TvxsQ2Km3Ap7CUM1LOl2sYjFVljHCKGfaCyAdcY4I iVK7VSDSa16G9eckvhz8aIBcWUqBrgbomQeP83gZzQ/OkSKx/Wf8xoRPYxQlvu+dEN4bS5 a1w0sz3zLtG+xo5/N21k3bBhXkKGYk0= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-591-sePtCS1xOjyfrSAEA2ASBA-1; Wed, 10 Apr 2024 11:56:04 -0400 X-MC-Unique: sePtCS1xOjyfrSAEA2ASBA-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 8930C8007BA; Wed, 10 Apr 2024 15:56:03 +0000 (UTC) Received: from t14s.fritz.box (unknown [10.39.193.162]) by smtp.corp.redhat.com (Postfix) with ESMTP id 82C97920; Wed, 10 Apr 2024 15:56:00 +0000 (UTC) From: David Hildenbrand To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, x86@kernel.org, linux-s390@vger.kernel.org, kvm@vger.kernel.org, David Hildenbrand , Andrew Morton , Yonghua Huang , Fei Li , Christoph Hellwig , Gerald Schaefer , Heiko Carstens , Ingo Molnar , Alex Williamson , Paolo Bonzini Subject: [PATCH v1 3/3] mm: follow_pte() improvements Date: Wed, 10 Apr 2024 17:55:27 +0200 Message-ID: <20240410155527.474777-4-david@redhat.com> In-Reply-To: <20240410155527.474777-1-david@redhat.com> References: <20240410155527.474777-1-david@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.1 X-Rspamd-Queue-Id: 98DC08001A X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: 4o3i6n4sructac6nwkk7db58iiskycw4 X-HE-Tag: 1712764569-811600 X-HE-Meta: U2FsdGVkX1/9cyO6kjV5fsCdzQJdTEWaKCKhTmsd31iQci9dJ3bX1chkQsysL28YBK9RaAyrlcG0jdU9mvugQKKA8RkJOgJSt7Ynbo6Xk75j/dFUMJAYosS6RtAiUjbL2sj0jfEKKwQGbD/hhZIX4Y3D8m+uHrcBalUrg8lqAp5O/33K/p1gLOHhMRE5LUWiozwM9HTimLST9leY2a8Lqb8TFxwy1+lNr3BMJ1TMhKwh09CnTXv37Bi3Uj0YM5Nr9b9CeWCWXnWGn+mqVNBTH1ZFf7cBNxtVMCnao2zVkkEJsKvQ1Av1ZGU/oXP61tugP5ufLt6P82MXuMqU4KT+apvkIq1mE+ouO9mNcYmNobErF6aLoY6DOt+C8D96rComciT27+wSxDdUKzqK5nMZt0gyoP8DI9P+E5BjWPdQS/7urkYdQbqXp/mBNcoKTO3bgpv9+JOIjUBd7DlsxYhCs706Cx3iP2Mi5ctcVs89TdDHVqBg27jKiWlKmHBbyazCn4b3qa35GOOskgFzwuvKSntlX3I7jKmdChZD9i6WdHYKoI2Q0mjpfZUjzmda6eIWOBsWpKGP/sOqR3SwJ1ulX4tudi79f9hFIdjVj4gcapo03Fi2qd0pZ8aGOJTFSGK4h8/qtb5Z1bk4ThWwAm9gTH/3dnmlhH/7Fn7HsmORe5JlB014SvgVeC4G1txw3jDCEDt8Lhe5kvKif4Q/6ixQx7OP1PvuWPRjkuBCGKzrnICViCS1PhfDHPWZYpXA/8LtuHcM1Nkr4H31IJ1uu7QYeSCMaw91OYVlREOfcWzljV6hSh5qJccukcvG4b+f29voNxV3BvxGYRGJUAhCRSflQFDCV2aMM0xDwHjuTTVF/EmoPlnL1/qTA/5zAE5HQItW8uGCrpV6I/9f+Me3bIY7spj6tciyODoW1rn6g0Pt2Rg9ZI3yEAWPIFXVng2l6rGj 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: List-Subscribe: List-Unsubscribe: follow_pte() is now our main function to lookup PTEs in VM_PFNMAP/VM_IO VMAs. Let's perform some more sanity checks to make this exported function harder to abuse. Further, extend the doc a bit, it still focuses on the KVM use case with MMU notifiers. Drop the KVM+follow_pfn() comment, follow_pfn() is no more, and we have other users nowadays. Also extend the doc regarding refcounted pages and the interaction with MMU notifiers. KVM is one example that uses MMU notifiers and can deal with refcounted pages properly. VFIO is one example that doesn't use MMU notifiers, and to prevent use-after-free, rejects refcounted pages: pfn_valid(pfn) && !PageReserved(pfn_to_page(pfn)). Protection changes are less of a concern for users like VFIO: the behavior is similar to longterm-pinning a page, and getting the PTE protection changed afterwards. The primary concern with refcounted pages is use-after-free, which callers should be aware of. Signed-off-by: David Hildenbrand --- mm/memory.c | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/mm/memory.c b/mm/memory.c index ab01fb69dc72..535ef2686f95 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -5935,15 +5935,21 @@ int __pmd_alloc(struct mm_struct *mm, pud_t *pud, unsigned long address) * * On a successful return, the pointer to the PTE is stored in @ptepp; * the corresponding lock is taken and its location is stored in @ptlp. - * The contents of the PTE are only stable until @ptlp is released; - * any further use, if any, must be protected against invalidation - * with MMU notifiers. + * + * The contents of the PTE are only stable until @ptlp is released using + * pte_unmap_unlock(). This function will fail if the PTE is non-present. + * Present PTEs may include PTEs that map refcounted pages, such as + * anonymous folios in COW mappings. + * + * Callers must be careful when relying on PTE content after + * pte_unmap_unlock(). Especially if the PTE maps a refcounted page, + * callers must protect against invalidation with MMU notifiers; otherwise + * access to the PFN at a later point in time can trigger use-after-free. * * Only IO mappings and raw PFN mappings are allowed. The mmap semaphore * should be taken for read. * - * KVM uses this function. While it is arguably less bad than the historic - * ``follow_pfn``, it is not a good general-purpose API. + * This function must not be used to modify PTE content. * * Return: zero on success, -ve otherwise. */ @@ -5957,6 +5963,10 @@ int follow_pte(struct vm_area_struct *vma, unsigned long address, pmd_t *pmd; pte_t *ptep; + mmap_assert_locked(mm); + if (unlikely(address < vma->vm_start || address >= vma->vm_end)) + goto out; + if (!(vma->vm_flags & (VM_IO | VM_PFNMAP))) goto out;