From: Xiaoyao Li <xiaoyao.li@intel.com>
To: Paolo Bonzini <pbonzini@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>
Cc: Sean Christopherson <sean.j.christopherson@intel.com>,
Fenghua Yu <fenghua.yu@intel.com>, Ingo Molnar <mingo@redhat.com>,
Borislav Petkov <bp@alien8.de>, H Peter Anvin <hpa@zytor.com>,
Peter Zijlstra <peterz@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
Dave Hansen <dave.hansen@intel.com>,
Radim Krcmar <rkrcmar@redhat.com>,
Ashok Raj <ashok.raj@intel.com>, Tony Luck <tony.luck@intel.com>,
Dan Williams <dan.j.williams@intel.com>,
Sai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>,
Ravi V Shankar <ravi.v.shankar@intel.com>,
linux-kernel <linux-kernel@vger.kernel.org>, x86 <x86@kernel.org>,
kvm@vger.kernel.org
Subject: Re: [PATCH v9 09/17] x86/split_lock: Handle #AC exception for split lock
Date: Wed, 16 Oct 2019 19:23:21 +0800 [thread overview]
Message-ID: <c3ff2fb3-4380-fb07-1fa3-15896a09e748@intel.com> (raw)
In-Reply-To: <57f40083-9063-5d41-f06d-fa1ae4c78ec6@redhat.com>
On 10/16/2019 6:16 PM, Paolo Bonzini wrote:
> On 16/10/19 11:47, Thomas Gleixner wrote:
>> On Wed, 16 Oct 2019, Paolo Bonzini wrote:
>>> Just never advertise split-lock
>>> detection to guests. If the host has enabled split-lock detection,
>>> trap #AC and forward it to the host handler---which would disable
>>> split lock detection globally and reenter the guest.
>>
>> Which completely defeats the purpose.
>
> Yes it does. But Sean's proposal, as I understand it, leads to the
> guest receiving #AC when it wasn't expecting one. So for an old guest,
> as soon as the guest kernel happens to do a split lock, it gets an
> unexpected #AC and crashes and burns. And then, after much googling and
> gnashing of teeth, people proceed to disable split lock detection.
>
> (Old guests are the common case: you're a cloud provider and your
> customers run old stuff; it's a workstation and you want to play that
> game that requires an old version of Windows; etc.).
>
> To save them the googling and gnashing of teeth, I guess we can do a
> pr_warn_ratelimited on the first split lock encountered by a guest. (It
> has to be ratelimited because userspace could create an arbitrary amount
> of guests to spam the kernel logs). But the end result is the same,
> split lock detection is disabled by the user.
>
> The first alternative I thought of was:
>
> - Remove KVM loading of MSR_TEST_CTRL, i.e. KVM *never* writes the CPU's
> actual MSR_TEST_CTRL. KVM still emulates MSR_TEST_CTRL so that the
> guest can do WRMSR and handle its own #AC faults, but KVM doesn't
> change the value in hardware.
>
> - trap #AC if the guest encounters a split lock while detection is
> disabled, and then disable split-lock detection in the host.
>
> But I discarded it because it still doesn't do anything for malicious
> guests, which can trigger #AC as they prefer. And it makes things
> _worse_ for sane guests, because they think split-lock detection is
> enabled but they become vulnerable as soon as there is only one
> malicious guest on the same machine.
>
> In all of these cases, the common final result is that split-lock
> detection is disabled on the host. So might as well go with the
> simplest one and not pretend to virtualize something that (without core
> scheduling) is obviously not virtualizable.
Right, the nature of core-scope makes MSR_TEST_CTL impossible/hard to
virtualize.
- Making old guests survive needs to disable split-lock detection in
host(hardware).
- Defending malicious guests needs to enable split-lock detection in
host(hardware).
We cannot achieve them at the same time.
In my opinion, letting kvm disable the split-lock detection in host is
not acceptable that it just opens the door for malicious guests to
attack. I think we can use Sean's proposal like below.
KVM always traps #AC, and only advertises split-lock detection to guest
when the global variable split_lock_detection_enabled in host is true.
- If guest enables #AC (CPL3 alignment check or split-lock detection
enabled), injecting #AC back into guest since it's supposed capable of
handling it.
- If guest doesn't enable #AC, KVM reports #AC to userspace (like other
unexpected exceptions), and we can print a hint in kernel, or let
userspace (e.g., QEMU) tell the user guest is killed because there is a
split-lock in guest.
In this way, malicious guests always get killed by userspace and old
sane guests cannot survive as well if it causes split-lock. If we do
want old sane guests work we have to disable the split-lock detection
(through booting parameter or debugfs) in the host just the same as we
want to run an old and split-lock generating userspace binary.
But there is an issue that we advertise split-lock detection to guest
based on the value of split_lock_detection_enabled to be true in host,
which can be turned into false dynamically when split-lock happens in
host kernel. This causes guest's capability changes at run time and I
don't if there is a better way to inform guest? Maybe we need a pv
interface?
> Thanks,
>
> Paolo
>
>> 1) Sane guest
>>
>> Guest kernel has #AC handler and you basically prevent it from
>> detecting malicious user space and killing it. You also prevent #AC
>> detection in the guest kernel which limits debugability.
>>
>> 2) Malicious guest
>>
>> Trigger #AC to disable the host detection and then carry out the DoS
>> attack.
>
>
next prev parent reply other threads:[~2019-10-16 11:23 UTC|newest]
Thread overview: 85+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-18 22:41 [PATCH v9 00/17] x86/split_lock: Enable split lock detection Fenghua Yu
2019-06-18 22:41 ` [PATCH v9 01/17] x86/common: Align cpu_caps_cleared and cpu_caps_set to unsigned long Fenghua Yu
2019-06-18 22:41 ` [PATCH v9 02/17] drivers/net/b44: Align pwol_mask to unsigned long for better performance Fenghua Yu
2019-06-24 15:12 ` David Laight
2019-06-24 18:43 ` Paolo Bonzini
2019-06-18 22:41 ` [PATCH v9 03/17] x86/split_lock: Align x86_capability to unsigned long to avoid split locked access Fenghua Yu
2019-06-24 15:12 ` David Laight
2019-06-25 23:54 ` Fenghua Yu
2019-06-26 19:15 ` Thomas Gleixner
2019-06-18 22:41 ` [PATCH v9 04/17] x86/msr-index: Define MSR_IA32_CORE_CAP and split lock detection bit Fenghua Yu
2019-06-18 22:41 ` [PATCH v9 05/17] x86/cpufeatures: Enumerate MSR_IA32_CORE_CAP Fenghua Yu
2019-06-18 22:41 ` [PATCH v9 06/17] x86/split_lock: Enumerate split lock detection by MSR_IA32_CORE_CAP Fenghua Yu
2019-06-18 22:41 ` [PATCH v9 07/17] x86/split_lock: Enumerate split lock detection on Icelake mobile processor Fenghua Yu
2019-06-18 22:41 ` [PATCH v9 08/17] x86/split_lock: Define MSR TEST_CTL register Fenghua Yu
2019-06-18 22:41 ` [PATCH v9 09/17] x86/split_lock: Handle #AC exception for split lock Fenghua Yu
2019-06-26 20:20 ` Thomas Gleixner
2019-06-26 20:36 ` Fenghua Yu
2019-06-26 21:47 ` Thomas Gleixner
2019-09-25 18:09 ` Sean Christopherson
2019-10-16 6:58 ` Xiaoyao Li
2019-10-16 9:29 ` Thomas Gleixner
2019-10-16 15:59 ` Sean Christopherson
2019-10-16 9:40 ` Paolo Bonzini
2019-10-16 9:47 ` Thomas Gleixner
2019-10-16 10:16 ` Paolo Bonzini
2019-10-16 11:23 ` Xiaoyao Li [this message]
2019-10-16 11:26 ` Paolo Bonzini
2019-10-16 13:13 ` Xiaoyao Li
2019-10-16 14:43 ` Thomas Gleixner
2019-10-16 15:37 ` Paolo Bonzini
2019-10-16 16:25 ` Xiaoyao Li
2019-10-16 16:38 ` Paolo Bonzini
2019-10-17 12:29 ` [RFD] x86/split_lock: Request to Intel Thomas Gleixner
2019-10-17 17:23 ` Sean Christopherson
2019-10-17 21:31 ` Thomas Gleixner
2019-10-17 23:38 ` Sean Christopherson
2019-10-17 23:28 ` Luck, Tony
2019-10-18 10:45 ` David Laight
2019-10-18 21:03 ` hpa
2019-10-18 2:36 ` Xiaoyao Li
2019-10-18 9:02 ` Thomas Gleixner
2019-10-18 10:20 ` Xiaoyao Li
2019-10-18 10:43 ` Peter Zijlstra
2019-10-16 11:49 ` [PATCH v9 09/17] x86/split_lock: Handle #AC exception for split lock Thomas Gleixner
2019-10-16 11:58 ` Paolo Bonzini
2019-10-16 13:51 ` Xiaoyao Li
2019-10-16 14:08 ` Paolo Bonzini
2019-10-16 14:14 ` David Laight
2019-10-16 15:03 ` Thomas Gleixner
2019-10-16 15:41 ` Sean Christopherson
2019-10-16 15:43 ` Paolo Bonzini
2019-10-16 16:23 ` Sean Christopherson
2019-10-16 17:42 ` Sean Christopherson
2019-10-17 1:23 ` Xiaoyao Li
2019-10-21 13:06 ` Paolo Bonzini
2019-10-21 13:03 ` Paolo Bonzini
2019-10-21 13:02 ` Paolo Bonzini
2019-10-16 14:50 ` Thomas Gleixner
2019-06-18 22:41 ` [PATCH v9 10/17] kvm/x86: Emulate MSR IA32_CORE_CAPABILITY Fenghua Yu
2019-06-18 22:41 ` [PATCH v9 11/17] kvm/vmx: Emulate MSR TEST_CTL Fenghua Yu
2019-06-27 2:24 ` Xiaoyao Li
2019-06-27 7:12 ` Thomas Gleixner
2019-06-27 7:58 ` Xiaoyao Li
2019-06-27 12:11 ` Thomas Gleixner
2019-06-27 12:22 ` Xiaoyao Li
2019-06-18 22:41 ` [PATCH v9 12/17] x86/split_lock: Enable split lock detection by default Fenghua Yu
2019-06-18 22:41 ` [PATCH v9 13/17] x86/split_lock: Disable split lock detection by kernel parameter "nosplit_lock_detect" Fenghua Yu
2019-06-26 20:34 ` Thomas Gleixner
2019-06-26 20:37 ` Fenghua Yu
2019-06-18 22:41 ` [PATCH v9 14/17] x86/split_lock: Add a debugfs interface to enable/disable split lock detection during run time Fenghua Yu
2019-06-26 21:37 ` Thomas Gleixner
2019-06-18 22:41 ` [PATCH v9 15/17] x86/split_lock: Add documentation for split lock detection interface Fenghua Yu
2019-06-26 21:51 ` Thomas Gleixner
2019-06-18 22:41 ` [PATCH v9 16/17] x86/split_lock: Reorganize few header files in order to call WARN_ON_ONCE() in atomic bit ops Fenghua Yu
2019-06-18 22:41 ` [PATCH v9 17/17] x86/split_lock: Warn on unaligned address in atomic bit operations Fenghua Yu
2019-06-26 22:00 ` Thomas Gleixner
2019-09-16 22:39 ` [PATCH 0/3] Fix some 4-byte vs. 8-byte alignment issues Tony Luck
2019-09-16 22:39 ` [PATCH 1/3] x86/common: Align cpu_caps_cleared and cpu_caps_set to unsigned long Tony Luck
2019-11-15 19:26 ` [tip: x86/cpu] x86/cpu: " tip-bot2 for Fenghua Yu
2019-09-16 22:39 ` [PATCH 2/3] drivers/net/b44: Align pwol_mask to unsigned long for better performance Tony Luck
2019-09-16 22:39 ` [PATCH 3/3] x86/split_lock: Align the x86_capability array to size of unsigned long Tony Luck
2019-09-17 8:29 ` David Laight
2019-09-17 19:14 ` Luck, Tony
2019-09-18 8:54 ` David Laight
2019-11-15 19:26 ` [tip: x86/cpu] x86/cpu: " tip-bot2 for Fenghua Yu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c3ff2fb3-4380-fb07-1fa3-15896a09e748@intel.com \
--to=xiaoyao.li@intel.com \
--cc=akpm@linux-foundation.org \
--cc=ashok.raj@intel.com \
--cc=bp@alien8.de \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@intel.com \
--cc=fenghua.yu@intel.com \
--cc=hpa@zytor.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=ravi.v.shankar@intel.com \
--cc=rkrcmar@redhat.com \
--cc=sai.praneeth.prakhya@intel.com \
--cc=sean.j.christopherson@intel.com \
--cc=tglx@linutronix.de \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).