Re: [PATCH 0/4] KVM/arm64: Enable PtrAuth on non-VHE KVM

From: Dave Martin <Dave.Martin@arm.com>
To: Marc Zyngier <maz@kernel.org>
Cc: kernel-team@android.com, kvm@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	kvmarm@lists.cs.columbia.edu
Subject: Re: [PATCH 0/4] KVM/arm64: Enable PtrAuth on non-VHE KVM
Date: Mon, 15 Jun 2020 15:17:56 +0100	[thread overview]
Message-ID: <20200615141755.GK25945@arm.com> (raw)
In-Reply-To: <dd0e5196a4e7baf4d0f8fba2b00e9ef5@kernel.org>

On Mon, Jun 15, 2020 at 02:22:19PM +0100, Marc Zyngier wrote:
> Hi Dave,
> 
> On 2020-06-15 13:59, Dave Martin wrote:
> >On Mon, Jun 15, 2020 at 09:19:50AM +0100, Marc Zyngier wrote:
> >>Not having PtrAuth on non-VHE KVM (for whatever reason VHE is not
> >>enabled on a v8.3 system) has always looked like an oddity. This
> >>trivial series remedies it, and allows a non-VHE KVM to offer PtrAuth
> >>to its guests.
> >
> >How likely do you think it is that people will use such a configuration?
> 
> Depending on the use case, very. See below.
> 
> >The only reason I can see for people to build a kernel with CONFIG_VHE=n
> >is as a workaround for broken hardware, or because the kernel is too old
> >to support VHE (in which case it doesn't understand ptrauth either, so
> >it is irrelevant whether ptrauth depends on VHE).
> 
> Part of the work happening around running protected VMs (which cannot
> be tampered with from EL1/0 host) makes it mandatory to disable VHE,
> so that we can wrap the host EL1 in its own Stage-2 page tables.
> We (the Android kernel team) are actively working on enabling this
> feature.
> 
> >I wonder whether it's therefore better to "encourage" people to turn
> >VHE on by making subsequent features depend on it where appropriate.
> >We do want multiplatform kernels to be configured with CONFIG_VHE=y for
> >example.
> 
> I'm all for having VHE on for platforms that support it. Which is why
> CONFIG_VHE=y is present in defconfig. However, we cannot offer the same
> level of guarantee as we can hopefully achieve with non-VHE (we can
> drop mappings from Stage-1, but can't protect VMs from an evil or
> compromised host). This is a very different use case from the usual
> "reduced hypervisor overhead" that we want in the general case.
> 
> >I ask this, because SVE suffers the same "oddity".  If SVE can be
> >enabled for non-VHE kernels straightforwardly then there's no reason not
> >to do so, but I worried in the past that this would duplicate complex
> >code that would never be tested or used.
> 
> It is a concern. I guess that if we manage to get some traction on
> Android, then the feature will get some testing! And yes, SVE is
> next on my list.
> 
> >If supporting ptrauth with !VHE is as simple as this series suggests,
> >then it's low-risk.  Perhaps SVE isn't much worse.  I was chasing nasty
> >bugs around at the time the SVE KVM support was originally written, and
> >didn't want to add more unknowns into the mix...
> 
> I think having started with a slightly smaller problem space was the
> right thing to do at the time. We are now reasonably confident that
> KVM and SVE are working correctly together, and we can now try to enable
> it on !VHE.

Cool, now I understand.

Cheers
---Dave

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel