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:   Thu, 30 Jan 2020 09:16:54 -0800
Message-Id: <A2E4B0E3-EDDF-46FD-8CE9-62A2E2E4BF20@amacapital.net>
References: <cf79eeeb-e107-bdff-13a8-c52288d0d123@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: <cf79eeeb-e107-bdff-13a8-c52288d0d123@intel.com>
To:     Xiaoyao Li <xiaoyao.li@intel.com>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk


> 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 enabled=

>>> 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 happens i=
n
>>> guest since KVM doesn't virtualize this feature to guest.
>>>=20
>>> Since the old guests lack split_lock #AC handler and may have split lock=

>>> buges. To make guest survive from split lock, applying the similar polic=
y
>>> 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, fo=
rward the exception. Otherwise you=E2=80=99re introducing a DoS into the gue=
st if the guest kernel is fine but guest userspace is buggy.
>=20
> To prevent DoS in guest, the better solution is virtualizing and advertisi=
ng this feature to guest, so guest can explicitly enable it by setting split=
_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 means =E2=
=80=9Csplit lock detection is forced on=E2=80=9D.  If this bit is set, the M=
SR bit controlling split lock detection is still writable, but split lock de=
tection is on regardless of the value.  Operating systems are expected to se=
t the bit to 1 to indicate to a hypervisor, if present, that they understand=
 that split lock detection is on.

This would be an SDM-only change, but it would also be a commitment to certa=
in behavior for future CPUs that don=E2=80=99t implement split locks.

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