[PATCH 0/4] x86/bus_lock: Set rate limit for bus lock

[PATCH 0/4] x86/bus_lock: Set rate limit for bus lock

[Fenghua Yu]

Bus lock warn and fatal handling is in tip. This series sets system
wide bus lock rate limit to throttle malicious code.

This series is applied on top of tip master branch.

Change Log:
-Set system wide rate limit instead of per-user rate limit (Thomas).
-Thomas suggested to split the previous bus lock into warn and fatal
patch set and this rate limit patch set:
https://lore.kernel.org/lkml/871rca6dbp.fsf@nanos.tec.linutronix.de/

Fenghua Yu (4):
  Documentation/x86: Add buslock.rst
  x86/bus_lock: Set rate limit for bus lock
  Documentation/admin-guide: Change doc for bus lock ratelimit
  Documentation/x86: Add ratelimit in buslock.rst

 .../admin-guide/kernel-parameters.txt         |   8 ++
 Documentation/x86/buslock.rst                 | 133 ++++++++++++++++++
 arch/x86/kernel/cpu/intel.c                   |  43 +++++-
 3 files changed, 182 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/x86/buslock.rst

-- 
2.31.1

[PATCH 1/4] Documentation/x86: Add buslock.rst

[Fenghua Yu]

Add buslock.rst to explain bus lock problem and how to detect and
handle it.

Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
Reviewed-by: Tony Luck <tony.luck@intel.com>
---
 Documentation/x86/buslock.rst | 110 ++++++++++++++++++++++++++++++++++
 1 file changed, 110 insertions(+)
 create mode 100644 Documentation/x86/buslock.rst

