On Tue, 11 Feb 2025 12:36:35 +0000,
Mark Rutland <mark.rutland@xxxxxxx> wrote:
>
> On Mon, Feb 10, 2025 at 06:41:37PM +0000, Marc Zyngier wrote:
> > We don't seem to be handling the GCS-specific exception class.
> > Handle it by delivering an UNDEF to the guest, and populate the
> > relevant trap bits.
> >
> > Signed-off-by: Marc Zyngier <maz@xxxxxxxxxx>
> > ---
> > arch/arm64/kvm/handle_exit.c | 11 +++++++++++
> > arch/arm64/kvm/sys_regs.c | 8 ++++++++
> > 2 files changed, 19 insertions(+)
> >
> > diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
> > index 4f8354bf7dc5f..624a78a99e38a 100644
> > --- a/arch/arm64/kvm/handle_exit.c
> > +++ b/arch/arm64/kvm/handle_exit.c
> > @@ -294,6 +294,16 @@ static int handle_svc(struct kvm_vcpu *vcpu)
> > return 1;
> > }
> >
> > +static int kvm_handle_gcs(struct kvm_vcpu *vcpu)
> > +{
> > + /* We don't expect GCS, so treat it with contempt */
> > + if (kvm_has_feat(vcpu->kvm, ID_AA64PFR1_EL1, GCS, IMP))
> > + WARN_ON_ONCE(1);
>
> Just to check / better my understanging, do we enforce that this can't
> be exposed to the guest somewhere?
>
> I see __kvm_read_sanitised_id_reg() masks it out, and the sys_reg_descs
> table has it filtered, but I'm not immediately sure whether that
> prevents host userspace maliciously setting this?
On writing to the idreg, you end-up in set_id_aa64pfr1_el1(), which
calls into set_id_reg(). There, arm64_check_features() compares each
and every feature in that register with the mask and limits that have
been established.
Since GCS is not part of the writable mask, and that it has been
disabled, the only valid value for ID_AA64PFR1_EL1.GCS is 0. A
non-zero value provided by userspace will be caught by the last check
in arm64_check_features(), and an error be returned.
HTH,
M.
--
Without deviation from the norm, progress is not possible.
