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

[Marc Zyngier <maz@kernel.org>]

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.

> 
> 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?

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.

Thanks,

	M.

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