diff --git a/Documentation/x86/buslock.rst b/Documentation/x86/buslock.rst
new file mode 100644
index 000000000000..4deaf8b82338
--- /dev/null
+++ b/Documentation/x86/buslock.rst
@@ -0,0 +1,110 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===============================
+Bus lock detection and handling
+===============================
+
+:Copyright: |copy| 2021 Intel Corporation
+:Authors: - Fenghua Yu <fenghua.yu@intel.com>
+          - Tony Luck <tony.luck@intel.com>
+
+Problem
+=======
+
+A split lock is any atomic operation whose operand crosses two cache lines.
+Since the operand spans two cache lines and the operation must be atomic,
+the system locks the bus while the CPU accesses the two cache lines.
+
+A bus lock is acquired through either split locked access to writeback (WB)
+memory or any locked access to non-WB memory. This is typically thousands of
+cycles slower than an atomic operation within a cache line. It also disrupts
+performance on other cores and brings the whole system to its knees.
+
+Detection
+=========
+
+Intel processors may support either or both of the following hardware
+mechanisms to detect split locks and bus locks.
+
+#AC exception for split lock detection
+--------------------------------------
+
+Beginning with the Tremont Atom CPU split lock operations may raise an
+Alignment Check (#AC) exception when a split lock operation is attemped.
+
+#DB exception for bus lock detection
+------------------------------------
+
+Some CPUs have ability to notify the kernel by an #DB trap after a user
+instruction acquires a bus lock and is executed. This allows the kernel
+to enforce user application throttling or mitigation.
+
+Software handling
+=================
+
+The kernel #AC and #DB handlers handle bus lock based on kernel parameter
+"split_lock_detect". Here is a summary of different options:
+
++------------------+----------------------------+-----------------------+
+|split_lock_detect=|#AC for split lock		|#DB for bus lock	|
++------------------+----------------------------+-----------------------+
+|off	  	   |Do nothing			|Do nothing		|
++------------------+----------------------------+-----------------------+
+|warn		   |Kernel OOPs			|Warn once per task and |
+|(default)	   |Warn once per task and	|and continues to run.  |
+|		   |disable future checking	|			|
+|		   |When both features are	|			|
+|		   |supported, warn in #AC	|			|
++------------------+----------------------------+-----------------------+
+|fatal		   |Kernel OOPs			|Send SIGBUS to user.	|
+|		   |Send SIGBUS to user		|			|
+|		   |When both features are	|			|
+|		   |supported, fatal in #AC	|			|
++------------------+----------------------------+-----------------------+
+
+Usages
+======
+
+Detecting and handling bus lock may find usages in various areas:
+
+It is critical for real time system designers who build consolidated real
+time systems. These systems run hard real time code on some cores and
+run "untrusted" user processes on some other cores. The hard real time
+cannot afford to have any bus lock from the untrusted processes to hurt
+real time performance. To date the designers have been unable to deploy
+these solutions as they have no way to prevent the "untrusted" user code
+from generating split lock and bus lock to block the hard real time code
+to access memory during bus locking.
+
+It may also find usage in cloud. A user process with bus lock running
+in one guest can block other cores from accessing shared memory.
+
+Bus lock may open a security hole where malicious user code may slow
+down overall system by executing instructions with bus lock.
+
+
+Guidance
+========
+off
+---
+
+Disable checking for split lock and bus lock. This option may be
+useful if there are legacy applications that trigger these events
+at a low rate so that mitigation is not needed.
+
+warn
+----
+
+The bus lock is warned so that it can be found and fixed. This is the
+default behavior.
+
+It may be useful to find and fix bus lock. The warning information has
+process id and faulting instruction address to help pin point bus lock
+and fix it.
+
+fatal
+-----
+
+In this case, the bus lock is not tolerated and the process is killed.
+
+It is useful in hard real time system.
-- 
2.31.1

Re: [PATCH 1/4] Documentation/x86: Add buslock.rst

[Thomas Gleixner]

On Mon, Apr 19 2021 at 21:49, Fenghua Yu wrote:
> Add buslock.rst to explain bus lock problem and how to detect and
> handle it.

Documentation/x86/buslock.rst:7: WARNING: Undefined substitution referenced: "copy".
Documentation/x86/buslock.rst: WARNING: document isn't included in any toctree

Warnings are overrated...

[tip: x86/splitlock] Documentation/x86: Add buslock.rst

[tip-bot2 for Fenghua Yu]

The following commit has been merged into the x86/splitlock branch of tip:

Commit-ID:     1897907cca5aa22cdfcdb7fb8f0644a6add0877d
Gitweb:        https://git.kernel.org/tip/1897907cca5aa22cdfcdb7fb8f0644a6add0877d
Author:        Fenghua Yu <fenghua.yu@intel.com>
AuthorDate:    Mon, 19 Apr 2021 21:49:55 
Committer:     Thomas Gleixner <tglx@linutronix.de>
CommitterDate: Tue, 18 May 2021 16:39:31 +02:00

Documentation/x86: Add buslock.rst

Add buslock.rst to explain bus lock problem and how to detect and
handle it.

[ tglx: Included it into index.rst and added the missing include ... ]

Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Tony Luck <tony.luck@intel.com>
Link: https://lore.kernel.org/r/20210419214958.4035512-2-fenghua.yu@intel.com

---
 Documentation/x86/buslock.rst | 104 +++++++++++++++++++++++++++++++++-
 Documentation/x86/index.rst   |   1 +-
 2 files changed, 105 insertions(+)
 create mode 100644 Documentation/x86/buslock.rst

diff --git a/Documentation/x86/buslock.rst b/Documentation/x86/buslock.rst
new file mode 100644
index 0000000..159ff6b
--- /dev/null
+++ b/Documentation/x86/buslock.rst
@@ -0,0 +1,104 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. include:: <isonum.txt>
+
+===============================
+Bus lock detection and handling
+===============================
+
+:Copyright: |copy| 2021 Intel Corporation
+:Authors: - Fenghua Yu <fenghua.yu@intel.com>
+          - Tony Luck <tony.luck@intel.com>
+
+Problem
+=======
+
+A split lock is any atomic operation whose operand crosses two cache lines.
+Since the operand spans two cache lines and the operation must be atomic,
+the system locks the bus while the CPU accesses the two cache lines.
+
+A bus lock is acquired through either split locked access to writeback (WB)
+memory or any locked access to non-WB memory. This is typically thousands of
+cycles slower than an atomic operation within a cache line. It also disrupts
+performance on other cores and brings the whole system to its knees.
+
+Detection
+=========
+
+Intel processors may support either or both of the following hardware
+mechanisms to detect split locks and bus locks.
+
+#AC exception for split lock detection
+--------------------------------------
+
+Beginning with the Tremont Atom CPU split lock operations may raise an
+Alignment Check (#AC) exception when a split lock operation is attemped.
+
+#DB exception for bus lock detection
+------------------------------------
+
+Some CPUs have the ability to notify the kernel by an #DB trap after a user
+instruction acquires a bus lock and is executed. This allows the kernel to
+terminate the application or to enforce throttling.
+
+Software handling
+=================
+
+The kernel #AC and #DB handlers handle bus lock based on the kernel
+parameter "split_lock_detect". Here is a summary of different options:
+
++------------------+----------------------------+-----------------------+
+|split_lock_detect=|#AC for split lock		|#DB for bus lock	|
++------------------+----------------------------+-----------------------+
+|off	  	   |Do nothing			|Do nothing		|
++------------------+----------------------------+-----------------------+
+|warn		   |Kernel OOPs			|Warn once per task and |
+|(default)	   |Warn once per task and	|and continues to run.  |
+|		   |disable future checking	|			|
+|		   |When both features are	|			|
+|		   |supported, warn in #AC	|			|
++------------------+----------------------------+-----------------------+
+|fatal		   |Kernel OOPs			|Send SIGBUS to user.	|
+|		   |Send SIGBUS to user		|			|
+|		   |When both features are	|			|
+|		   |supported, fatal in #AC	|			|
++------------------+----------------------------+-----------------------+
+
+Usages
+======
+
+Detecting and handling bus lock may find usages in various areas:
+
+It is critical for real time system designers who build consolidated real
+time systems. These systems run hard real time code on some cores and run
+"untrusted" user processes on other cores. The hard real time cannot afford
+to have any bus lock from the untrusted processes to hurt real time
+performance. To date the designers have been unable to deploy these
+solutions as they have no way to prevent the "untrusted" user code from
+generating split lock and bus lock to block the hard real time code to
+access memory during bus locking.
+
+It's also useful for general computing to prevent guests or user
+applications from slowing down the overall system by executing instructions
+with bus lock.
+
+
+Guidance
+========
+off
+---
+
+Disable checking for split lock and bus lock. This option can be useful if
+there are legacy applications that trigger these events at a low rate so
+that mitigation is not needed.
+
+warn
+----
+
+A warning is emitted when a bus lock is detected which allows to identify
+the offending application. This is the default behavior.
+
+fatal
+-----
+
+In this case, the bus lock is not tolerated and the process is killed.
diff --git a/Documentation/x86/index.rst b/Documentation/x86/index.rst
index 4693e19..0004f5d 100644
--- a/Documentation/x86/index.rst
+++ b/Documentation/x86/index.rst
@@ -29,6 +29,7 @@ x86-specific Documentation
    microcode
    resctrl
    tsx_async_abort
+   buslock
    usb-legacy-support
    i386/index
    x86_64/index

Re: [tip: x86/splitlock] Documentation/x86: Add buslock.rst

[Xiaoyao Li]

On 5/18/2021 10:44 PM, tip-bot2 for Fenghua Yu wrote:
...
> +
> +Software handling
> +=================
> +
> +The kernel #AC and #DB handlers handle bus lock based on the kernel
> +parameter "split_lock_detect". Here is a summary of different options:
> +
> ++------------------+----------------------------+-----------------------+
> +|split_lock_detect=|#AC for split lock		|#DB for bus lock	|
> ++------------------+----------------------------+-----------------------+
> +|off	  	   |Do nothing			|Do nothing		|
> ++------------------+----------------------------+-----------------------+
> +|warn		   |Kernel OOPs			|Warn once per task and |
> +|(default)	   |Warn once per task and	|and continues to run.  |
> +|		   |disable future checking	|			|
> +|		   |When both features are	|			|
> +|		   |supported, warn in #AC	|			|
> ++------------------+----------------------------+-----------------------+
> +|fatal		   |Kernel OOPs			|Send SIGBUS to user.	|
> +|		   |Send SIGBUS to user		|			|
> +|		   |When both features are	|			|
> +|		   |supported, fatal in #AC	|			|
> ++------------------+----------------------------+-----------------------+
> +

Hi all,

I'm wonder if using only one "split_lock_detect" parameter for those two 
features is good/correct.

In fact, split lock is just one type of bus lock. There are two types 
bus lock:
1) split lock, lock on WB memory across multiple cache lines;
2) lock on non-WB memory;

As current design, if both features are available, it only enables #AC 
for split lock either for "warn" or "fatal". Thus we cannot capture any 
bus lock due to 2) lock on non-WB memory.

Why not provide separate parameter for them? e.g., split_lock_detect and 
bus_lock_detect. Then they can be configured and enabled independently.

Re: [tip: x86/splitlock] Documentation/x86: Add buslock.rst

[Fenghua Yu]

On Wed, Aug 18, 2021 at 09:59:49AM +0800, Xiaoyao Li wrote:
> On 5/18/2021 10:44 PM, tip-bot2 for Fenghua Yu wrote:
> I'm wonder if using only one "split_lock_detect" parameter for those two
> features is good/correct.
> 
> In fact, split lock is just one type of bus lock. There are two types bus
> lock:
> 1) split lock, lock on WB memory across multiple cache lines;
> 2) lock on non-WB memory;
> 
> As current design, if both features are available, it only enables #AC for
> split lock either for "warn" or "fatal". Thus we cannot capture any bus lock
> due to 2) lock on non-WB memory.
> 
> Why not provide separate parameter for them? e.g., split_lock_detect and
> bus_lock_detect. Then they can be configured and enabled independently.

#AC for split lock is a model specific feature and only available on limited
(and legacy) platforms. #DB for bus lock is an architectural feature and will
replace #AC for split lock in future platforms. The platforms that support
both of them are very rare (maybe only one AFAIK). Adding two parameters makes
code and usage complex while only one platform may get benefit in reality.

