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 4E128CD11C2 for ; Wed, 10 Apr 2024 20:12:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B487E6B0089; Wed, 10 Apr 2024 16:12:58 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id AD1516B008A; Wed, 10 Apr 2024 16:12:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 971C56B008C; Wed, 10 Apr 2024 16:12:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 7587B6B0089 for ; Wed, 10 Apr 2024 16:12:58 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 379CC120929 for ; Wed, 10 Apr 2024 20:12:58 +0000 (UTC) X-FDA: 81994720836.25.DC01299 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf23.hostedemail.com (Postfix) with ESMTP id 78F5314001F for ; Wed, 10 Apr 2024 20:12:55 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=sXBQMsjo; dmarc=none; spf=pass (imf23.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1712779975; 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=yUErbBcy3uZEmOx+2yplj9AWv1zm5kwvtjr1ulKN7Zg=; b=dBm0mCZVRA+Xi5I2VHKu6x3dU/X+vv9ofqTrCoDX6ebKjDOZspwrM0Fut4INDveZ5uHL3R BUqm/b9bDLEJigK66pNpNuFje2YQI4SPw4v+5m5lleNJxe6e2qlXAsEhgGpiJw5awGk8Xp y8bhoOEfygkahnUKiKL8xazWw83nfxw= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=sXBQMsjo; dmarc=none; spf=pass (imf23.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1712779975; a=rsa-sha256; cv=none; b=EdYu23eOKHWKrl8p9rxDit+sBr4emDtgi0dMiUB73BYnzleOV/+mUg9MNfjqhN9CRhphOx EEuJ5YUyg9bXcZWb3+1ZrwwN787k1CVP5USpxbEaoHHq67M93YAuXNh0uw6IIqpjd/3lom JV4ndPzP5X7TB/NX7nmgDZdG7XC4d5k= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id B60ED61EBD; Wed, 10 Apr 2024 20:12:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E20D2C433F1; Wed, 10 Apr 2024 20:12:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1712779973; bh=bKXTwEG9V/7gGFzi/nyfEqGiaBgclvN4MQublr5sz80=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=sXBQMsjoj5uKsr9LmT+OooLDlwYt4YcTHKM6vzXBNrCG67rEEi7TQ0JN6rZ0WY8hn vd+WikGTb95drIxuerlIJJsUEPwInCKguinDAK3geNfIlKkGVTtrHZzqT+atKs2XkF /8T8Y1KtIpOeTdFjZLGaNwKYWKzWq/s5npDtdbmg= Date: Wed, 10 Apr 2024 13:12:52 -0700 From: Andrew Morton To: David Hildenbrand Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org, linux-s390@vger.kernel.org, kvm@vger.kernel.org, Yonghua Huang , Fei Li , Christoph Hellwig , Gerald Schaefer , Heiko Carstens , Ingo Molnar , Alex Williamson , Paolo Bonzini Subject: Re: [PATCH v1 1/3] drivers/virt/acrn: fix PFNMAP PTE checks in acrn_vm_ram_map() Message-Id: <20240410131252.3ff0e92cfeccc4435bcdcdd2@linux-foundation.org> In-Reply-To: <20240410155527.474777-2-david@redhat.com> References: <20240410155527.474777-1-david@redhat.com> <20240410155527.474777-2-david@redhat.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 78F5314001F X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: ah3bkske3eae9sq4hgo1zakngoew7wke X-HE-Tag: 1712779975-857731 X-HE-Meta: U2FsdGVkX1+5upmdYnTR7uKA4pMYJfRIwEf+rFqun6mzXYCJGx44EfAkDm3pvfdQQ3rJUwccA0k0becKGU+ojm9SbnKyVdhccXcPeWHZV+1vTSwhcPZXL3jrDLpv6KXFRZR45bU2nG6xbxmCc83wqvFecGihNy1PZeO7Nbbyz5/H3Kj88BZVJff86op5DwSzJoqMwTRWvKk/Nq59viPIOW1EKyi0Nno0CjPBWGQBq8t8RoP+DG+BOHz/8ZKRfKQOAjVkCqyqt+YWNaLljBRnn+Jojh+wKGDrn8XLwCD7Sn9RGzF0kInBigwdGDnLDwEhjz0SAGBtYzbumYyOotraN2YazYLlE7A3KZC2h10o/hva9W+ThQW758yvv5eJEx5Ur2Nq6ti1Km7hTaCz+C4u4ijNxHas0+yLKQZE8Lyt+odo+k03t2Y1tsI0GB0BsdepNYZRor7uM3tvzqHKJpKURMAAD0QSBQuE5BPTDEfkPR7x1n1KqlIpmuG3tDJO+YIXyYD7wheQono8yPSICZtymd68ZvchXj4jwsJH/GQoo7cTR8OUknIjnPJhmM+Z8Z62PNtd0A8yNy6UU04Os/daM7J6cj93WhahlbJRsQO9aDjrEqoy1jSH8aDt7DN71JeZ2WeDG1jovjIf9gC3JYNuUtG+Jqvt4WdowqfbdjYrsL3LUbqStD071PkpRqdhkdImH0G4zkflJBLfrOSdNgHbM9m2lFT2FRzC3Fcgyf9g5datyPDtuuIA5+7TvHfYSm0cUMqvqnXZZVNlTlqebDYhhsRgp3/r0MaG1FPnfsPB4IpOsmDt5YYCS3yQrkdcI2z92s+iPIiV/sb6gn4dSKarAn0s4M2vR1IohCFtfb4uXHUXTPn7NP3bh4f7vtQxeNgpOYF5zovMxclcGztZPSU8+UuS8iQta+FWnUvHaV7njsU5x638hqej+JeUpT26pdnjpCKfHGa2dbz+GQz2Q3A HKj+RK/5 PN0pxT33tD7/AMDoY1KVXQ3AK6RPl0sI/jSoE9ge7++oclD5hYYjgIcP6yznrWfQ6/WLy+kWfRJcXlt9YRQjVzSuy+gsTbSYuU22E6ygQHL+ENG/f2yLD1Vu8nWvlhRXXbaoc/srZlimHHPxaaTzx1e8njtpfvA8Ns2c6eUReHSTXzVyF8cghsqr81HKX8iUzqPoQwzPIRHt6ZfvZebQ9L3sWY7IL/JmPRpYkYUwGC5ql0iquvG75uffWqRCkH5g4kAZF8JedN8LdW9mP4sM1ceoVRdg4YxMzgTglhl77a1FxnCjVW/96YW695TlRA+PLI1FqQ+ixdNvxA06/TUsltBHHhAq0w7Zr9m+uqbg4FaQy0TjjhfvnoXqKbo73F5C8DS2oyIodjcPMVKaG1JZ/2gC6axYqEDFvCpJF+2buXjII7M1S8pBRYIIFw1D93P36DWBDd3xMkU2orG3nexDiJbTYeB2l/Key6GfF3sd6TwpLzMhpPhDPsFK4HA== 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: On Wed, 10 Apr 2024 17:55:25 +0200 David Hildenbrand wrote: > We currently miss to handle various cases, resulting in a dangerous > follow_pte() (previously follow_pfn()) usage. > > (1) We're not checking PTE write permissions. > > Maybe we should simply always require pte_write() like we do for > pin_user_pages_fast(FOLL_WRITE)? Hard to tell, so let's check for > ACRN_MEM_ACCESS_WRITE for now. > > (2) We're not rejecting refcounted pages. > > As we are not using MMU notifiers, messing with refcounted pages is > dangerous and can result in use-after-free. Let's make sure to reject them. > > (3) We are only looking at the first PTE of a bigger range. > > We only lookup a single PTE, but memmap->len may span a larger area. > Let's loop over all involved PTEs and make sure the PFN range is > actually contiguous. Reject everything else: it couldn't have worked > either way, and rather made use access PFNs we shouldn't be accessing. > This all sounds rather nasty and the maintainers of this driver may choose to turn your fixes into something suitable for current mainline and for -stable backporting. If they choose to do this then please just go ahead. Once such a change appear in linux-next the mm-unstable patch "virt: acrn: stop using follow_pfn" will start generating rejects, which will be easy enough to handle. Of they may choose to incorporate that change at the same time. Here it is: From: Christoph Hellwig Subject: virt: acrn: stop using follow_pfn Date: Mon, 25 Mar 2024 07:45:40 +0800 Switch from follow_pfn to follow_pte so that we can get rid of follow_pfn. Note that this doesn't fix any of the pre-existing raciness and lack of permission checking in the code. Link: https://lkml.kernel.org/r/20240324234542.2038726-1-hch@lst.de Link: https://lkml.kernel.org/r/20240324234542.2038726-2-hch@lst.de Signed-off-by: Christoph Hellwig Reviewed-by: David Hildenbrand Cc: Andy Lutomirski Cc: Dave Hansen Cc: Fei Li Cc: Peter Zijlstra Cc: Ingo Molnar Signed-off-by: Andrew Morton --- drivers/virt/acrn/mm.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) --- a/drivers/virt/acrn/mm.c~virt-acrn-stop-using-follow_pfn +++ a/drivers/virt/acrn/mm.c @@ -172,18 +172,24 @@ int acrn_vm_ram_map(struct acrn_vm *vm, mmap_read_lock(current->mm); vma = vma_lookup(current->mm, memmap->vma_base); if (vma && ((vma->vm_flags & VM_PFNMAP) != 0)) { + spinlock_t *ptl; + pte_t *ptep; + if ((memmap->vma_base + memmap->len) > vma->vm_end) { mmap_read_unlock(current->mm); return -EINVAL; } - ret = follow_pfn(vma, memmap->vma_base, &pfn); - mmap_read_unlock(current->mm); + ret = follow_pte(vma->vm_mm, memmap->vma_base, &ptep, &ptl); if (ret < 0) { + mmap_read_unlock(current->mm); dev_dbg(acrn_dev.this_device, "Failed to lookup PFN at VMA:%pK.\n", (void *)memmap->vma_base); return ret; } + pfn = pte_pfn(ptep_get(ptep)); + pte_unmap_unlock(ptep, ptl); + mmap_read_unlock(current->mm); return acrn_mm_region_add(vm, memmap->user_vm_pa, PFN_PHYS(pfn), memmap->len, _