linux-kernel - Re: [PATCH 2/5] kvm/arm64: rework guest entry logic

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: <YeAh2PX5PFcBl9y6@FVFF77S0Q05N>
Date:   Thu, 13 Jan 2022 12:58:00 +0000
From:   Mark Rutland <mark.rutland@....com>
To:     Marc Zyngier <maz@...nel.org>
Cc:     linux-kernel@...r.kernel.org, aleksandar.qemu.devel@...il.com,
        alexandru.elisei@....com, anup.patel@....com,
        aou@...s.berkeley.edu, atish.patra@....com,
        benh@...nel.crashing.org, borntraeger@...ux.ibm.com, bp@...en8.de,
        catalin.marinas@....com, chenhuacai@...nel.org,
        dave.hansen@...ux.intel.com, david@...hat.com,
        frankja@...ux.ibm.com, frederic@...nel.org, gor@...ux.ibm.com,
        hca@...ux.ibm.com, imbrenda@...ux.ibm.com, james.morse@....com,
        jmattson@...gle.com, joro@...tes.org, kvm@...r.kernel.org,
        mingo@...hat.com, mpe@...erman.id.au, nsaenzju@...hat.com,
        palmer@...belt.com, paulmck@...nel.org, paulus@...ba.org,
        paul.walmsley@...ive.com, pbonzini@...hat.com, seanjc@...gle.com,
        suzuki.poulose@....com, tglx@...utronix.de,
        tsbogend@...ha.franken.de, vkuznets@...hat.com,
        wanpengli@...cent.com, will@...nel.org
Subject: Re: [PATCH 2/5] kvm/arm64: rework guest entry logic

On Thu, Jan 13, 2022 at 11:43:30AM +0000, Marc Zyngier wrote:
> On Thu, 13 Jan 2022 11:17:53 +0000,
> Mark Rutland <mark.rutland@....com> wrote:
> > 
> > On Tue, Jan 11, 2022 at 05:55:20PM +0000, Marc Zyngier wrote:
> > > On Tue, 11 Jan 2022 15:35:36 +0000,
> > > Mark Rutland <mark.rutland@....com> wrote:
> 
> [...]
> 
> > > > @@ -891,26 +909,23 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu)
> > > >  		kvm_arch_vcpu_ctxsync_fp(vcpu);
> > > >  
> > > >  		/*
> > > > -		 * We may have taken a host interrupt in HYP mode (ie
> > > > -		 * while executing the guest). This interrupt is still
> > > > -		 * pending, as we haven't serviced it yet!
> > > > +		 * We must ensure that any pending interrupts are taken before
> > > > +		 * we exit guest timing so that timer ticks are accounted as
> > > > +		 * guest time. Transiently unmask interrupts so that any
> > > > +		 * pending interrupts are taken.
> > > >  		 *
> > > > -		 * We're now back in SVC mode, with interrupts
> > > > -		 * disabled.  Enabling the interrupts now will have
> > > > -		 * the effect of taking the interrupt again, in SVC
> > > > -		 * mode this time.
> > > > +		 * Per ARM DDI 0487G.b section D1.13.4, an ISB (or other
> > > > +		 * context synchronization event) is necessary to ensure that
> > > > +		 * pending interrupts are taken.
> > > >  		 */
> > > >  		local_irq_enable();
> > > > +		isb();
> > > > +		local_irq_disable();
> > > 
> > > Small nit: we may be able to elide this enable/isb/disable dance if a
> > > read of ISR_EL1 returns 0.
> > 
> > Wouldn't that be broken when using GIC priority masking, since that
> > can prevent IRQS being signalled ot the PE?
> 
> You're right. But this can be made even simpler. We already know if
> we've exited the guest because of an IRQ (ret tells us that), and
> that's true whether we're using priority masking or not. It could be
> as simple as:
> 
> 	if (ARM_EXCEPTION_CODE(ret) == ARM_EXCEPTION_IRQ) {
> 		// We exited because of an interrupt. Let's take
> 		// it now to account timer ticks to the guest.
> 	 	local_irq_enable();
>  		isb();
>  		local_irq_disable();
> 	}
> 
> and that would avoid accounting the interrupt to the guest if it fired
> after the exit took place.
> 
> > I'm happy to rework this, but I'll need to think a bit harder about
> > it. Would you be happy if we did that as a follow-up?
> 
> Oh, absolutely. I want the flow to be correct before we make it
> fast(-ish).

Cool; I'll leave that for now on the assumption we'll address that with a
follow-up patch, though your suggestion above looks "obviously" correct to me.

Thanks,
Mark.