Thanks.

-Fenghua

Re: [tip: x86/splitlock] Documentation/x86: Add buslock.rst

[Xiaoyao Li]

On 8/18/2021 11:36 PM, Fenghua Yu wrote:
> On Wed, Aug 18, 2021 at 09:59:49AM +0800, Xiaoyao Li wrote:
>> On 5/18/2021 10:44 PM, tip-bot2 for Fenghua Yu wrote:
>> I'm wonder if using only one "split_lock_detect" parameter for those two
>> features is good/correct.
>>
>> In fact, split lock is just one type of bus lock. There are two types bus
>> lock:
>> 1) split lock, lock on WB memory across multiple cache lines;
>> 2) lock on non-WB memory;
>>
>> As current design, if both features are available, it only enables #AC for
>> split lock either for "warn" or "fatal". Thus we cannot capture any bus lock
>> due to 2) lock on non-WB memory.
>>
>> Why not provide separate parameter for them? e.g., split_lock_detect and
>> bus_lock_detect. Then they can be configured and enabled independently.
> 
> #AC for split lock is a model specific feature and only available on limited
> (and legacy) platforms. #DB for bus lock is an architectural feature and will
> replace #AC for split lock in future platforms. The platforms that support
> both of them are very rare (maybe only one AFAIK). 

I suppose you mean only SPR supports both.

> Adding two parameters makes
> code and usage complex while only one platform may get benefit in reality.

First, it's about correctness not easiness. Administrator wants to kill 
any user application that causes bus lock so setting 
"split_lock_detect=fatal". But it's possible that all non-WB bus lock 
escapes if the platform supports both feature.

(Yes, the parameter is called "split_lock_detect". It's no surprising 
that it can only detects split lock.)

Second, I don't think using two separate parameters makes code and usage 
complex. e.g.,

   - "split_lock_detect" for split lock feature, it can be
     [off|fatal|warn]
   - "bus_lock_detect" for bus lock feature, it can be
     [off|fatal|warn|ratelimit]

   Of course, kernel can print a message like "split/bus lock detection
   is not supported by silicon" when feature is not available.

Both features can work independently, and every combination can work wit 
h no issue.

Users are suggested to use "bus_lock_detect" to detect all bus lock and 
leave "split_lock_detect" to whatever. Of course they can only use 
"split_lock_detect" while leaving "bus_lock_detect" to off, if they are 
only interested in split lock.

> Thanks.
> 
> -Fenghua
> 

[PATCH 2/4] x86/bus_lock: Set rate limit for bus lock

[Fenghua Yu]

A bus lock can be thousands of cycles slower than atomic operation within
one cache line. It also disrupts performance on other cores. Malicious
users may generate multiple bus locks to degrade the whole system
performance.

To mitigate the issue, the kernel can set a system wide rate limit for
bus locks via a kernel parameter:
	split_lock_detect=ratelimit:N

When the system detects bus locks at a rate higher than N/sec (where
N can be set by the kernel boot argument in the range [1..1000]) any
task triggering a bus lock will be forced to sleep for at least 20ms
until the overall system rate of bus locks drops below the threshold.

Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
Reviewed-by: Tony Luck <tony.luck@intel.com>
---
 arch/x86/kernel/cpu/intel.c | 43 +++++++++++++++++++++++++++++++++++--
 1 file changed, 41 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index fe0bec14d7ec..149c4d33e8c4 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -10,6 +10,7 @@
 #include <linux/thread_info.h>
 #include <linux/init.h>
 #include <linux/uaccess.h>
