linux-kernel - Re: [PATCH 3/3] KVM: x86: WARN only once if KVM leaves a dangling userspace I/O request

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: <649b5c71b5ad40e3c74f76c86ad0ca89f9dac3e1.camel@redhat.com>
Date:   Tue, 12 Jul 2022 16:34:18 +0300
From:   Maxim Levitsky <mlevitsk@...hat.com>
To:     Sean Christopherson <seanjc@...gle.com>,
        Paolo Bonzini <pbonzini@...hat.com>
Cc:     kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
        syzbot+760a73552f47a8cd0fd9@...kaller.appspotmail.com,
        Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
        Hou Wenlong <houwenlong.hwl@...group.com>
Subject: Re: [PATCH 3/3] KVM: x86: WARN only once if KVM leaves a dangling
 userspace I/O request

On Mon, 2022-07-11 at 23:27 +0000, Sean Christopherson wrote:
> Change a WARN_ON() to separate WARN_ON_ONCE() if KVM has an outstanding
> PIO or MMIO request without an associated callback, i.e. if KVM queued a
> userspace I/O exit but didn't actually exit to userspace before moving
> on to something else.  Warning on every KVM_RUN risks spamming the kernel
> if KVM gets into a bad state.  Opportunistically split the WARNs so that
> it's easier to triage failures when a WARN fires.
> 
> Deliberately do not use KVM_BUG_ON(), i.e. don't kill the VM.  While the
> WARN is all but guaranteed to fire if and only if there's a KVM bug, a
> dangling I/O request does not present a danger to KVM (that flag is truly
> truly consumed only in a single emulator path), and any such bug is
> unlikely to be fatal to the VM (KVM essentially failed to do something it
> shouldn't have tried to do in the first place).  In other words, note the
> bug, but let the VM keep running.
> 
> Signed-off-by: Sean Christopherson <seanjc@...gle.com>
> ---
>  arch/x86/kvm/x86.c | 6 ++++--
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 567d13405445..50dc55996416 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -10847,8 +10847,10 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu)
>                 r = cui(vcpu);
>                 if (r <= 0)
>                         goto out;
> -       } else
> -               WARN_ON(vcpu->arch.pio.count || vcpu->mmio_needed);
> +       } else {
> +               WARN_ON_ONCE(vcpu->arch.pio.count);
> +               WARN_ON_ONCE(vcpu->mmio_needed);
> +       }
>  
>         if (kvm_run->immediate_exit) {
>                 r = -EINTR;

At some point in the future, the checkpatch.pl should start to WARN the
patch submitter if WARN_ON and not WARN_ON_ONCE was used ;-)

It already bugs the user about BUG_ON ;-)

Reviewed-by: Maxim Levitsky <mlevitsk@...hat.com>

Best regards,
	Maxim Levitsky