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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D7EB0C433FE for ; Mon, 4 Apr 2022 14:03:43 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1376808AbiDDOFi (ORCPT ); Mon, 4 Apr 2022 10:05:38 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52042 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1349617AbiDDOFf (ORCPT ); Mon, 4 Apr 2022 10:05:35 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [IPv6:2604:1380:4601:e00::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C8653DF94; Mon, 4 Apr 2022 07:03:38 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 84513B816A6; Mon, 4 Apr 2022 14:03:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E8E28C2BBE4; Mon, 4 Apr 2022 14:03:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1649081016; bh=AEmWPvqVQn1yx8cH2eWg94/7riYkWEIyAZw3zc0gW3s=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=oek85EHdiVttdQkx+aSBWnCKE8vfjdHMFTOgGF6hEJMZg21N7bhBBxmp1Xb6SlZZ2 2vq9D3ZdaZ0E4vbRzvqrPa62TO3C10DaWxyZ5QhUMbUaSmqqE4e3zqjo6D3YAYpxsC DpDpMo2vJjCzkkOyzAq0BWQ0ogrQ+jF0wiaKlZfY= Date: Mon, 4 Apr 2022 16:03:33 +0200 From: Greg KH To: Paolo Bonzini Cc: linux-kernel@vger.kernel.org, kvm@vger.kernel.org, stable@vger.kernel.org, Qiuhao Li , Gaoning Pan , Yongkang Jia , syzbot+6cde2282daa792c49ab8@syzkaller.appspotmail.com, Tadeusz Struk , Maxim Levitsky Subject: Re: [PATCH 5.16] KVM: x86/mmu: do compare-and-exchange of gPTE via the user address Message-ID: References: <20220404134141.427397-3-pbonzini@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220404134141.427397-3-pbonzini@redhat.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 04, 2022 at 09:41:40AM -0400, Paolo Bonzini wrote: > commit 2a8859f373b0a86f0ece8ec8312607eacf12485d upstream. > > FNAME(cmpxchg_gpte) is an inefficient mess. It is at least decent if it > can go through get_user_pages_fast(), but if it cannot then it tries to > use memremap(); that is not just terribly slow, it is also wrong because > it assumes that the VM_PFNMAP VMA is contiguous. > > The right way to do it would be to do the same thing as > hva_to_pfn_remapped() does since commit add6a0cd1c5b ("KVM: MMU: try to > fix up page faults before giving up", 2016-07-05), using follow_pte() > and fixup_user_fault() to determine the correct address to use for > memremap(). To do this, one could for example extract hva_to_pfn() > for use outside virt/kvm/kvm_main.c. But really there is no reason to > do that either, because there is already a perfectly valid address to > do the cmpxchg() on, only it is a userspace address. That means doing > user_access_begin()/user_access_end() and writing the code in assembly > to handle any exception correctly. Worse, the guest PTE can be 8-byte > even on i686 so there is the extra complication of using cmpxchg8b to > account for. But at least it is an efficient mess. > > Reported-by: Qiuhao Li > Reported-by: Gaoning Pan > Reported-by: Yongkang Jia > Reported-by: syzbot+6cde2282daa792c49ab8@syzkaller.appspotmail.com > Debugged-by: Tadeusz Struk > Tested-by: Maxim Levitsky > Cc: stable@vger.kernel.org > Fixes: bd53cb35a3e9 ("X86/KVM: Handle PFNs outside of kernel reach when touching GPTEs") > Signed-off-by: Paolo Bonzini > --- > arch/x86/kvm/mmu/paging_tmpl.h | 77 ++++++++++++++++------------------ > 1 file changed, 37 insertions(+), 40 deletions(-) This, and the 5.15, and 5.10 patches now applied. 5.4 did not apply cleanly. thanks, greg k-h