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

[Kashyap Chamarthy]

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.  

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.)


[1] "CVE3"-related commits:
    - 471470bc7052 (arm64: errata: Add Cortex-A520 speculative
      unprivileged load workaround, 2023-09-21)
    - 4f1df628d4ec (KVM: arm64: Advertise ID_AA64PFR0_EL1.CSV3=1 if the
      CPUs are Meltdown-safe, 2020-11-26)
[2] 
https://www.qemu.org/docs/master/system/i386/cpu.html#important-cpu-features-for-intel-x86-hosts
    - "Important CPU features for Intel x86 hosts"
[3] https://lists.nongnu.org/archive/html/qemu-arm/2024-12/msg01224.html

-- 
/kashyap