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? > > 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? Is split_lock_detect=fatal the only available way to prevent them? > > 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? -- Eduardo
