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]
Message-ID: <ZkzldN0SwEhstwEB@google.com>
Date: Tue, 21 May 2024 11:18:28 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Paolo Bonzini <pbonzini@...hat.com>
Cc: kvm@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 9/9] KVM: x86: Disable KVM_INTEL_PROVE_VE by default

On Tue, May 21, 2024, Paolo Bonzini wrote:
> On Sat, May 18, 2024 at 2:04 AM Sean Christopherson <seanjc@...gle.com> wrote:
> > Disable KVM's "prove #VE" support by default, as it provides no functional
> > value, and even its sanity checking benefits are relatively limited.  Ie.
> > it should be fully opt-in even on debug kernels, especially since EPT
> > Violation #VE suppression appears to be buggy on some CPUs.
> 
> More #VE trapping than #VE suppression.
>
> I wouldn't go so far as making it *depend* on DEBUG_KERNEL.  EXPERT
> plus the scary help message is good enough.

Works for me.

> 
> What about this:
> 
> diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
> index b6831e17ec31..2864608c7016 100644
> --- a/arch/x86/kvm/Kconfig
> +++ b/arch/x86/kvm/Kconfig
> @@ -97,14 +97,15 @@ config KVM_INTEL
> 
>  config KVM_INTEL_PROVE_VE
>          bool "Check that guests do not receive #VE exceptions"
> -        depends on KVM_INTEL && DEBUG_KERNEL && EXPERT
> +        depends on KVM_INTEL && EXPERT
>          help
>            Checks that KVM's page table management code will not incorrectly
>            let guests receive a virtualization exception.  Virtualization
>            exceptions will be trapped by the hypervisor rather than injected
>            in the guest.
> 
> -          This should never be enabled in a production environment.
> +          Note that #VE trapping appears to be buggy on some CPUs.

I see where you're coming from, but I don't think "trapping" is much better,
e.g. it suggests there's something broken with the interception of #VEs.  Ah,
the entire help text is weird.

This?

config KVM_INTEL_PROVE_VE
        bool "Verify guests do not receive unexpected EPT Violation #VEs"
        depends on KVM_INTEL && EXPERT
        help
          Enable EPT Violation #VEs (when supported) for all VMs, to verify
	  that KVM's EPT management code will not incorrectly result in a #VE
	  (KVM is supposed to supress #VEs by default).  Unexpected #VEs will
	  be intercepted by KVM and will trigger a WARN, but are otherwise
	  transparent to the guest.
	  
	  Note, EPT Violation #VE support appears to be buggy on some CPUs.

          This should never be enabled in a production environment!

          If unsure, say N.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