+#include <linux/delay.h>
 
 #include <asm/cpufeature.h>
 #include <asm/msr.h>
@@ -41,6 +42,7 @@ enum split_lock_detect_state {
 	sld_off = 0,
 	sld_warn,
 	sld_fatal,
+	sld_ratelimit,
 };
 
 /*
@@ -997,13 +999,31 @@ static const struct {
 	{ "off",	sld_off   },
 	{ "warn",	sld_warn  },
 	{ "fatal",	sld_fatal },
+	{ "ratelimit:", sld_ratelimit },
 };
 
+static struct ratelimit_state bld_ratelimit;
+
 static inline bool match_option(const char *arg, int arglen, const char *opt)
 {
-	int len = strlen(opt);
+	int len = strlen(opt), ratelimit;
+
+	if (strncmp(arg, opt, len))
+		return false;
+
+	/*
+	 * Min ratelimit is 1 bus lock/sec.
+	 * Max ratelimit is 1000 bus locks/sec.
+	 */
+	if (sscanf(arg, "ratelimit:%d", &ratelimit) == 1 &&
+	    ratelimit > 0 && ratelimit <= 1000) {
+		ratelimit_state_init(&bld_ratelimit, HZ, ratelimit);
+		ratelimit_set_flags(&bld_ratelimit, RATELIMIT_MSG_ON_RELEASE);
 
-	return len == arglen && !strncmp(arg, opt, len);
+		return true;
+	}
+
+	return len == arglen;
 }
 
 static bool split_lock_verify_msr(bool on)
@@ -1082,6 +1102,15 @@ static void sld_update_msr(bool on)
 
 static void split_lock_init(void)
 {
+	/*
+	 * #DB for bus lock handles ratelimit and #AC for split lock is
+	 * disabled.
+	 */
+	if (sld_state == sld_ratelimit) {
+		split_lock_verify_msr(false);
+		return;
+	}
+
 	if (cpu_model_supports_sld)
 		split_lock_verify_msr(sld_state != sld_off);
 }
@@ -1154,6 +1183,12 @@ void handle_bus_lock(struct pt_regs *regs)
 	switch (sld_state) {
 	case sld_off:
 		break;
+	case sld_ratelimit:
+		/* Enforce no more than bld_ratelimit bus locks/sec. */
+		while (!__ratelimit(&bld_ratelimit))
+			msleep(20);
+		/* Warn on the bus lock. */
+		fallthrough;
 	case sld_warn:
 		pr_warn_ratelimited("#DB: %s/%d took a bus_lock trap at address: 0x%lx\n",
 				    current->comm, current->pid, regs->ip);
@@ -1259,6 +1294,10 @@ static void sld_state_show(void)
 				" from non-WB" : "");
 		}
 		break;
+	case sld_ratelimit:
+		if (boot_cpu_has(X86_FEATURE_BUS_LOCK_DETECT))
+			pr_info("#DB: setting system wide bus lock rate limit to %u/sec\n", bld_ratelimit.burst);
+		break;
 	}
 }
 
-- 
2.31.1

[tip: x86/splitlock] x86/bus_lock: Set rate limit for bus lock

[tip-bot2 for Fenghua Yu]

The following commit has been merged into the x86/splitlock branch of tip:

Commit-ID:     ef4ae6e4413159d2329a172c12e9274e2cb0a3a8
Gitweb:        https://git.kernel.org/tip/ef4ae6e4413159d2329a172c12e9274e2cb0a3a8
Author:        Fenghua Yu <fenghua.yu@intel.com>
AuthorDate:    Mon, 19 Apr 2021 21:49:56 
Committer:     Thomas Gleixner <tglx@linutronix.de>
CommitterDate: Tue, 18 May 2021 16:39:31 +02:00

x86/bus_lock: Set rate limit for bus lock

A bus lock can be thousands of cycles slower than atomic operation within
one cache line. It also disrupts performance on other cores. Malicious
users can generate multiple bus locks to degrade the whole system
performance.

The current mitigation is to kill the offending process, but for certain
scenarios it's desired to identify and throttle the offending application.

Add a system wide rate limit for bus locks. When the system detects bus
locks at a rate higher than N/sec (where N can be set by the kernel boot
argument in the range [1..1000]) any task triggering a bus lock will be
forced to sleep for at least 20ms until the overall system rate of bus
locks drops below the threshold.

Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Tony Luck <tony.luck@intel.com>
Link: https://lore.kernel.org/r/20210419214958.4035512-3-fenghua.yu@intel.com

