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

[Marc Zyngier]

On Thu, 19 Dec 2024 12:38:50 +0000,
Daniel "P. Berrangé" <berrange@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:
> > > 
> > > On Thu, Dec 12, 2024 at 11:04:30AM +0100, Eric Auger wrote:
> > > 
> > > Hi Eric,
> > > 
> > > > On 12/12/24 10:36, Cornelia Huck wrote:
> > > > > On Thu, Dec 12 2024, Daniel P. Berrangé <berrange@redhat.com> wrote:
> > > 
> > > [...]
> > > 
> > > > >> Consider you mgmt app wants to set a CPU model that's common across
> > > > >> heterogeneous hardware. They don't neccessarily want/need to be
> > > > >> able to live migrate between heterogeneous CPUs, but for simplicity
> > > > >> of configuration desire to set a single named CPU across all guests,
> > > > >> irrespective of what host hey are launched on. The ARM spec baseline
> > > > >> named models would give you that config simplicity.
> > > > > If we use architecture extensions (i.e. Armv8.x/9.x) as baseline, I'm
> > > > > seeing some drawbacks:
> > > > > - a lot of work before we can address some specific use cases
> > > > > - old models can get new optional features
> > > > > - a specific cpu might have a huge set of optional features on top of
> > > > >   the baseline model
> > > > >
> > > > > Using a reference core such as Neoverse-V2 probably makes more sense
> > > > > (easier to get started, less feature diff?) It would still make a good
> > > > > starting point for a simple config.
> > > > >
> > > > Actually from a dev point of view I am not sure it changes much to have
> > > > either ARM spec rev baseline or CPU ref core named model.
> > > > 
> > > > One remark is that if you look at
> > > > https://developer.arm.com/documentation/109697/2024_09?lang=en
> > > > you will see there are quite a lot of spec revisions and quite a few of
> > > > them are actually meaningful in the light of currently avaiable and
> > > > relevant HW we want to address. What I would like to avoid is to be
> > > > obliged to look at all of them in a generic manner while we just want to
> > > > address few cpu ref models.
> > > > 
> > > > Also starting from the ARM spec rev baseline the end-user may need to
> > > > add more feature opt-ins to be close to a specific cpu model. So I
> > > > foresee extra complexity for the end-user.
> > > 
> > > (Assuming I'm parsing your last para right; correct me if not.)
> > > 
> > > Isn't a user wanting to add extra CPU flags (on top of a baseline) a
> > > "normal behaviour" and not "extra complexity"?  Besides coming close to
> > > a specific CPU model, there's the additional important use-case of CPU
> > > flags that provide security mitigation.
> > > 
> > > 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. See what KVM does for CSV3, for example (and all the
> > rest of the side-channel stuff).
> > 
> > You can't rely on userspace for security, that'd be completely
> > ludicrous.
> 
> Actually that's a normal situation QEMU has to deal with.
> 
> QEMU needs to be able to expose a deterministic fixed ABI to the guest
> VM, and that includes control over what CPU features are exposed to
> it. In most cases, the hypervisor cannot arbitrary force enable new
> guest features without agreement from QEMU.

Which ABI? The only ABI that matters is what is defined by the
architecture. When it comes to CPU features, new features are exposed
by default. If QEMU wants to turn it off, it can in most (but not all)
cases. But that's the extent of the "agreement" we have with
userspace, QEMU or otherwise.

If a feature is deemed broken or unsafe, KVM will turn it at least
hide it from the guest without userspace's intervention, and if
possible actively turn it off.

> If a guest happens to be using '-cpu host', then when a new CPU flag
> arrives as part of a security fix, there is at least no CPU config
> change required. QEMU may or may not need changes, in order that
> the behaviour associated with the new CPU flag is correctly handled.

How is that "flag" visible from the guest? The only way to expose
properties is through the ID registers, and you can't invent your own,
nor expose something that is not already handled by the host.

> If the guest is using a named CPU model, as well as modifying QEMU
> to know about the new flag, the host admin needs to explicitly
> decide whether & when to expose the new CPU flag for each guest VM
> on the host.
>
> Until the new CPU flag is exposed to the guest, while the host itself
> may be able to remain protected to the new security issue, the guest
> OS is likely remain vulnerable, or have degraded operation in some way.

I think that's the point where we talk past each other. There is no
"flag" that can be exposed to a guest as part of the architecture. We
have a set of architectural features, and in 99% of the cases, we can
only expose to the guest a feature that both exists on the host and
that the hypervisor understands.

Thanks,

        M.

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