linux-kernel - Re: [PATCH 14/17] KVM: x86/mmu: Handle no-slot faults at the beginning of kvm_faultin

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Mon, 13 May 2024 14:28:22 +0800
From: Xiaoyao Li <xiaoyao.li@...el.com>
To: Paolo Bonzini <pbonzini@...hat.com>, linux-kernel@...r.kernel.org,
 kvm@...r.kernel.org
Cc: Sean Christopherson <seanjc@...gle.com>,
 David Matlack <dmatlack@...gle.com>, Kai Huang <kai.huang@...el.com>
Subject: Re: [PATCH 14/17] KVM: x86/mmu: Handle no-slot faults at the
 beginning of kvm_faultin_pfn()

On 5/7/2024 11:58 PM, Paolo Bonzini wrote:
> From: Sean Christopherson <seanjc@...gle.com>
> 
> Handle the "no memslot" case at the beginning of kvm_faultin_pfn(), just
> after the private versus shared check, so that there's no need to
> repeatedly query whether or not a slot exists.  This also makes it more
> obvious that, except for private vs. shared attributes, the process of
> faulting in a pfn simply doesn't apply to gfns without a slot.
> 
> Opportunistically stuff @fault's metadata in kvm_handle_noslot_fault() so
> that it doesn't need to be duplicated in all paths that invoke
> kvm_handle_noslot_fault(), and to minimize the probability of not stuffing
> the right fields.
> 
> Leave the existing handle behind, but convert it to a WARN, to guard
> against __kvm_faultin_pfn() unexpectedly nullifying fault->slot.
> 
> Cc: David Matlack <dmatlack@...gle.com>
> Signed-off-by: Sean Christopherson <seanjc@...gle.com>
> Reviewed-by: Kai Huang <kai.huang@...el.com>
> Message-ID: <20240228024147.41573-14-seanjc@...gle.com>
> Signed-off-by: Paolo Bonzini <pbonzini@...hat.com>

Reviewed-by: Xiaoyao Li <xiaoyao.li@...el.com>