[PATCH v13 16/40] KVM: arm64: Manage GCS access and registers for guests

[Marc Zyngier]

On Wed, 02 Oct 2024 19:24:12 +0100,
Mark Brown <broonie at kernel.org> wrote:
> 
> [1  <text/plain; us-ascii (7bit)>]
> On Wed, Oct 02, 2024 at 04:55:25PM +0100, Marc Zyngier wrote:
> > Marc Zyngier <maz at kernel.org> wrote:
> 
> > > > +	if (!kvm_has_gcs(kvm))
> > > > +		kvm->arch.fgu[HFGxTR_GROUP] |= (HFGxTR_EL2_nGCS_EL0 |
> > > > +						HFGxTR_EL2_nGCS_EL1);
> 
> > > Why are you still allowing the GCS instructions when GCS isn't
> > > enabled?
> 
> > Scratch that, they are NOPs when GCS isn't enabled, so there shouldn't
> > be any need for extra traps.
> 
> They are, though really they should UNDEF if GCS isn't there (which I
> had thought was what you were referencing here).  Equally we only have
> traps for a subset of GCS instructions and it's not like there aren't a
> whole bunch of untrappable extensions anyway so it's not clear it's
> worth the effort just for that.

If the encodings UNDEF when GCS is not implemented (i.e. they are not
in the NOP space), then all trapable instructions should absolutely
UNDEF (and yes, it is worth the effort, even if it is only to
demonstrate that the architecture is sub-par).

So I expect the next version to handle traps for GCSPUSHX, GCSPOPX,
GCSPUSHM, GCSSTR and GCSSTTR when GCS isn't enabled.

I'm also pretty sure this is missing some form of sanitisation for
PSTATE.EXLOCK, and looking at the pseudocode, you seem to be missing
the handling of that bit on exception injection.

	M.

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