[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2] i386: Add ratelimit for bus locks acquired in guest
From: |
Eduardo Habkost |
Subject: |
Re: [PATCH v2] i386: Add ratelimit for bus locks acquired in guest |
Date: |
Wed, 21 Apr 2021 10:12:10 -0400 |
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.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?
--
Eduardo