public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Pavel Machek <pavel@denx.de>, Tony Luck <tony.luck@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	patches@lists.linux.dev
Subject: Re: [PATCH v2 1/2] x86/split_lock: Make life miserable for split lockers
Date: Thu, 17 Mar 2022 19:06:58 +0100	[thread overview]
Message-ID: <87fsngcv25.ffs@tglx> (raw)
In-Reply-To: <20220317111305.GB2237@amd>

On Thu, Mar 17 2022 at 12:13, Pavel Machek wrote:
>> In https://lore.kernel.org/all/87y22uujkm.ffs@tglx/ Thomas
>> said:
>> 
>>   Its's simply wishful thinking that stuff gets fixed because of a
>>   WARN_ONCE(). This has never worked. The only thing which works is to
>>   make stuff fail hard or slow it down in a way which makes it annoying
>>   enough to users to complain.
>> 
>> He was talking about WBINVD. But it made me think about how we
>> use the split lock detection feature in Linux.
>> 
>> Existing code has three options for applications:
>> 1) Don't enable split lock detection (allow arbitrary split locks)
>> 2) Warn once when a process uses split lock, but let the process
>>    keep running with split lock detection disabled
>> 3) Kill process that use split locks
>
> I'm not sure what split locks are, and if you want applications to
> stop doing that maybe documentation would help.

Split locks are lock prefixed operations which cross a cache line
boundary. The way how they are implemented is taking the bus lock, which
is the largest serialization hammer.

Bus locks are also triggered by lock prefixed operations on uncached
memory and on MMIO.

> Anyway, you can't really introduce regressions to userspace to "get
> stuff fixed" in applications.

Split locks can be triggered by unpriviledged user space and can be used
to run a local DoS attack. A very effective DoS to be clear.

We have no indication whether a process is malicious or just doing
stupid things. The only reason to not kill the offending process
instantly is that there can be legacy binary only executables which
trigger that due to stupidity.

But that opens up DoS at the same time. So the only way to "protect"
against that is to slow down the freqeuncy of buslocks unconditionally.
If you don't like that after analysing the situation you can turn split
lock detection off.

The only binary I've seen so far triggering this, is some stoneage "value
add" blob from HP which is also doing totally nuts other things.

Thanks,

        tglx

  parent reply	other threads:[~2022-03-17 18:07 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-17  1:27 [PATCH] x86/split_lock: Make life miserable for split lockers Tony Luck
2022-03-07 22:30 ` Thomas Gleixner
2022-03-08  0:37   ` Luck, Tony
2022-03-08 14:59     ` Thomas Gleixner
2022-03-08 17:12       ` Luck, Tony
2022-03-10 20:48 ` [PATCH v2 0/2] " Tony Luck
2022-03-10 20:48   ` [PATCH v2 1/2] x86/split_lock: " Tony Luck
2022-03-17 11:13     ` Pavel Machek
2022-03-17 16:27       ` Luck, Tony
2022-03-17 18:06       ` Thomas Gleixner [this message]
2022-03-17 22:21         ` David Laight
2022-03-17 22:40           ` Luck, Tony
2022-03-18 12:21             ` Fenghua Yu
2022-04-27 13:49     ` [tip: x86/splitlock] " tip-bot2 for Tony Luck
2022-03-10 20:48   ` [PATCH v2 2/2] x86/split-lock: Remove unused TIF_SLD bit Tony Luck
2022-04-27 13:49     ` [tip: x86/splitlock] " tip-bot2 for Tony Luck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87fsngcv25.ffs@tglx \
    --to=tglx@linutronix.de \
    --cc=fenghua.yu@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=patches@lists.linux.dev \
    --cc=pavel@denx.de \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox