linux-kernel - Re: [PATCH v2 2/2] KVM: x86/xen: Stop Xen timer before changing the IRQ vector

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] [day] [month] [year] [list]

Date:   Mon, 8 Aug 2022 12:00:59 -0500
From:   Coleman Dietsch <dietschc@....edu>
To:     Sean Christopherson <seanjc@...gle.com>
Cc:     kvm@...r.kernel.org, Paolo Bonzini <pbonzini@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
        "H . Peter Anvin" <hpa@...or.com>, linux-kernel@...r.kernel.org,
        skhan@...uxfoundation.org, Pavel Skripkin <paskripkin@...il.com>,
        linux-kernel-mentees@...ts.linuxfoundation.org,
        syzbot+e54f930ed78eb0f85281@...kaller.appspotmail.com
Subject: Re: [PATCH v2 2/2] KVM: x86/xen: Stop Xen timer before changing the
 IRQ vector

On Fri, Aug 05, 2022 at 06:50:15PM +0000, Sean Christopherson wrote:
> On Fri, Jul 29, 2022, Coleman Dietsch wrote:
> > This moves the stop xen timer call outside of the previously unreachable
> 
> Please avoid "This", "This patch", etc... and describe what the change is, not
> what the patch is.
> 
> > if else statement as well as making sure that the timer is stopped first
> > before changing IRQ vector. Code was streamlined a bit also.
> 
> Generally speaking, don't describe the literal code changes, e.g. write the changelog
> as if you were describing the bug and the fix to someone in a verbal conversation.
> 

Understood.

> > This was contributing to the ODEBUG bug in kvm_xen_vcpu_set_attr crash that
> > was discovered by syzbot.
> 
> That's not proper justification as it doesn't explain why this patch is needed
> even after fixing the immedate cause of the ODEBUG splat.
> 
>   Stop Xen's timer (if it's running) prior to changing the vector and
>   potentially (re)starting the timer.  Changing the vector while the timer
>   is still running can result in KVM injecting a garbage event, e.g.
>   vm_xen_inject_timer_irqs() could see a non-zero xen.timer_pending from
>   a previous timer but inject the new xen.timer_virq.
> 

Thanks for helping clarify this Sean.

> > ODEBUG: init active (active state 0)
> > object type: hrtimer hint: xen_timer_callbac0
> > RIP: 0010:debug_print_object+0x16e/0x250 lib/debugobjects.c:502
> > Call Trace:
> > __debug_object_init
> > debug_hrtimer_init
> > debug_init
> > hrtimer_init
> > kvm_xen_init_timer
> > kvm_xen_vcpu_set_attr
> > kvm_arch_vcpu_ioctl
> > kvm_vcpu_ioctl
> > vfs_ioctl
> > 
> 
> Fixes: 536395260582 ("KVM: x86/xen: handle PV timers oneshot mode")
> Cc: stable@...r.kernel.org
> 
> > Link: https://syzkaller.appspot.com/bug?id=8234a9dfd3aafbf092cc5a7cd9842e3ebc45fc42
> > Reported-by: syzbot+e54f930ed78eb0f85281@...kaller.appspotmail.com
> > Signed-off-by: Coleman Dietsch <dietschc@....edu>
> > ---
> >  arch/x86/kvm/xen.c | 37 ++++++++++++++++++-------------------
> >  1 file changed, 18 insertions(+), 19 deletions(-)
> > 
> > diff --git a/arch/x86/kvm/xen.c b/arch/x86/kvm/xen.c
> > index 2dd0f72a62f2..f612fac0e379 100644
> > --- a/arch/x86/kvm/xen.c
> > +++ b/arch/x86/kvm/xen.c
> > @@ -707,27 +707,26 @@ int kvm_xen_vcpu_set_attr(struct kvm_vcpu *vcpu, struct kvm_xen_vcpu_attr *data)
> >  		break;
> >  
> >  	case KVM_XEN_VCPU_ATTR_TYPE_TIMER:
> > -		if (data->u.timer.port) {
> > -			if (data->u.timer.priority != KVM_IRQ_ROUTING_XEN_EVTCHN_PRIO_2LEVEL) {
> > -				r = -EINVAL;
> > -				break;
> > -			}
> > -			vcpu->arch.xen.timer_virq = data->u.timer.port;
> > -
> > -			/* Check for existing timer */
> > -			if (!vcpu->arch.xen.timer.function)
> > -				kvm_xen_init_timer(vcpu);
> > -
> > -			/* Restart the timer if it's set */
> > -			if (data->u.timer.expires_ns)
> > -				kvm_xen_start_timer(vcpu, data->u.timer.expires_ns,
> > -						    data->u.timer.expires_ns -
> > -						    get_kvmclock_ns(vcpu->kvm));
> > -		} else if (kvm_xen_timer_enabled(vcpu)) {
> > -			kvm_xen_stop_timer(vcpu);
> > -			vcpu->arch.xen.timer_virq = 0;
> > +		if (data->u.timer.port &&
> > +		    data->u.timer.priority != KVM_IRQ_ROUTING_XEN_EVTCHN_PRIO_2LEVEL) {
> > +			r = -EINVAL;
> > +			break;
> >  		}
> >  
> > +		/* Check for existing timer */
> > +		if (!vcpu->arch.xen.timer.function)
> > +			kvm_xen_init_timer(vcpu);
> > +
> > +		/* Stop the timer (if it's running) before changing the vector */
> > +		kvm_xen_stop_timer(vcpu);
> > +		vcpu->arch.xen.timer_virq = data->u.timer.port;
> > +
> > +		/* Restart the timer if it's set */
> 
> The "if it's set" part is stale, maybe this?
> 
> 		/* Start the timer if the new value has a valid vector+expiry. */
> 

Agreed, I'll clean that comment up a bit.

> > +		if (data->u.timer.port && data->u.timer.expires_ns)
> > +			kvm_xen_start_timer(vcpu, data->u.timer.expires_ns,
> > +					    data->u.timer.expires_ns -
> > +					    get_kvmclock_ns(vcpu->kvm));
> > +
> >  		r = 0;
> >  		break;
> >  
> > -- 
> > 2.34.1
> >