Re: [PATCH] KVM: arm64: pkvm: Fixup boot mode to reflect that the kernel resumes from EL1

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Nov 28, 2022 at 04:21:28PM +0000, Vincent Donnefort wrote:
> On Tue, Nov 08, 2022 at 10:01:38AM +0000, Vincent Donnefort wrote:
> > From: Marc Zyngier <maz@xxxxxxxxxx>
> > 
> > The kernel has an awfully complicated boot sequence in order to cope
> > with the various EL2 configurations, including those that "enhanced"
> > the architecture. We go from EL2 to EL1, then back to EL2, staying
> > at EL2 if VHE capable and otherwise go back to EL1.
> > 
> > Here's a paracetamol tablet for you.
> > 
> > The cpu_resume path follows the same logic, because coming up with
> > two versions of a square wheel is hard.
> > 
> > However, things aren't this straightforward with pKVM, as the host
> > resume path is always proxied by the hypervisor, which means that
> > the kernel is always entered at EL1. Which contradicts what the
> > __boot_cpu_mode[] array contains (it obviously says EL2).
> > 
> > This thus triggers a HVC call from EL1 to EL2 in a vain attempt
> > to upgrade from EL1 to EL2 VHE, which we are, funnily enough,
> > reluctant to grant to the host kernel. This is also completely
> > unexpected, and puzzles your average EL2 hacker.
> > 
> > Address it by fixing up the boot mode at the point the host gets
> > deprivileged. is_hyp_mode_available() and co already have a static
> > branch to deal with this, making it pretty safe.
> > 
> > Cc: <stable@xxxxxxxxxxxxxxx> # 5.15+
> > Reported-by: Vincent Donnefort <vdonnefort@xxxxxxxxxx>
> > Signed-off-by: Marc Zyngier <maz@xxxxxxxxxx>
> > Tested-by: Vincent Donnefort <vdonnefort@xxxxxxxxxx>
> > 
> > --- 
> > 
> > This patch doesn't have an upstream version. It's been fixed by the side
> > effect of another upstream patch. see conversation [1]
> > 
> > [1] https://lore.kernel.org/all/20221011165400.1241729-1-maz@xxxxxxxxxx/
> > 
> > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> > index 4cb265e15361..3fe816c244ce 100644
> > --- a/arch/arm64/kvm/arm.c
> > +++ b/arch/arm64/kvm/arm.c
> > @@ -2000,6 +2000,17 @@ static int pkvm_drop_host_privileges(void)
> >  	 * once the host stage 2 is installed.
> >  	 */
> >  	static_branch_enable(&kvm_protected_mode_initialized);
> > +
> > +	/*
> > +	 * Fixup the boot mode so that we don't take spurious round
> > +	 * trips via EL2 on cpu_resume. Flush to the PoC for a good
> > +	 * measure, so that it can be observed by a CPU coming out of
> > +	 * suspend with the MMU off.
> > +	 */
> > +	__boot_cpu_mode[0] = __boot_cpu_mode[1] = BOOT_CPU_MODE_EL1;
> > +	dcache_clean_poc((unsigned long)__boot_cpu_mode,
> > +			 (unsigned long)(__boot_cpu_mode + 2));
> > +
> >  	on_each_cpu(_kvm_host_prot_finalize, &ret, 1);
> >  	return ret;
> >  }
> > -- 
> > 2.38.1.431.g37b22c650d-goog
> >
> 
> Hi Greg,
> 
> Any chance to pick this fix for 5.15?

<formletter>

This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read:
    https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.

</formletter>



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux