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? > > > > > > > > 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...@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.qi...@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. > > -- Eduardo
