Re: [PATCH RFCv2 00/20] kvm/arm: Introduce a customizable aarch64 KVM host model

[Marc Zyngier]

On Thu, 19 Dec 2024 17:51:44 +0000,
Daniel "P. Berrangé" <berrange@redhat.com> wrote:
> 
> On Thu, Dec 19, 2024 at 03:41:56PM +0000, Marc Zyngier wrote:
> > On Thu, 19 Dec 2024 15:07:25 +0000,
> > Kashyap Chamarthy <kchamart@redhat.com> wrote:
> > > 
> > > On Thu, Dec 19, 2024 at 12:26:29PM +0000, Marc Zyngier wrote:
> > > > On Thu, 19 Dec 2024 11:35:16 +0000,
> > > > Kashyap Chamarthy <kchamart@redhat.com> wrote:
> > > 
> > > [...]
> > > 
> > > > > Consider this:
> > > > > 
> > > > > Say, there's a serious security issue in a released ARM CPU.  As part 
> > > > > of
> > > > > the fix, two new CPU flags need to be exposed to the guest OS, call 
> > > > > them
> > > > > "secflag1" and "secflag2".  Here, the user is configuring a baseline
> > > > > model + two extra CPU flags, not to get close to some other CPU model
> > > > > but to mitigate itself against a serious security flaw.
> > > > 
> > > > If there's such a security issue, that the hypervisor's job to do so,
> > > > not userspace. 
> > > 
> > > I don't disagree.  Probably that has always been the case on ARM.  I
> > > asked the above based on how QEMU on x86 handles it today.
> > > 
> > > > See what KVM does for CSV3, for example (and all the
> > > > rest of the side-channel stuff).
> > > 
> > > Noted.  From a quick look in the kernel tree, I assume you're referring
> > > to these commits[1].
> > > 
> > > > You can't rely on userspace for security, that'd be completely
> > > > ludicrous.
> > > 
> > > As Dan Berrangé points out, it's the bog-standard way QEMU deals with
> > > some of the CPU-related issues on x86 today.  See this "important CPU
> > > flags"[2] section in the QEMU docs.
> > 
> > I had a look, and we do things quite differently. For example, the
> > spec-ctrl equivalent in implemented in FW and in KVM, and is exposed
> > by default if the HW is vulnerable. Userspace could hide that the
> > mitigation is there, but that's the extent of the configurability.
> 
> Whether it is enabled by default or disabled by default isn't a
> totally fatal problem. If QEMU can toggle it to the opposite value,
> we have the same level of configurability in both cases.
> 
> It does, however, have implications for QEMU as if KVM gained support
> for exposing the new feature by default and QEMU didn't know about
> it, then the guest ABI would have changed without QEMU realizing it.

No. It just imposes that QEMU implements its part of the architecture,
which is that any ID reg it doesn't know about and that is advertised
as writable gets written back to 0, which is (in general, but with a
couple of exceptions) the value indicating that a feature is not
implemented.

The ID register space is architected, and has been unchanged for the
past 13 years.

> IOW, it would imply a requirement for timely QEMU updates to match
> the kernel, which is something we wouldn't need in x86 world where
> the feature is disabled by default. Disable by default is a more
> stable approach from QEMU's POV.

Given the above, I don't see where the burden is. And that ship has
sailed since the beginning of KVM/arm, really. It is also worth
realising that for a very long time, it wasn't really possible to
"disable" new features. Even today, disabling a feature really means
emulating its absence.

> 
> > > Mind you, I'm _not_ saying this is how ARM should do it.  I don't know
> > > enough about ARM to make such remarks.
> > > 
> > >     * * *
> > > 
> > > To reply to your other question on this thread[3] about "which ABI?"  I
> > > think Dan is talking about the *guest* ABI: the virtual "chipset" that
> > > is exposed to a guest (e.g. PCI(e) topology, ACPI tables, CPU model,
> > > etc).  As I understand it, this "guest ABI" should remain predictable,
> > > regardless of:
> > > 
> > >   - whether you're updating KVM, QEMU, or the underlying physical
> > >     hardware itself; or
> > >   - if the guest is migrated, live or offline
> > > 
> > > (As you might know, QEMU's "machine types" concept allows to create a
> > > stable guest ABI.)
> > 
> > All of this is under control of QEMU, *except* for the "maximum" of
> > the architectural features exposed to the guest. All you can do is
> > *downgrade* from there, and only to a limited extent.
> > 
> > That, in turn has a direct impact on what you call the "CPU model",
> > which for the ARM architecture really doesn't exist. All we have is a
> > bag of discrete features, with intricate dependencies between them.
> > 
> > Even ignoring virtualisation: you can readily find two machines using
> > the same CPUs (let's say Neoverse-N1), integrated by the same vendor
> > (let's say, Ampere), in SoCs that bear the same name (Altra), and
> > realise that they have a different feature set. Fun, isn't it?
> 
> "Fun" is probably not the word I'd pick :-)

Of course not. "Braindead" is the word I wanted to write, but sarcasm
took over... ;-)

> 
> > That's why I don't see CPU models as a viable thing in terms of ABI.
> > They are an approximation of what you could have, but the ABI is
> > elsewhere.
> 
> Right, this makes life quite challenging for QEMU. The premise of named
> CPU models (as opposed to -host), is to facilitate the migration of VMs
> between heterogenous hardware platforms. That assumes it is possible to
> downgrade the CPU on both src + dst, to the common baseline you desire.
> 
> If we were to define a named CPU model, for that to be usable, QEMU
> would have to be able to query the "maxmimum" architectural features,
> and validate that the delta between the host maximum, and the named
> CPU model is possible to downgrade. Is arm providing sufficient info
> to let QEMU do that ?

I think so. On creating a brand new VM, you get the maximum allowed on
the HW, and the subset of features you can downgrade. The intersection
of these two sets and your model's will tell you whether you can
actually instantiate this model on this host. You can also decide that
it is OK to let a extra features advertised, such as extra page sizes
or 32bit support, which the hypervisor can hide, but not disable.

Thanks,

        M.

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