lkml.org 
[lkml]   [2024]   [Mar]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH 11/16] KVM: x86/mmu: Explicitly disallow private accesses to emulated MMIO
    From


    On 28/02/2024 3:41 pm, Sean Christopherson wrote:
    > Explicitly detect and disallow private accesses to emulated MMIO in
    > kvm_handle_noslot_fault() instead of relying on kvm_faultin_pfn_private()
    > to perform the check. This will allow the page fault path to go straight
    > to kvm_handle_noslot_fault() without bouncing through __kvm_faultin_pfn().
    >
    > Signed-off-by: Sean Christopherson <seanjc@google.com>
    > ---
    > arch/x86/kvm/mmu/mmu.c | 5 +++++
    > 1 file changed, 5 insertions(+)
    >
    > diff --git a/arch/x86/kvm/mmu/mmu.c b/arch/x86/kvm/mmu/mmu.c
    > index 5c8caab64ba2..ebdb3fcce3dc 100644
    > --- a/arch/x86/kvm/mmu/mmu.c
    > +++ b/arch/x86/kvm/mmu/mmu.c
    > @@ -3314,6 +3314,11 @@ static int kvm_handle_noslot_fault(struct kvm_vcpu *vcpu,
    > {
    > gva_t gva = fault->is_tdp ? 0 : fault->addr;
    >
    > + if (fault->is_private) {
    > + kvm_mmu_prepare_memory_fault_exit(vcpu, fault);
    > + return -EFAULT;
    > + }
    > +

    As mentioned in another reply in this series, unless I am mistaken, for
    TDX guest the _first_ MMIO access would still cause EPT violation with
    MMIO GFN being private.

    Returning to userspace cannot really help here because the MMIO mapping
    is inside the guest.

    I am hoping I am missing something here?

    \
     
     \ /
      Last update: 2024-03-06 23:35    [W:3.783 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site