---
 arch/x86/kernel/cpu/intel.c | 42 ++++++++++++++++++++++++++++++++++--
 1 file changed, 40 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/cpu/intel.c b/arch/x86/kernel/cpu/intel.c
index 8adffc1..7c23f03 100644
--- a/arch/x86/kernel/cpu/intel.c
+++ b/arch/x86/kernel/cpu/intel.c
@@ -10,6 +10,7 @@
 #include <linux/thread_info.h>
 #include <linux/init.h>
 #include <linux/uaccess.h>
+#include <linux/delay.h>
 
 #include <asm/cpufeature.h>
 #include <asm/msr.h>
@@ -41,6 +42,7 @@ enum split_lock_detect_state {
 	sld_off = 0,
 	sld_warn,
 	sld_fatal,
+	sld_ratelimit,
 };
 
 /*
@@ -997,13 +999,30 @@ static const struct {
 	{ "off",	sld_off   },
 	{ "warn",	sld_warn  },
 	{ "fatal",	sld_fatal },
+	{ "ratelimit:", sld_ratelimit },
 };
 
+static struct ratelimit_state bld_ratelimit;
+
 static inline bool match_option(const char *arg, int arglen, const char *opt)
 {
-	int len = strlen(opt);
+	int len = strlen(opt), ratelimit;
+
+	if (strncmp(arg, opt, len))
+		return false;
+
+	/*
+	 * Min ratelimit is 1 bus lock/sec.
+	 * Max ratelimit is 1000 bus locks/sec.
+	 */
+	if (sscanf(arg, "ratelimit:%d", &ratelimit) == 1 &&
+	    ratelimit > 0 && ratelimit <= 1000) {
+		ratelimit_state_init(&bld_ratelimit, HZ, ratelimit);
+		ratelimit_set_flags(&bld_ratelimit, RATELIMIT_MSG_ON_RELEASE);
+		return true;
+	}
 
-	return len == arglen && !strncmp(arg, opt, len);
+	return len == arglen;
 }
 
 static bool split_lock_verify_msr(bool on)
@@ -1082,6 +1101,15 @@ static void sld_update_msr(bool on)
 
 static void split_lock_init(void)
 {
+	/*
+	 * #DB for bus lock handles ratelimit and #AC for split lock is
+	 * disabled.
+	 */
+	if (sld_state == sld_ratelimit) {
+		split_lock_verify_msr(false);
+		return;
+	}
+
 	if (cpu_model_supports_sld)
 		split_lock_verify_msr(sld_state != sld_off);
 }
@@ -1154,6 +1182,12 @@ void handle_bus_lock(struct pt_regs *regs)
 	switch (sld_state) {
 	case sld_off:
 		break;
+	case sld_ratelimit:
+		/* Enforce no more than bld_ratelimit bus locks/sec. */
+		while (!__ratelimit(&bld_ratelimit))
+			msleep(20);
+		/* Warn on the bus lock. */
+		fallthrough;
 	case sld_warn:
 		pr_warn_ratelimited("#DB: %s/%d took a bus_lock trap at address: 0x%lx\n",
 				    current->comm, current->pid, regs->ip);
@@ -1259,6 +1293,10 @@ static void sld_state_show(void)
 				" from non-WB" : "");
 		}
 		break;
+	case sld_ratelimit:
+		if (boot_cpu_has(X86_FEATURE_BUS_LOCK_DETECT))
+			pr_info("#DB: setting system wide bus lock rate limit to %u/sec\n", bld_ratelimit.burst);
+		break;
 	}
 }
 

[PATCH 3/4] Documentation/admin-guide: Change doc for bus lock ratelimit

[Fenghua Yu]

Since bus lock rate limit changes the split_lock_detect parameter,
update the documentation for the change.

Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
Reviewed-by: Tony Luck <tony.luck@intel.com>
---
 Documentation/admin-guide/kernel-parameters.txt | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index f5892896bedc..c13bbfd8c5aa 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -5154,6 +5154,14 @@
 				  exception. Default behavior is by #AC if
 				  both features are enabled in hardware.
 
+			ratelimit:N -
+				  Set system wide rate limit to N bus locks
+				  per second for bus lock detection.
+				  0 < N <= 1000.
+
+				  N/A for split lock detection.
+
+
 			If an #AC exception is hit in the kernel or in
 			firmware (i.e. not while executing in user mode)
 			the kernel will oops in either "warn" or "fatal"
-- 
2.31.1

[tip: x86/splitlock] Documentation/admin-guide: Add bus lock ratelimit

[tip-bot2 for Fenghua Yu]

The following commit has been merged into the x86/splitlock branch of tip:

Commit-ID:     9d839c280b64817345c2fa462c0027a9bd742361
Gitweb:        https://git.kernel.org/tip/9d839c280b64817345c2fa462c0027a9bd742361
Author:        Fenghua Yu <fenghua.yu@intel.com>
AuthorDate:    Mon, 19 Apr 2021 21:49:57 
Committer:     Thomas Gleixner <tglx@linutronix.de>
CommitterDate: Tue, 18 May 2021 16:39:31 +02:00

Documentation/admin-guide: Add bus lock ratelimit

Since bus lock rate limit changes the split_lock_detect parameter,
update the documentation for the change.

Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Tony Luck <tony.luck@intel.com>
Link: https://lore.kernel.org/r/20210419214958.4035512-4-fenghua.yu@intel.com

---
 Documentation/admin-guide/kernel-parameters.txt | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index cb89dbd..ca94624 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -5283,6 +5283,14 @@
 				  exception. Default behavior is by #AC if
 				  both features are enabled in hardware.
 
+			ratelimit:N -
+				  Set system wide rate limit to N bus locks
+				  per second for bus lock detection.
+				  0 < N <= 1000.
+
+				  N/A for split lock detection.
+
+
 			If an #AC exception is hit in the kernel or in
 			firmware (i.e. not while executing in user mode)
 			the kernel will oops in either "warn" or "fatal"

[PATCH 4/4] Documentation/x86: Add ratelimit in buslock.rst

[Fenghua Yu]

ratelimit is a new option in bus lock handling. Need to add it in
buslock.rst.

Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
Reviewed-by: Tony Luck <tony.luck@intel.com>
---
 Documentation/x86/buslock.rst | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/Documentation/x86/buslock.rst b/Documentation/x86/buslock.rst
index 4deaf8b82338..87ee5925cb5c 100644
--- a/Documentation/x86/buslock.rst
+++ b/Documentation/x86/buslock.rst
@@ -61,6 +61,11 @@ The kernel #AC and #DB handlers handle bus lock based on kernel parameter
 |		   |When both features are	|			|
 |		   |supported, fatal in #AC	|			|
 +------------------+----------------------------+-----------------------+
+|ratelimit:N	   |Do nothing			|Limit bus lock rate to	|
+|(0 < N <= 1000)   |				|N bus locks per second	|
+|		   |				|system wide and warn on|
+|		   |				|bus locks.		|
++------------------+----------------------------+-----------------------+
 
 Usages
 ======
@@ -108,3 +113,21 @@ fatal
 In this case, the bus lock is not tolerated and the process is killed.
 
 It is useful in hard real time system.
+
+ratelimit
+---------
+
+A system wide bus lock rate limit N is specified where 0 < N <= 1000.
+Less bus locks can be generated when N is smaller.
+
+This may find usage in throttling malicious processes in cloud. For
+example, a few malicious users may generate a lot of bus locks to launch
+Denial of Service (DoS) attack. By setting ratelimit, the system wide
+bus locks is rate limited by N bus locks per second and the DoS attack
+will be mitigated. The bus locks are warned so that the system
+administrator can found the malicious users and processes.
+
+Selecting a rate limit of 1000 would allow the bus to be locked for
+up to about seven million cycles each second (assuming 7000 cycles for
+each bus lock). On a 2 GHz processor that would be about 0.35% system
+impact.
-- 
2.31.1

[tip: x86/splitlock] Documentation/x86: Add ratelimit in buslock.rst

[tip-bot2 for Fenghua Yu]

The following commit has been merged into the x86/splitlock branch of tip:

Commit-ID:     d28397eaf4c27947a1ffc720d42e8b3a33ae1e2a
Gitweb:        https://git.kernel.org/tip/d28397eaf4c27947a1ffc720d42e8b3a33ae1e2a
Author:        Fenghua Yu <fenghua.yu@intel.com>
AuthorDate:    Mon, 19 Apr 2021 21:49:58 
Committer:     Thomas Gleixner <tglx@linutronix.de>
CommitterDate: Tue, 18 May 2021 16:39:31 +02:00

