linux-kernel - RE: [PATCH v5 2/3] x86/bus_lock: Handle #DB for bus lock

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 20 Mar 2021 14:57:52 +0100
From:   Thomas Gleixner <tglx@...utronix.de>
To:     "Luck\, Tony" <tony.luck@...el.com>,
        "Yu\, Fenghua" <fenghua.yu@...el.com>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Peter Zijlstra <peterz@...radead.org>,
        Randy Dunlap <rdunlap@...radead.org>,
        "Li\, Xiaoyao" <xiaoyao.li@...el.com>,
        "Shankar\, Ravi V" <ravi.v.shankar@...el.com>
Cc:     linux-kernel <linux-kernel@...r.kernel.org>, x86 <x86@...nel.org>,
        "Yu\, Fenghua" <fenghua.yu@...el.com>
Subject: RE: [PATCH v5 2/3] x86/bus_lock: Handle #DB for bus lock

On Sat, Mar 20 2021 at 02:01, Thomas Gleixner wrote:

> On Fri, Mar 19 2021 at 21:50, Tony Luck wrote:
>>>  What is the justifucation for making this rate limit per UID and not
>>>  per task, per process or systemwide?
>>
>> The concern is that a malicious user is running a workload that loops
>> obtaining the buslock. This brings the whole system to its knees.
>>
>> Limiting per task doesn't help. The user can just fork(2) a whole bunch
>> of tasks for a distributed buslock attack..
>
> Fair enough.
>
>> Systemwide might be an interesting alternative. Downside would be accidental
>> rate limit of non-malicious tasks that happen to grab a bus lock periodically
>> but in the same window with other buslocks from other users.
>>
>> Do you think that a risk worth taking to make the code simpler?
>
> I'd consider it low risk, but I just looked for the usage of the
> existing ratelimit in struct user and the related commit. Nw it's dawns
> on me where you are coming from.

So after getting real numbers myself, I have more thoughts on
this. Setting a reasonable per user limit might be hard when you want to
protect e.g. against an orchestrated effort by several users
(containers...). If each of them stays under the limit which is easy
enough to figure out then you still end up with significant accumulated
damage.

So systemwide might not be the worst option after all.

The question is how wide spread are bus locks in existing applications?
I haven't found any on a dozen machines with random variants of
workloads so far according to perf ... -e sq_misc.split_lock.

What's the actual scenario in the real world where a buslock access
might be legitimate?

And what's the advice, recommendation for a system administrator how to
analyze the situation and what kind of parameter to set?

I tried to get answers from Documentation/x86/buslock.rst, but ....

Thanks,

        tglx