From: Amit Cohen <amcohen(a)nvidia.com>
[ Upstream commit e67dfb8d15deb33c425d0b0ee22f2e5eef54c162 ]
Several tests do not set some ports down as part of their cleanup(),
resulting in IPv6 link-local addresses and associated routes not being
deleted.
These leaks were found using a BPF tool that monitors ASIC resources.
Solve this by setting the ports down at the end of the tests.
Signed-off-by: Amit Cohen <amcohen(a)nvidia.com>
Reviewed-by: Petr Machata <petrm(a)nvidia.com>
Signed-off-by: Ido Schimmel <idosch(a)nvidia.com>
Signed-off-by: David S. Miller <davem(a)davemloft.net>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
.../selftests/drivers/net/mlxsw/devlink_trap_l3_drops.sh | 3 +++
.../selftests/drivers/net/mlxsw/devlink_trap_l3_exceptions.sh | 3 +++
tools/testing/selftests/drivers/net/mlxsw/qos_dscp_bridge.sh | 2 ++
tools/testing/selftests/net/forwarding/pedit_dsfield.sh | 2 ++
tools/testing/selftests/net/forwarding/pedit_l4port.sh | 2 ++
tools/testing/selftests/net/forwarding/skbedit_priority.sh | 2 ++
6 files changed, 14 insertions(+)
diff --git a/tools/testing/selftests/drivers/net/mlxsw/devlink_trap_l3_drops.sh b/tools/testing/selftests/drivers/net/mlxsw/devlink_trap_l3_drops.sh
index 4029833f7e27..160891dcb4bc 100755
--- a/tools/testing/selftests/drivers/net/mlxsw/devlink_trap_l3_drops.sh
+++ b/tools/testing/selftests/drivers/net/mlxsw/devlink_trap_l3_drops.sh
@@ -109,6 +109,9 @@ router_destroy()
__addr_add_del $rp1 del 192.0.2.2/24 2001:db8:1::2/64
tc qdisc del dev $rp2 clsact
+
+ ip link set dev $rp2 down
+ ip link set dev $rp1 down
}
setup_prepare()
diff --git a/tools/testing/selftests/drivers/net/mlxsw/devlink_trap_l3_exceptions.sh b/tools/testing/selftests/drivers/net/mlxsw/devlink_trap_l3_exceptions.sh
index 42d44e27802c..190c1b6b5365 100755
--- a/tools/testing/selftests/drivers/net/mlxsw/devlink_trap_l3_exceptions.sh
+++ b/tools/testing/selftests/drivers/net/mlxsw/devlink_trap_l3_exceptions.sh
@@ -111,6 +111,9 @@ router_destroy()
__addr_add_del $rp1 del 192.0.2.2/24 2001:db8:1::2/64
tc qdisc del dev $rp2 clsact
+
+ ip link set dev $rp2 down
+ ip link set dev $rp1 down
}
setup_prepare()
diff --git a/tools/testing/selftests/drivers/net/mlxsw/qos_dscp_bridge.sh b/tools/testing/selftests/drivers/net/mlxsw/qos_dscp_bridge.sh
index 5cbff8038f84..28a570006d4d 100755
--- a/tools/testing/selftests/drivers/net/mlxsw/qos_dscp_bridge.sh
+++ b/tools/testing/selftests/drivers/net/mlxsw/qos_dscp_bridge.sh
@@ -93,7 +93,9 @@ switch_destroy()
lldptool -T -i $swp1 -V APP -d $(dscp_map 10) >/dev/null
lldpad_app_wait_del
+ ip link set dev $swp2 down
ip link set dev $swp2 nomaster
+ ip link set dev $swp1 down
ip link set dev $swp1 nomaster
ip link del dev br1
}
diff --git a/tools/testing/selftests/net/forwarding/pedit_dsfield.sh b/tools/testing/selftests/net/forwarding/pedit_dsfield.sh
index 55eeacf59241..64fbd211d907 100755
--- a/tools/testing/selftests/net/forwarding/pedit_dsfield.sh
+++ b/tools/testing/selftests/net/forwarding/pedit_dsfield.sh
@@ -75,7 +75,9 @@ switch_destroy()
tc qdisc del dev $swp2 clsact
tc qdisc del dev $swp1 clsact
+ ip link set dev $swp2 down
ip link set dev $swp2 nomaster
+ ip link set dev $swp1 down
ip link set dev $swp1 nomaster
ip link del dev br1
}
diff --git a/tools/testing/selftests/net/forwarding/pedit_l4port.sh b/tools/testing/selftests/net/forwarding/pedit_l4port.sh
index 5f20d289ee43..10e594c55117 100755
--- a/tools/testing/selftests/net/forwarding/pedit_l4port.sh
+++ b/tools/testing/selftests/net/forwarding/pedit_l4port.sh
@@ -71,7 +71,9 @@ switch_destroy()
tc qdisc del dev $swp2 clsact
tc qdisc del dev $swp1 clsact
+ ip link set dev $swp2 down
ip link set dev $swp2 nomaster
+ ip link set dev $swp1 down
ip link set dev $swp1 nomaster
ip link del dev br1
}
diff --git a/tools/testing/selftests/net/forwarding/skbedit_priority.sh b/tools/testing/selftests/net/forwarding/skbedit_priority.sh
index e3bd8a6bb8b4..bde11dc27873 100755
--- a/tools/testing/selftests/net/forwarding/skbedit_priority.sh
+++ b/tools/testing/selftests/net/forwarding/skbedit_priority.sh
@@ -72,7 +72,9 @@ switch_destroy()
tc qdisc del dev $swp2 clsact
tc qdisc del dev $swp1 clsact
+ ip link set dev $swp2 down
ip link set dev $swp2 nomaster
+ ip link set dev $swp1 down
ip link set dev $swp1 nomaster
ip link del dev br1
}
--
2.30.2
Hi all,
This patch series makes the RATIONAL symbol tristate, so it is not
forced builtin if all users are modular, and makes the
RATIONAL_KUNIT_TEST depend on RATIONAL, to avoid enabling RATIONAL if
there are no real users.
Changes compared to v1:
- Drop compile-testing and help text for RATIONAL.
- Make RATIONAL_KUNIT_TEST depend on RATIONAL.
Thanks for your comments!
[1] https://lore.kernel.org/r/20210705114633.1500710-1-geert@linux-m68k.org/
Geert Uytterhoeven (2):
math: Make RATIONAL tristate
math: RATIONAL_KUNIT_TEST should depend on RATIONAL instead of
selecting it
lib/Kconfig.debug | 3 +--
lib/math/Kconfig | 2 +-
lib/math/rational.c | 3 +++
3 files changed, 5 insertions(+), 3 deletions(-)
--
2.25.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert(a)linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
All but one symbols that select RATIONAL are tristate, but RATIONAL
itself is bool. Change it to tristate, so the rational fractions
support code can be modular if no builtin code relies on it.
While at it, add support for compile-testing and provide a help text.
Signed-off-by: Geert Uytterhoeven <geert(a)linux-m68k.org>
---
Exposed by commit b6c75c4afceb8bc0 ("lib/math/rational: add Kunit test
cases") and CONFIG_KUNIT_ALL_TESTS=m.
I'm not so happy RATIONAL_KUNIT_TEST selects RATIONAL, as test code
should depend on the presence of the feature to test. Else enabling
a test may add unneeded code to a production kernel.
Perhaps the "if COMPILE_TEST" should be dropped, making RATIONAL
visible, so RATIONAL_KUNIT_TEST can depend on RATIONAL instead?
---
lib/math/Kconfig | 5 ++++-
lib/math/rational.c | 3 +++
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/lib/math/Kconfig b/lib/math/Kconfig
index f19bc9734fa7cc4b..14def252ea7db6e0 100644
--- a/lib/math/Kconfig
+++ b/lib/math/Kconfig
@@ -14,4 +14,7 @@ config PRIME_NUMBERS
If unsure, say N.
config RATIONAL
- bool
+ tristate "Rational fractions support" if COMPILE_TEST
+ help
+ This option provides support for rational fractions.
+ This symbol should be selected automatically by drivers that need it.
diff --git a/lib/math/rational.c b/lib/math/rational.c
index c0ab51d8fbb98d17..ec59d426ea638b0f 100644
--- a/lib/math/rational.c
+++ b/lib/math/rational.c
@@ -13,6 +13,7 @@
#include <linux/export.h>
#include <linux/minmax.h>
#include <linux/limits.h>
+#include <linux/module.h>
/*
* calculate best rational approximation for a given fraction
@@ -106,3 +107,5 @@ void rational_best_approximation(
}
EXPORT_SYMBOL(rational_best_approximation);
+
+MODULE_LICENSE("GPL v2");
--
2.25.1
Hi,
From: John Wood <john.wood(a)gmx.com>
Date: Sat, 5 Jun 2021 17:04:00 +0200
> For a correct management of a fork brute force attack it is necessary to
> track all the information related to the application crashes. To do so,
> use the extended attributes (xattr) of the executable files and define a
> statistical data structure to hold all the necessary information shared
> by all the fork hierarchy processes. This info is the number of crashes,
> the last crash timestamp and the crash period's moving average.
>
> The same can be achieved using a pointer to the fork hierarchy
> statistical data held by the task_struct structure. But this has an
> important drawback: a brute force attack that happens through the execve
> system call losts the faults info since these statistics are freed when
> the fork hierarchy disappears. Using this method makes not possible to
> manage this attack type that can be successfully treated using extended
> attributes.
>
> Also, to avoid false positives during the attack detection it is
> necessary to narrow the possible cases. So, only the following scenarios
> are taken into account:
>
> 1.- Launching (fork()/exec()) a setuid/setgid process repeatedly until a
> desirable memory layout is got (e.g. Stack Clash).
> 2.- Connecting to an exec()ing network daemon (e.g. xinetd) repeatedly
> until a desirable memory layout is got (e.g. what CTFs do for simple
> network service).
> 3.- Launching processes without exec() (e.g. Android Zygote) and
> exposing state to attack a sibling.
> 4.- Connecting to a fork()ing network daemon (e.g. apache) repeatedly
> until the previously shared memory layout of all the other children
> is exposed (e.g. kind of related to HeartBleed).
>
> In each case, a privilege boundary has been crossed:
>
> Case 1: setuid/setgid process
> Case 2: network to local
> Case 3: privilege changes
> Case 4: network to local
>
> To mark that a privilege boundary has been crossed it is only necessary
> to create a new stats for the executable file via the extended attribute
> and only if it has no previous statistical data. This is done using four
> different LSM hooks, one per privilege boundary:
>
> setuid/setgid process --> bprm_creds_from_file hook (based on secureexec
> flag).
> network to local -------> socket_accept hook (taking into account only
> external connections).
> privilege changes ------> task_fix_setuid and task_fix_setgid hooks.
>
> To detect a brute force attack it is necessary that the executable file
> statistics be updated in every fatal crash and the most important data
> to update is the application crash period. To do so, use the new
> "task_fatal_signal" LSM hook added in a previous step.
>
> The application crash period must be a value that is not prone to change
> due to spurious data and follows the real crash period. So, to compute
> it, the exponential moving average (EMA) is used.
>
> Based on the updated statistics two different attacks can be handled. A
> slow brute force attack that is detected if the maximum number of faults
> per fork hierarchy is reached and a fast brute force attack that is
> detected if the application crash period falls below a certain
> threshold.
>
> Moreover, only the signals delivered by the kernel are taken into
> account with the exception of the SIGABRT signal since the latter is
> used by glibc for stack canary, malloc, etc failures, which may indicate
> that a mitigation has been triggered.
>
> Signed-off-by: John Wood <john.wood(a)gmx.com>
>
> <snip>
>
> +static int brute_get_xattr_stats(struct dentry *dentry, struct inode *inode,
> + struct brute_stats *stats)
> +{
> + int rc;
> + struct brute_raw_stats raw_stats;
> +
> + rc = __vfs_getxattr(dentry, inode, XATTR_NAME_BRUTE, &raw_stats,
> + sizeof(raw_stats));
> + if (rc < 0)
> + return rc;
> +
> + stats->faults = le32_to_cpu(raw_stats.faults);
> + stats->nsecs = le64_to_cpu(raw_stats.nsecs);
> + stats->period = le64_to_cpu(raw_stats.period);
> + stats->flags = raw_stats.flags;
> + return 0;
> +}
>
> <snip>
>
> +static int brute_task_execve(struct linux_binprm *bprm, struct file *file)
> +{
> + struct dentry *dentry = file_dentry(bprm->file);
> + struct inode *inode = file_inode(bprm->file);
> + struct brute_stats stats;
> + int rc;
> +
> + inode_lock(inode);
> + rc = brute_get_xattr_stats(dentry, inode, &stats);
> + if (WARN_ON_ONCE(rc && rc != -ENODATA))
> + goto unlock;
I think I caught a problem here. Have you tested this with
initramfs?
According to init/do_mount.c's
init_rootfs()/rootfs_init_fs_context(), when `root=` cmdline
parameter is not empty, kernel creates rootfs of type ramfs
(tmpfs otherwise).
The thing about ramfs is that it doesn't support xattrs.
I'm running this v8 on a regular PC with initramfs and having
`root=` in cmdline, and Brute doesn't allow the kernel to run
any init processes (/init, /sbin/init, ...) with err == -95
(-EOPNOTSUPP) -- I'm getting a
WARNING: CPU: 0 PID: 173 at brute_task_execve+0x15d/0x200
<snip>
Failed to execute /init (error -95)
and so on (and a panic at the end).
If I omit `root=` from cmdline, then the kernel runs init process
just fine -- I guess because initramfs is then placed inside tmpfs
with xattr support.
As for me, this ramfs/tmpfs selection based on `root=` presence
is ridiculous and I don't see or know any reasons behind that.
But that's another story, and ramfs might be not the only one
system without xattr support.
I think Brute should have a fallback here, e.g. it could simply
ignore files from xattr-incapable filesystems instead of such
WARNING splats and stuff.
> +
> + if (rc == -ENODATA && bprm->secureexec) {
> + brute_reset_stats(&stats);
> + rc = brute_set_xattr_stats(dentry, inode, &stats);
> + if (WARN_ON_ONCE(rc))
> + goto unlock;
> + }
> +
> + rc = 0;
> +unlock:
> + inode_unlock(inode);
> + return rc;
> +}
> +
>
> <snip>
Thanks,
Al
From: Tianjia Zhang <tianjia.zhang(a)linux.alibaba.com>
Q1 and Q2 are numbers with *maximum* length of 384 bytes. If the calculated
length of Q1 and Q2 is less than 384 bytes, things will go wrong.
E.g. if Q2 is 383 bytes, then
1. The bytes of q2 are copied to sigstruct->q2 in calc_q1q2().
2. The entire sigstruct->q2 is reversed, which results it being
256 * Q2, given that the last byte of sigstruct->q2 is added
to before the bytes given by calc_q1q2().
Either change in key or measurement can trigger the bug. E.g. an unmeasured
heap could cause a devastating change in Q1 or Q2.
Reverse exactly the bytes of Q1 and Q2 in calc_q1q2() before returning to
the caller.
Link: https://lore.kernel.org/linux-sgx/20210301051836.30738-1-tianjia.zhang@linu…
Signed-off-by: Tianjia Zhang <tianjia.zhang(a)linux.alibaba.com>
Signed-off-by: Jarkko Sakkinen <jarkko(a)kernel.org>
---
The original patch did a bad job explaining the code change but it
turned out making sense. I wrote a new description.
tools/testing/selftests/sgx/sigstruct.c | 41 +++++++++++++------------
1 file changed, 21 insertions(+), 20 deletions(-)
diff --git a/tools/testing/selftests/sgx/sigstruct.c b/tools/testing/selftests/sgx/sigstruct.c
index dee7a3d6c5a5..92bbc5a15c39 100644
--- a/tools/testing/selftests/sgx/sigstruct.c
+++ b/tools/testing/selftests/sgx/sigstruct.c
@@ -55,10 +55,27 @@ static bool alloc_q1q2_ctx(const uint8_t *s, const uint8_t *m,
return true;
}
+static void reverse_bytes(void *data, int length)
+{
+ int i = 0;
+ int j = length - 1;
+ uint8_t temp;
+ uint8_t *ptr = data;
+
+ while (i < j) {
+ temp = ptr[i];
+ ptr[i] = ptr[j];
+ ptr[j] = temp;
+ i++;
+ j--;
+ }
+}
+
static bool calc_q1q2(const uint8_t *s, const uint8_t *m, uint8_t *q1,
uint8_t *q2)
{
struct q1q2_ctx ctx;
+ int len;
if (!alloc_q1q2_ctx(s, m, &ctx)) {
fprintf(stderr, "Not enough memory for Q1Q2 calculation\n");
@@ -89,8 +106,10 @@ static bool calc_q1q2(const uint8_t *s, const uint8_t *m, uint8_t *q1,
goto out;
}
- BN_bn2bin(ctx.q1, q1);
- BN_bn2bin(ctx.q2, q2);
+ len = BN_bn2bin(ctx.q1, q1);
+ reverse_bytes(q1, len);
+ len = BN_bn2bin(ctx.q2, q2);
+ reverse_bytes(q2, len);
free_q1q2_ctx(&ctx);
return true;
@@ -152,22 +171,6 @@ static RSA *gen_sign_key(void)
return key;
}
-static void reverse_bytes(void *data, int length)
-{
- int i = 0;
- int j = length - 1;
- uint8_t temp;
- uint8_t *ptr = data;
-
- while (i < j) {
- temp = ptr[i];
- ptr[i] = ptr[j];
- ptr[j] = temp;
- i++;
- j--;
- }
-}
-
enum mrtags {
MRECREATE = 0x0045544145524345,
MREADD = 0x0000000044444145,
@@ -367,8 +370,6 @@ bool encl_measure(struct encl *encl)
/* BE -> LE */
reverse_bytes(sigstruct->signature, SGX_MODULUS_SIZE);
reverse_bytes(sigstruct->modulus, SGX_MODULUS_SIZE);
- reverse_bytes(sigstruct->q1, SGX_MODULUS_SIZE);
- reverse_bytes(sigstruct->q2, SGX_MODULUS_SIZE);
EVP_MD_CTX_destroy(ctx);
RSA_free(key);
--
2.32.0
I had posted a patch to fix a theoretical race with sysfs and device
removal [0]. While the issue is no longer present with the patch
present, the zram driver has already a lot of enhancements, so much so,
that the race alone is very difficult to reproduce. Likewise, the zram
driver had a series of other races on module removal which I recently
posted fixes for [1], and it makes it unclear if these paper over the
possible theoretical sysfs race. Although we even have gdb output
from an actual race where this issue presented itself, there are
other races which could happen before that and so what we realy need
is a clean separate driver where we can experiment and try to reproduce
unusual races.
This adds such a driver, a new sysfs_test driver, along with a set of
new tests for it. We take hint of observed issues with the sysfs on the
zram driver, and build sandbox based where wher can try to poke holes at
the kernel with.
There are two main races we're after trying to reproduce:
1) proving the deadlock is real
2) allowing for enough slack for us to try to see if we can
reproduce the syfs / device removal race
In order to tackle the second race, we need a bit of help from kernefs,
given that the race is difficult to reproduce. So we add fault injection
support to kernfs, which allows us to trigger all possible races on
write.
This should be enough evidence for us to drop the suggested patch for
sysfs for the second race. The first race however which leads to a
deadlock is clearly explained now and I hope this shows how we need a
generic solution.
[0] https://lkml.kernel.org/r/20210623215007.862787-1-mcgrof@kernel.org
[1] https://lkml.kernel.org/r/20210702043716.2692247-1-mcgrof@kernel.org
Luis Chamberlain (4):
selftests: add tests_sysfs module
kernfs: add initial failure injection support
test_sysfs: add support to use kernfs failure injection
test_sysfs: demonstrate deadlock fix
.../fault-injection/fault-injection.rst | 22 +
MAINTAINERS | 9 +-
fs/kernfs/Makefile | 1 +
fs/kernfs/failure-injection.c | 82 +
fs/kernfs/file.c | 13 +
fs/kernfs/kernfs-internal.h | 73 +
include/linux/kernfs.h | 5 +
lib/Kconfig.debug | 23 +
lib/Makefile | 1 +
lib/test_sysfs.c | 1037 +++++++++++++
tools/testing/selftests/sysfs/Makefile | 12 +
tools/testing/selftests/sysfs/config | 5 +
tools/testing/selftests/sysfs/sysfs.sh | 1376 +++++++++++++++++
13 files changed, 2658 insertions(+), 1 deletion(-)
create mode 100644 fs/kernfs/failure-injection.c
create mode 100644 lib/test_sysfs.c
create mode 100644 tools/testing/selftests/sysfs/Makefile
create mode 100644 tools/testing/selftests/sysfs/config
create mode 100755 tools/testing/selftests/sysfs/sysfs.sh
--
2.27.0
Hi Linus,
Please pull the following Kselftest update for Linux 5.14-rc1.
This Kselftest update for Linux 5.14-rc1 consists of fixes to
existing tests and framework:
-- migrate sgx test to kselftest harness
-- add new test cases to sgx test
-- ftrace test fix event-no-pid on 1-core machine
-- splice test adjust for handler fallback removal
diff is attached.
Apologies if this message appears to have double spacing. My email
client is at fault - I am trying to figure out what changed.
thanks,
-- Shuah
----------------------------------------------------------------
The following changes since commit d07f6ca923ea0927a1024dfccafc5b53b61cfecc:
Linux 5.13-rc2 (2021-05-16 15:27:44 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest
tags/linux-kselftest-next-5.14-rc1
for you to fetch changes up to 4896df9d53ae5521f3ce83751e828ad70bc65c80:
selftests/sgx: remove checks for file execute permissions (2021-06-23
18:38:04 -0600)
----------------------------------------------------------------
linux-kselftest-next-5.14-rc1
This Kselftest update for Linux 5.14-rc1 consists of fixes to
existing tests and framework:
-- migrate sgx test to kselftest harness
-- add new test cases to sgx test
-- ftrace test fix event-no-pid on 1-core machine
-- splice test adjust for handler fallback removal
----------------------------------------------------------------
Dave Hansen (1):
selftests/sgx: remove checks for file execute permissions
Jarkko Sakkinen (5):
selftests/sgx: Rename 'eenter' and 'sgx_call_vdso'
selftests/sgx: Migrate to kselftest harness
selftests/sgx: Dump enclave memory map
selftests/sgx: Add EXPECT_EEXIT() macro
selftests/sgx: Refine the test enclave to have storage
Kees Cook (3):
selftests/tls: Add {} to avoid static checker warning
selftests: splice: Adjust for handler fallback removal
selftests: lib.mk: Also install "config" and "settings"
Krzysztof Kozlowski (1):
selftests/ftrace: fix event-no-pid on 1-core machine
Po-Hsu Lin (1):
selftests: timers: rtcpie: skip test if default RTC device does
not exist
Xiaochen Shen (1):
selftests/resctrl: Fix incorrect parsing of option "-t"
.../selftests/ftrace/test.d/event/event-no-pid.tc | 7 +
tools/testing/selftests/lib.mk | 1 +
tools/testing/selftests/net/tls.c | 3 +-
tools/testing/selftests/resctrl/README | 2 +-
tools/testing/selftests/resctrl/resctrl_tests.c | 4 +-
tools/testing/selftests/sgx/call.S | 6 +-
tools/testing/selftests/sgx/defines.h | 10 +
tools/testing/selftests/sgx/load.c | 19 +-
tools/testing/selftests/sgx/main.c | 239
+++++++++++++--------
tools/testing/selftests/sgx/main.h | 4 +-
tools/testing/selftests/sgx/test_encl.c | 19 +-
tools/testing/selftests/sgx/test_encl.lds | 3 +-
.../testing/selftests/splice/short_splice_read.sh | 119 ++++++++--
tools/testing/selftests/timers/rtcpie.c | 10 +-
14 files changed, 308 insertions(+), 138 deletions(-)
----------------------------------------------------------------