Re: [PATCH v2] i386: Add ratelimit for bus locks acquired in guest

[Chenyi Qiang <chenyi.qiang@intel.com>]

On 4/21/2021 11:18 PM, Eduardo Habkost wrote:
> On Wed, Apr 21, 2021 at 10:50:10PM +0800, Xiaoyao Li wrote:
>> On 4/21/2021 10:12 PM, Eduardo Habkost wrote:
>>> On Wed, Apr 21, 2021 at 02:26:42PM +0800, Chenyi Qiang wrote:
>>>> Hi, Eduardo, thanks for your comments!
>>>>
>>>>
>>>> On 4/21/2021 12:34 AM, Eduardo Habkost wrote:
>>>>> Hello,
>>>>>
>>>>> Thanks for the patch.  Comments below:
>>>>>
>>>>> On Tue, Apr 20, 2021 at 05:37:36PM +0800, Chenyi Qiang wrote:
>>>>>> Virtual Machines can exploit bus locks to degrade the performance of
>>>>>> system. To address this kind of performance DOS attack, bus lock VM exit
>>>>>> is introduced in KVM and it will report the bus locks detected in guest,
>>>>>> which can help userspace to enforce throttling policies.
>>>>>>
>>>>>
>>>>> Is there anything today that would protect the system from
>>>>> similar attacks from userspace with access to /dev/kvm?
>>>>>
>>>>
>>>> I can't fully understand your meaning for "similar attack with access to
>>>> /dev/kvm". But there are some similar associated detection features on bare
>>>> metal.
>>>
>>> What I mean is: you say guests can make a performance DoS attack
>>> on the host, and your patch mitigates that.
>>>
>>> What would be the available methods to prevent untrusted
>>> userspace running on the host with access to /dev/kvm from making
>>> a similar DoS attack on the host?
> 
> Thanks for all the clarifications below.  Considering them,
> what's the answer to the question above?
> 

Hi Eduardo,

Just make it more clear.

Bus lock detection contains two sub-features. One is bus lock debug 
exception, and the other is bus lock VM exit.

Bus lock #DB exception can help detect the bus locks acquired in user 
space and bus lock VM exit detects the bus locks insides VMs. To address 
the attacks from non-VM userspace attackers against VM, Bus lock #DB 
exception can help.

The Bus lock #DB exception support 
(https://lore.kernel.org/lkml/20210322135325.682257-3-fenghua.yu@intel.com/) 
extends the  existing kernel command line parameter "split_lock_detect=" 
also applying to non-wb bus lock.
For example, split_lock_detect=fatal will send SIGBUS to the attackers 
once this kind of #DB is detected.

>>>
>>>>
>>>> 1. Split lock detection:https://lore.kernel.org/lkml/158031147976.396.8941798847364718785.tip-bot2@tip-bot2/
>>>> Some CPUs can raise an #AC trap when a split lock is attempted.
>>>
>>> Would split_lock_detect=fatal be enough to prevent the above attacks?
>>
>> NO.
>>
>> There are two types bus lock:
>> 1. split lock - lock on cacheable memory while the memory across two cache
>> lines.
>> 2. non-wb lock - lock on non-writableback memory (you can find it on Intel
>> ISE chapter 8, https://software.intel.com/content/www/us/en/develop/download/intel-architecture-instruction-set-extensions-programming-reference.html)
>>
>> split lock detection can only prevent 1)
>>
>>> Is split_lock_detect=fatal the only available way to prevent them?
>>
>> as above, 2) non-wb lock can be prevented by "non-wb lock disable" feature
> 
> Bus lock VM exit applies to both 1 and 2, correct?
> 
>>
>>>
>>>>
>>>> 2. Bus lock Debug Exception:
>>>> https://lore.kernel.org/lkml/20210322135325.682257-1-fenghua.yu@intel.com/
>>>> The kernel can be notified by an #DB trap after a user instruction acquires
>>>> a bus lock and is executed.
>>>
>>> I see a rate limit option mentioned at the above URL.  Would a
>>> host kernel bus lock rate limit option make this QEMU patch
>>> redundant?
>>>
>>
>> No. Bus lock Debug exception cannot be used to detect the bus lock happens
>> in guest (vmx non-root mode).
>>
>> We have patch to virtualize this feature for guest
>> https://lore.kernel.org/kvm/20210202090433.13441-1-chenyi.qiang@intel.com/
>>
>> that guest will have its own setting of bus lock debug exception on or off.
>>
>> What's more important is that, even we force set the
>> MSR_DEBUGCTL.BUS_LOCK_DETECT for guest, guest still can escape from it.
>> Because bus lock #DB is a trap which is delivered after the instruction
>> completes. If the instruction acquires bus lock subsequently faults e.g.,
>> #PF, then no bus lock #DB generated. But the bus lock does happen.
>>
>> But with bus lock VM exit, even the instruction faults, it will cause a BUS
>> LOCK VM exit.
>>
>>
>