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

[Cornelia Huck <cohuck@redhat.com>]

On Thu, Dec 19 2024, 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.

I don't think "hiding" is the same thing as "disabling"? The underlying
behaviour will still have changed, the main question is whether that is
a problem.

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

It implies that QEMU (or generally the VMM) needs to actively disable
everything it does not know about (i.e. setting everything in any
writable id reg to zero if it has no idea what it is about) to provide a
stable guest interface across different kernels. Just tweaking some
known values is only sufficient for a stable interface across two
systems with the same kernel.

(...)

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

Not sure if I understand what you mean, but "give me the contents of all
id registers, and which registers are writable" should probably do the
trick?