Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From:   Andy Lutomirski <luto@amacapital.net>
Mime-Version: 1.0 (1.0)
Subject: Re: [PATCH 2/2] KVM: VMX: Extend VMX's #AC handding
Date:   Fri, 31 Jan 2020 07:37:43 -0800
Message-Id: <5D1CAD6E-7D40-48C6-8D21-203BDC3D0B63@amacapital.net>
References: <3499ee3f-e734-50fd-1b50-f6923d1f4f76@intel.com>
Cc:     Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        "H. Peter Anvin" <hpa@zytor.com>,
        Paolo Bonzini <pbonzini@redhat.com>,
        Sean Christopherson <sean.j.christopherson@intel.com>,
        x86@kernel.org, linux-kernel@vger.kernel.org, kvm@vger.kernel.org
In-Reply-To: <3499ee3f-e734-50fd-1b50-f6923d1f4f76@intel.com>
To:     Xiaoyao Li <xiaoyao.li@intel.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> On Jan 30, 2020, at 11:22 PM, Xiaoyao Li <xiaoyao.li@intel.com> wrote:
>=20
> =EF=BB=BFOn 1/31/2020 1:16 AM, Andy Lutomirski wrote:
>>>> On Jan 30, 2020, at 8:30 AM, Xiaoyao Li <xiaoyao.li@intel.com> wrote:
>>>=20
>>> =EF=BB=BFOn 1/30/2020 11:18 PM, Andy Lutomirski wrote:
>>>>>> On Jan 30, 2020, at 4:24 AM, Xiaoyao Li <xiaoyao.li@intel.com> wrote:=

>>>>>=20
>>>>> =EF=BB=BFThere are two types of #AC can be generated in Intel CPUs:
>>>>> 1. legacy alignment check #AC;
>>>>> 2. split lock #AC;
>>>>>=20
>>>>> Legacy alignment check #AC can be injected to guest if guest has enabl=
ed
>>>>> alignemnet check.
>>>>>=20
>>>>> When host enables split lock detection, i.e., split_lock_detect!=3Doff=
,
>>>>> guest will receive an unexpected #AC when there is a split_lock happen=
s in
>>>>> guest since KVM doesn't virtualize this feature to guest.
>>>>>=20
>>>>> Since the old guests lack split_lock #AC handler and may have split lo=
ck
>>>>> buges. To make guest survive from split lock, applying the similar pol=
icy
>>>>> as host's split lock detect configuration:
>>>>> - host split lock detect is sld_warn:
>>>>>   warning the split lock happened in guest, and disabling split lock
>>>>>   detect around VM-enter;
>>>>> - host split lock detect is sld_fatal:
>>>>>   forwarding #AC to userspace. (Usually userspace dump the #AC
>>>>>   exception and kill the guest).
>>>> A correct userspace implementation should, with a modern guest kernel, f=
orward the exception. Otherwise you=E2=80=99re introducing a DoS into the gu=
est if the guest kernel is fine but guest userspace is buggy.
>>>=20
>>> To prevent DoS in guest, the better solution is virtualizing and adverti=
sing this feature to guest, so guest can explicitly enable it by setting spl=
it_lock_detect=3Dfatal, if it's a latest linux guest.
>>>=20
>>> However, it's another topic, I'll send out the patches later.
>>>=20
>> Can we get a credible description of how this would work? I suggest:
>> Intel adds and documents a new CPUID bit or core capability bit that mean=
s =E2=80=9Csplit lock detection is forced on=E2=80=9D.  If this bit is set, t=
he MSR bit controlling split lock detection is still writable, but split loc=
k detection is on regardless of the value.  Operating systems are expected t=
o set the bit to 1 to indicate to a hypervisor, if present, that they unders=
tand that split lock detection is on.
>> This would be an SDM-only change, but it would also be a commitment to ce=
rtain behavior for future CPUs that don=E2=80=99t implement split locks.
>=20
> It sounds a PV solution for virtualization that it doesn't need to be defi=
ned in Intel-SDM but in KVM document.
>=20
> As you suggested, we can define new bit in KVM_CPUID_FEATURES (0x40000001)=
 as KVM_FEATURE_SLD_FORCED and reuse MSR_TEST_CTL or use a new virtualized M=
SR for guest to tell hypervisor it understand split lock detection is forced=
 on.

Of course KVM can do this. But this missed the point. Intel added a new CPU f=
eature, complete with an enumeration mechanism, that cannot be correctly use=
d if a hypervisor is present. As it stands, without specific hypervisor and g=
uest support of a non-Intel interface, it is *impossible* to give architectu=
rally correct behavior to a guest. If KVM implements your suggestion, *Windo=
ws* guests will still malfunction on Linux.

This is Intel=E2=80=99s mess. Intel should have some responsibility for clea=
ning it up. If Intel puts something like my suggestion into the SDM, all the=
 OSes and hypervisors will implement it the *same* way and will be compatibl=
e. Sure, old OSes will still be broken, but at least new guests will work co=
rrectly. Without something like this, even new guests are busted.

>=20
>> Can one of you Intel folks ask the architecture team about this?
>=20