Re: [PATCH 0/2] KVM: arm/arm64: Add VCPU workarounds firmware register

[Dave Martin <Dave.Martin@arm.com>]

On Tue, Jan 22, 2019 at 11:11:09AM +0000, Marc Zyngier wrote:
> On Tue, 22 Jan 2019 10:17:00 +0000,
> Dave Martin <Dave.Martin@arm.com> wrote:
> > 
> > On Mon, Jan 07, 2019 at 12:05:35PM +0000, Andre Przywara wrote:
> > > Workarounds for Spectre variant 2 or 4 vulnerabilities require some help
> > > from the firmware, so KVM implements an interface to provide that for
> > > guests. When such a guest is migrated, we want to make sure we don't
> > > loose the protection the guest relies on.
> > > 
> > > This introduces two new firmware registers in KVM's GET/SET_ONE_REG
> > > interface, so userland can save the level of protection implemented by
> > > the hypervisor and used by the guest. Upon restoring these registers,
> > > we make sure we don't downgrade and reject any values that would mean
> > > weaker protection.
> > 
> > Just trolling here, but could we treat these as immutable, like the ID
> > registers?  
> > 
> > We don't support migration between nodes that are "too different" in any
> > case, so I wonder if adding complex logic to compare vulnerabilities and
> > workarounds is liable to create more problems than it solves...
> 
> And that's exactly the case we're trying to avoid. Two instances of
> the same HW. One with firmware mitigations, one without. Migrating in
> one direction is perfectly safe, migrating in the other isn't.
> 
> It is not about migrating to different HW at all.

So this is a realistic scenario when deploying a firmware update across
a cluter that has homogeneous hardware -- there will temporarly be
different firmware versions running on different nodes?

My concern is really "will the checking be too buggy / untested in
practice to be justified by the use case".

I'll take a closer look at the checking logic.

Cheers
---Dave