Re: [PATCH v1 0/7] KVM: arm64: Fix handling of host fpsimd/sve state in protected mode

From: Marc Zyngier <maz@kernel.org>
To: Fuad Tabba <tabba@google.com>
Cc: Mark Brown <broonie@kernel.org>,
	Oliver Upton <oliver.upton@linux.dev>,
	kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
	will@kernel.org, qperret@google.com, seanjc@google.com,
	alexandru.elisei@arm.com, catalin.marinas@arm.com,
	philmd@linaro.org, james.morse@arm.com, suzuki.poulose@arm.com,
	mark.rutland@arm.com, joey.gouly@arm.com, rananta@google.com,
	yuzenghui@huawei.com
Subject: Re: [PATCH v1 0/7] KVM: arm64: Fix handling of host fpsimd/sve state in protected mode
Date: Mon, 20 May 2024 09:11:13 +0100	[thread overview]
Message-ID: <87pltg3ntq.wl-maz@kernel.org> (raw)
In-Reply-To: <CA+EHjTxJe8yjVkhc=2fENJoMZs+MTR=9AZLmYcxZ5HxNnUOaQw@mail.gmail.com>

On Mon, 20 May 2024 08:35:47 +0100,
Fuad Tabba <tabba@google.com> wrote:
> 
> Hi Oliver and Mark,
> 
> On Fri, May 17, 2024 at 7:19 PM Mark Brown <broonie@kernel.org> wrote:
> >
> > On Fri, May 17, 2024 at 05:30:54PM +0000, Oliver Upton wrote:
> >
> > > Hmm... Is there any reason why we need to be concerned about preserving
> > > host SVE state?
> >
> > > The syscall ABI has it that only the first 128 bits of the vector
> > > registers are preserved by the kernel, and I see no reason why we
> > > couldn't apply a similar restriction to KVM_RUN HVCs into EL2. We'd need
> > > to eagerly flush the vector registers on entry to avoid disclosing guest
> > > usage of SVE.
> >
> > > What you have is certainly correct, I just wonder if we're going out of
> > > our way to save/restore 0's for larger VLs.
> >
> > Not just larger VLs, there's also the P registers even for 128 bit SVE.
> >
> > I think it'd be sensible to discard.  A big part of why the host ABI is
> > like that is that the AAPCS makes the SVE specific state caller
> > preserved on function calls, with syscalls mirroring that.  This means
> > that even if the kernel is using FP the HVC would need to be inline in a
> > function using SVE in order to get any state that needs to be preserved
> > in there, or there'd need to be some other non-AAPCS thing going on.  We
> > already ensure that any EL0 state is saved prior to trying to run a VM,
> > I've not checked the interaction with pKVM here but if there's any
> > issues I'd hope it's not too difficult to close them.
> 
> The reason for that is that in pKVM we want to avoid leaking any
> information about protected VM activity to the host, including whether
> the VM might have performed fpsimd/sve operations. Therefore, we need
> to ensure that the host SVE state looks the same after a protected
> guest has run as it did before a protected guest has run.
> 
> It would be correct to only save/restore the host's fpsimd state
> (i.e., first 128 bits of the vector registers), which is what KVM does
> in other modes. However, unless we always zero out the rest of the
> state, regardless whether the protected guest has used fpsimd/sve,
> then the host would be able to find out that the guest has in fact
> performed fpsimd/sve operations.
> 
> This isn't necessary for non-protected VMs, but Marc thought that for
> now it would be better to simplify things and have pKVM behave the
> same way for both protected and non-protected VMs. As a future
> optimization for non-protected VMs, we could have them behave as VMs
> in other modes.

And I stand by what I said. Having a hybrid mode is a maintenance
burden, and it will absolutely lead to some sort of horrible bugs (it
just take a look at the mailing list to see that we have no shortage
of bugs related to lazy FP/SVE handling).

If someone is desperate for lazy handling, then the lazy handling
should apply to both protected and non-protected VMs so that we can
actually reason about it.

	M.

-- 
Without deviation from the norm, progress is not possible.

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