Documentation/x86: Add ratelimit in buslock.rst

ratelimit is a new command line option for bus lock handling. Add proper
documentation.

[ tglx: Massaged documentation ]

Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Tony Luck <tony.luck@intel.com>
Link: https://lore.kernel.org/r/20210419214958.4035512-5-fenghua.yu@intel.com

---
 Documentation/x86/buslock.rst | 22 ++++++++++++++++++++++
 1 file changed, 22 insertions(+)

diff --git a/Documentation/x86/buslock.rst b/Documentation/x86/buslock.rst
index 159ff6b..7c051e7 100644
--- a/Documentation/x86/buslock.rst
+++ b/Documentation/x86/buslock.rst
@@ -63,6 +63,11 @@ parameter "split_lock_detect". Here is a summary of different options:
 |		   |When both features are	|			|
 |		   |supported, fatal in #AC	|			|
 +------------------+----------------------------+-----------------------+
+|ratelimit:N	   |Do nothing			|Limit bus lock rate to	|
+|(0 < N <= 1000)   |				|N bus locks per second	|
+|		   |				|system wide and warn on|
+|		   |				|bus locks.		|
++------------------+----------------------------+-----------------------+
 
 Usages
 ======
@@ -102,3 +107,20 @@ fatal
 -----
 
 In this case, the bus lock is not tolerated and the process is killed.
+
+ratelimit
+---------
+
+A system wide bus lock rate limit N is specified where 0 < N <= 1000. This
+allows a bus lock rate up to N bus locks per second. When the bus lock rate
+is exceeded then any task which is caught via the buslock #DB exception is
+throttled by enforced sleeps until the rate goes under the limit again.
+
+This is an effective mitigation in cases where a minimal impact can be
+tolerated, but an eventual Denial of Service attack has to be prevented. It
+allows to identify the offending processes and analyze whether they are
+malicious or just badly written.
+
+Selecting a rate limit of 1000 allows the bus to be locked for up to about
+seven million cycles each second (assuming 7000 cycles for each bus
+lock). On a 2 GHz processor that would be about 0.35% system slowdown.

Re: [PATCH 0/4] x86/bus_lock: Set rate limit for bus lock

[Fenghua Yu]

Hi, Dear X86 maintainers,

On Mon, Apr 19, 2021 at 09:49:54PM +0000, Fenghua Yu wrote:
> Bus lock warn and fatal handling is in tip. This series sets system
> wide bus lock rate limit to throttle malicious code.
> 
> This series is applied on top of tip master branch.
> 
> Change Log:
> -Set system wide rate limit instead of per-user rate limit (Thomas).
> -Thomas suggested to split the previous bus lock into warn and fatal
> patch set and this rate limit patch set:
> https://lore.kernel.org/lkml/871rca6dbp.fsf@nanos.tec.linutronix.de/

Any comment on this series?

The series can be applied to 5.13-rc cleanly without any change.

Thanks.

-Fenghua

Re: [PATCH 0/4] x86/bus_lock: Set rate limit for bus lock

[Thomas Gleixner]

On Mon, May 17 2021 at 18:46, Fenghua Yu wrote:
> Hi, Dear X86 maintainers,
>
> On Mon, Apr 19, 2021 at 09:49:54PM +0000, Fenghua Yu wrote:
>> Bus lock warn and fatal handling is in tip. This series sets system
>> wide bus lock rate limit to throttle malicious code.
>> 
>> This series is applied on top of tip master branch.
>> 
>> Change Log:
>> -Set system wide rate limit instead of per-user rate limit (Thomas).
>> -Thomas suggested to split the previous bus lock into warn and fatal
>> patch set and this rate limit patch set:
>> https://lore.kernel.org/lkml/871rca6dbp.fsf@nanos.tec.linutronix.de/
>
> Any comment on this series?
>
> The series can be applied to 5.13-rc cleanly without any change.

It's on my todo list already.

Re: [PATCH 0/4] x86/bus_lock: Set rate limit for bus lock

[Fenghua Yu]

On Mon, May 17, 2021 at 09:01:57PM +0200, Thomas Gleixner wrote:
> On Mon, May 17 2021 at 18:46, Fenghua Yu wrote:
> > On Mon, Apr 19, 2021 at 09:49:54PM +0000, Fenghua Yu wrote:
> >> Bus lock warn and fatal handling is in tip. This series sets system
> It's on my todo list already.

Thank you very much, Thomas!

-Fenghua