- Linux-kselftest-mirror - lists.linaro.org

[PATCH 5.10 355/663] kselftests: dmabuf-heaps: Fix Makefiles inclusion of the kernels usr/include dir

by Greg Kroah-Hartman

From: John Stultz <john.stultz(a)linaro.org> [ Upstream commit 64ba3d591c9d2be2a9c09e99b00732afe002ad0d ] Copied in from somewhere else, the makefile was including the kerne's usr/include dir, which caused the asm/ioctl.h file to be used. Unfortunately, that file has different values for _IOC_SIZEBITS and _IOC_WRITE than include/uapi/asm-generic/ioctl.h which then causes the _IOCW macros to give the wrong ioctl numbers, specifically for DMA_BUF_IOCTL_SYNC. This patch simply removes the extra include from the Makefile Cc: Shuah Khan <shuah(a)kernel.org> Cc: Brian Starkey <brian.starkey(a)arm.com> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: Laura Abbott <labbott(a)kernel.org> Cc: Hridya Valsaraju <hridya(a)google.com> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Sandeep Patil <sspatil(a)google.com> Cc: Daniel Mentz <danielmentz(a)google.com> Cc: linux-media(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Cc: linux-kselftest(a)vger.kernel.org Fixes: a8779927fd86c ("kselftests: Add dma-heap test") Signed-off-by: John Stultz <john.stultz(a)linaro.org> Signed-off-by: Shuah Khan <skhan(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- tools/testing/selftests/dmabuf-heaps/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/dmabuf-heaps/Makefile b/tools/testing/selftests/dmabuf-heaps/Makefile index 607c2acd20829..604b43ece15f5 100644 --- a/tools/testing/selftests/dmabuf-heaps/Makefile +++ b/tools/testing/selftests/dmabuf-heaps/Makefile @@ -1,5 +1,5 @@ # SPDX-License-Identifier: GPL-2.0 -CFLAGS += -static -O3 -Wl,-no-as-needed -Wall -I../../../../usr/include +CFLAGS += -static -O3 -Wl,-no-as-needed -Wall TEST_GEN_PROGS = dmabuf-heap -- 2.27.0

4 years, 6 months

1
0
0 0

[PATCH 5.11 430/775] kselftests: dmabuf-heaps: Fix Makefiles inclusion of the kernels usr/include dir

by Greg Kroah-Hartman

From: John Stultz <john.stultz(a)linaro.org> [ Upstream commit 64ba3d591c9d2be2a9c09e99b00732afe002ad0d ] Copied in from somewhere else, the makefile was including the kerne's usr/include dir, which caused the asm/ioctl.h file to be used. Unfortunately, that file has different values for _IOC_SIZEBITS and _IOC_WRITE than include/uapi/asm-generic/ioctl.h which then causes the _IOCW macros to give the wrong ioctl numbers, specifically for DMA_BUF_IOCTL_SYNC. This patch simply removes the extra include from the Makefile Cc: Shuah Khan <shuah(a)kernel.org> Cc: Brian Starkey <brian.starkey(a)arm.com> Cc: Sumit Semwal <sumit.semwal(a)linaro.org> Cc: Laura Abbott <labbott(a)kernel.org> Cc: Hridya Valsaraju <hridya(a)google.com> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Sandeep Patil <sspatil(a)google.com> Cc: Daniel Mentz <danielmentz(a)google.com> Cc: linux-media(a)vger.kernel.org Cc: dri-devel(a)lists.freedesktop.org Cc: linux-kselftest(a)vger.kernel.org Fixes: a8779927fd86c ("kselftests: Add dma-heap test") Signed-off-by: John Stultz <john.stultz(a)linaro.org> Signed-off-by: Shuah Khan <skhan(a)linuxfoundation.org> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- tools/testing/selftests/dmabuf-heaps/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/dmabuf-heaps/Makefile b/tools/testing/selftests/dmabuf-heaps/Makefile index 607c2acd20829..604b43ece15f5 100644 --- a/tools/testing/selftests/dmabuf-heaps/Makefile +++ b/tools/testing/selftests/dmabuf-heaps/Makefile @@ -1,5 +1,5 @@ # SPDX-License-Identifier: GPL-2.0 -CFLAGS += -static -O3 -Wl,-no-as-needed -Wall -I../../../../usr/include +CFLAGS += -static -O3 -Wl,-no-as-needed -Wall TEST_GEN_PROGS = dmabuf-heap -- 2.27.0

4 years, 6 months

1
0
0 0

[PATCH v4 0/8] Fork brute force attack mitigation

by John Wood

Attacks against vulnerable userspace applications with the purpose to break ASLR or bypass canaries traditionally use some level of brute force with the help of the fork system call. This is possible since when creating a new process using fork its memory contents are the same as those of the parent process (the process that called the fork system call). So, the attacker can test the memory infinite times to find the correct memory values or the correct memory addresses without worrying about crashing the application. Based on the above scenario it would be nice to have this detected and mitigated, and this is the goal of this patch serie. Specifically the following attacks are expected to be detected: 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 So, what will really be detected are fork/exec brute force attacks that cross any of the commented bounds. The implementation details and comparison against other existing implementations can be found in the "Documentation" patch. This v4 version has changed a lot from the v2. Basically the application crash period is now compute on an on-going basis using an exponential moving average (EMA), a detection of a brute force attack through the "execve" system call has been added and the crossing of the commented privilege bounds are taken into account. Also, the fine tune has also been removed and now, all this kind of attacks are detected without administrator intervention. In the v2 version Kees Cook suggested to study if the statistical data shared by all the fork hierarchy processes can be tracked in some other way. Specifically the question was if this info can be hold by the family hierarchy of the mm struct. After studying this hierarchy I think it is not suitable for the Brute LSM since they are totally copied on fork() and in this case we want that they are shared. So I leave this road. So, knowing all this information I will explain now the different patches: The 1/8 patch defines a new LSM hook to get the fatal signal of a task. This will be useful during the attack detection phase. The 2/8 patch defines a new LSM and manages the statistical data shared by all the fork hierarchy processes. The 3/8 patch detects a fork/exec brute force attack. The 4/8 patch narrows the detection taken into account the privilege boundary crossing. The 5/8 patch mitigates a brute force attack. The 6/8 patch adds self-tests to validate the Brute LSM expectations. The 7/8 patch adds the documentation to explain this implementation. The 8/8 patch updates the maintainers file. This patch serie is a task of the KSPP [1] and can also be accessed from my github tree [2] in the "brute_v4" branch. [1] https://github.com/KSPP/linux/issues/39 [2] https://github.com/johwood/linux/ The previous versions can be found in: RFC https://lore.kernel.org/kernel-hardening/20200910202107.3799376-1-keescook@… Version 2 https://lore.kernel.org/kernel-hardening/20201025134540.3770-1-john.wood@gm… Version 3 https://lore.kernel.org/lkml/20210221154919.68050-1-john.wood@gmx.com/ Changelog RFC -> v2 ------------------- - Rename this feature with a more suitable name (Jann Horn, Kees Cook). - Convert the code to an LSM (Kees Cook). - Add locking to avoid data races (Jann Horn). - Add a new LSM hook to get the fatal signal of a task (Jann Horn, Kees Cook). - Add the last crashes timestamps list to avoid false positives in the attack detection (Jann Horn). - Use "period" instead of "rate" (Jann Horn). - Other minor changes suggested (Jann Horn, Kees Cook). Changelog v2 -> v3 ------------------ - Compute the application crash period on an on-going basis (Kees Cook). - Detect a brute force attack through the execve system call (Kees Cook). - Detect an slow brute force attack (Randy Dunlap). - Fine tuning the detection taken into account privilege boundary crossing (Kees Cook). - Taken into account only fatal signals delivered by the kernel (Kees Cook). - Remove the sysctl attributes to fine tuning the detection (Kees Cook). - Remove the prctls to allow per process enabling/disabling (Kees Cook). - Improve the documentation (Kees Cook). - Fix some typos in the documentation (Randy Dunlap). - Add self-test to validate the expectations (Kees Cook). Changelog v3 -> v4 ------------------ - Fix all the warnings shown by the tool "scripts/kernel-doc" (Randy Dunlap). Any constructive comments are welcome. Thanks. John Wood (8): security: Add LSM hook at the point where a task gets a fatal signal security/brute: Define a LSM and manage statistical data securtiy/brute: Detect a brute force attack security/brute: Fine tuning the attack detection security/brute: Mitigate a brute force attack selftests/brute: Add tests for the Brute LSM Documentation: Add documentation for the Brute LSM MAINTAINERS: Add a new entry for the Brute LSM Documentation/admin-guide/LSM/Brute.rst | 224 +++++ Documentation/admin-guide/LSM/index.rst | 1 + MAINTAINERS | 7 + include/linux/lsm_hook_defs.h | 1 + include/linux/lsm_hooks.h | 4 + include/linux/security.h | 4 + kernel/signal.c | 1 + security/Kconfig | 11 +- security/Makefile | 4 + security/brute/Kconfig | 13 + security/brute/Makefile | 2 + security/brute/brute.c | 1102 ++++++++++++++++++++++ security/security.c | 5 + tools/testing/selftests/Makefile | 1 + tools/testing/selftests/brute/.gitignore | 2 + tools/testing/selftests/brute/Makefile | 5 + tools/testing/selftests/brute/config | 1 + tools/testing/selftests/brute/exec.c | 44 + tools/testing/selftests/brute/test.c | 507 ++++++++++ tools/testing/selftests/brute/test.sh | 226 +++++ 20 files changed, 2160 insertions(+), 5 deletions(-) create mode 100644 Documentation/admin-guide/LSM/Brute.rst create mode 100644 security/brute/Kconfig create mode 100644 security/brute/Makefile create mode 100644 security/brute/brute.c create mode 100644 tools/testing/selftests/brute/.gitignore create mode 100644 tools/testing/selftests/brute/Makefile create mode 100644 tools/testing/selftests/brute/config create mode 100644 tools/testing/selftests/brute/exec.c create mode 100644 tools/testing/selftests/brute/test.c create mode 100755 tools/testing/selftests/brute/test.sh -- 2.25.1

4 years, 6 months

1
1
0 0

[PATCH v6 6/6] selftest/x86/signal: Include test cases for validating sigaltstack

by Chang S. Bae

The test measures the kernel's signal delivery with different (enough vs. insufficient) stack sizes. Signed-off-by: Chang S. Bae <chang.seok.bae(a)intel.com> Reviewed-by: Len Brown <len.brown(a)intel.com> Cc: x86(a)kernel.org Cc: linux-kselftest(a)vger.kernel.org Cc: linux-kernel(a)vger.kernel.org --- Changes from v3: * Revised test messages again (Borislav Petkov) Changes from v2: * Revised test messages (Borislav Petkov) --- tools/testing/selftests/x86/Makefile | 2 +- tools/testing/selftests/x86/sigaltstack.c | 128 ++++++++++++++++++++++ 2 files changed, 129 insertions(+), 1 deletion(-) create mode 100644 tools/testing/selftests/x86/sigaltstack.c diff --git a/tools/testing/selftests/x86/Makefile b/tools/testing/selftests/x86/Makefile index 333980375bc7..65bba2ae86ee 100644 --- a/tools/testing/selftests/x86/Makefile +++ b/tools/testing/selftests/x86/Makefile @@ -13,7 +13,7 @@ CAN_BUILD_WITH_NOPIE := $(shell ./check_cc.sh $(CC) trivial_program.c -no-pie) TARGETS_C_BOTHBITS := single_step_syscall sysret_ss_attrs syscall_nt test_mremap_vdso \ check_initial_reg_state sigreturn iopl ioperm \ test_vsyscall mov_ss_trap \ - syscall_arg_fault fsgsbase_restore + syscall_arg_fault fsgsbase_restore sigaltstack TARGETS_C_32BIT_ONLY := entry_from_vm86 test_syscall_vdso unwind_vdso \ test_FCMOV test_FCOMI test_FISTTP \ vdso_restorer diff --git a/tools/testing/selftests/x86/sigaltstack.c b/tools/testing/selftests/x86/sigaltstack.c new file mode 100644 index 000000000000..f689af75e979 --- /dev/null +++ b/tools/testing/selftests/x86/sigaltstack.c @@ -0,0 +1,128 @@ +// SPDX-License-Identifier: GPL-2.0-only + +#define _GNU_SOURCE +#include <signal.h> +#include <stdio.h> +#include <stdbool.h> +#include <string.h> +#include <err.h> +#include <errno.h> +#include <limits.h> +#include <sys/mman.h> +#include <sys/auxv.h> +#include <sys/prctl.h> +#include <sys/resource.h> +#include <setjmp.h> + +/* sigaltstack()-enforced minimum stack */ +#define ENFORCED_MINSIGSTKSZ 2048 + +#ifndef AT_MINSIGSTKSZ +# define AT_MINSIGSTKSZ 51 +#endif + +static int nerrs; + +static bool sigalrm_expected; + +static unsigned long at_minstack_size; + +static void sethandler(int sig, void (*handler)(int, siginfo_t *, void *), + int flags) +{ + struct sigaction sa; + + memset(&sa, 0, sizeof(sa)); + sa.sa_sigaction = handler; + sa.sa_flags = SA_SIGINFO | flags; + sigemptyset(&sa.sa_mask); + if (sigaction(sig, &sa, 0)) + err(1, "sigaction"); +} + +static void clearhandler(int sig) +{ + struct sigaction sa; + + memset(&sa, 0, sizeof(sa)); + sa.sa_handler = SIG_DFL; + sigemptyset(&sa.sa_mask); + if (sigaction(sig, &sa, 0)) + err(1, "sigaction"); +} + +static int setup_altstack(void *start, unsigned long size) +{ + stack_t ss; + + memset(&ss, 0, sizeof(ss)); + ss.ss_size = size; + ss.ss_sp = start; + + return sigaltstack(&ss, NULL); +} + +static jmp_buf jmpbuf; + +static void sigsegv(int sig, siginfo_t *info, void *ctx_void) +{ + if (sigalrm_expected) { + printf("[FAIL]\tWrong signal delivered: SIGSEGV (expected SIGALRM)."); + nerrs++; + } else { + printf("[OK]\tSIGSEGV signal delivered.\n"); + } + + siglongjmp(jmpbuf, 1); +} + +static void sigalrm(int sig, siginfo_t *info, void *ctx_void) +{ + if (!sigalrm_expected) { + printf("[FAIL]\tWrong signal delivered: SIGALRM (expected SIGSEGV)."); + nerrs++; + } else { + printf("[OK]\tSIGALRM signal delivered.\n"); + } +} + +static void test_sigaltstack(void *altstack, unsigned long size) +{ + if (setup_altstack(altstack, size)) + err(1, "sigaltstack()"); + + sigalrm_expected = (size > at_minstack_size) ? true : false; + + sethandler(SIGSEGV, sigsegv, 0); + sethandler(SIGALRM, sigalrm, SA_ONSTACK); + + if (!sigsetjmp(jmpbuf, 1)) { + printf("[RUN]\tTest an alternate signal stack of %ssufficient size.\n", + sigalrm_expected ? "" : "in"); + printf("\tRaise SIGALRM. %s is expected to be delivered.\n", + sigalrm_expected ? "It" : "SIGSEGV"); + raise(SIGALRM); + } + + clearhandler(SIGALRM); + clearhandler(SIGSEGV); +} + +int main(void) +{ + void *altstack; + + at_minstack_size = getauxval(AT_MINSIGSTKSZ); + + altstack = mmap(NULL, at_minstack_size + SIGSTKSZ, PROT_READ | PROT_WRITE, + MAP_PRIVATE | MAP_ANONYMOUS | MAP_STACK, -1, 0); + if (altstack == MAP_FAILED) + err(1, "mmap()"); + + if ((ENFORCED_MINSIGSTKSZ + 1) < at_minstack_size) + test_sigaltstack(altstack, ENFORCED_MINSIGSTKSZ + 1); + + test_sigaltstack(altstack, at_minstack_size + SIGSTKSZ); + + return nerrs == 0 ? 0 : 1; +} -- 2.17.1

4 years, 6 months

1
0
0 0

[PATCH v6 4/6] selftest/sigaltstack: Use the AT_MINSIGSTKSZ aux vector if available

by Chang S. Bae

The SIGSTKSZ constant may not represent enough stack size in some architectures as the hardware state size grows. Use getauxval(AT_MINSIGSTKSZ) to increase the stack size. Signed-off-by: Chang S. Bae <chang.seok.bae(a)intel.com> Reviewed-by: Len Brown <len.brown(a)intel.com> Cc: linux-kselftest(a)vger.kernel.org Cc: linux-kernel(a)vger.kernel.org --- Changes from v5: * Added as a new patch. --- tools/testing/selftests/sigaltstack/sas.c | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/tools/testing/selftests/sigaltstack/sas.c b/tools/testing/selftests/sigaltstack/sas.c index 8934a3766d20..c53b070755b6 100644 --- a/tools/testing/selftests/sigaltstack/sas.c +++ b/tools/testing/selftests/sigaltstack/sas.c @@ -17,6 +17,7 @@ #include <string.h> #include <assert.h> #include <errno.h> +#include <sys/auxv.h> #include "../kselftest.h" @@ -24,6 +25,11 @@ #define SS_AUTODISARM (1U << 31) #endif +#ifndef AT_MINSIGSTKSZ +#define AT_MINSIGSTKSZ 51 +#endif + +static unsigned int stack_size; static void *sstack, *ustack; static ucontext_t uc, sc; static const char *msg = "[OK]\tStack preserved"; @@ -47,7 +53,7 @@ void my_usr1(int sig, siginfo_t *si, void *u) #endif if (sp < (unsigned long)sstack || - sp >= (unsigned long)sstack + SIGSTKSZ) { + sp >= (unsigned long)sstack + stack_size) { ksft_exit_fail_msg("SP is not on sigaltstack\n"); } /* put some data on stack. other sighandler will try to overwrite it */ @@ -108,6 +114,10 @@ int main(void) stack_t stk; int err; + /* Make sure more than the required minimum. */ + stack_size = getauxval(AT_MINSIGSTKSZ) + SIGSTKSZ; + ksft_print_msg("[NOTE]\tthe stack size is %lu\n", stack_size); + ksft_print_header(); ksft_set_plan(3); @@ -117,7 +127,7 @@ int main(void) sigaction(SIGUSR1, &act, NULL); act.sa_sigaction = my_usr2; sigaction(SIGUSR2, &act, NULL); - sstack = mmap(NULL, SIGSTKSZ, PROT_READ | PROT_WRITE, + sstack = mmap(NULL, stack_size, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_STACK, -1, 0); if (sstack == MAP_FAILED) { ksft_exit_fail_msg("mmap() - %s\n", strerror(errno)); @@ -139,7 +149,7 @@ int main(void) } stk.ss_sp = sstack; - stk.ss_size = SIGSTKSZ; + stk.ss_size = stack_size; stk.ss_flags = SS_ONSTACK | SS_AUTODISARM; err = sigaltstack(&stk, NULL); if (err) { @@ -161,7 +171,7 @@ int main(void) } } - ustack = mmap(NULL, SIGSTKSZ, PROT_READ | PROT_WRITE, + ustack = mmap(NULL, stack_size, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_STACK, -1, 0); if (ustack == MAP_FAILED) { ksft_exit_fail_msg("mmap() - %s\n", strerror(errno)); @@ -170,7 +180,7 @@ int main(void) getcontext(&uc); uc.uc_link = NULL; uc.uc_stack.ss_sp = ustack; - uc.uc_stack.ss_size = SIGSTKSZ; + uc.uc_stack.ss_size = stack_size; makecontext(&uc, switch_fn, 0); raise(SIGUSR1); -- 2.17.1

4 years, 6 months

1
0
0 0

[PATCH] kunit: tool: Fix a python tuple typing error

by David Gow

The first argument to namedtuple() should match the name of the type, which wasn't the case for KconfigEntryBase. Fixing this is enough to make mypy show no python typing errors again. Fixes 97752c39bd ("kunit: kunit_tool: Allow .kunitconfig to disable config items") Signed-off-by: David Gow <davidgow(a)google.com> --- tools/testing/kunit/kunit_config.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/kunit/kunit_config.py b/tools/testing/kunit/kunit_config.py index 0b550cbd667d..1e2683dcc0e7 100644 --- a/tools/testing/kunit/kunit_config.py +++ b/tools/testing/kunit/kunit_config.py @@ -13,7 +13,7 @@ from typing import List, Set CONFIG_IS_NOT_SET_PATTERN = r'^# CONFIG_(\w+) is not set$' CONFIG_PATTERN = r'^CONFIG_(\w+)=(\S+|".*")$' -KconfigEntryBase = collections.namedtuple('KconfigEntry', ['name', 'value']) +KconfigEntryBase = collections.namedtuple('KconfigEntryBase', ['name', 'value']) class KconfigEntry(KconfigEntryBase): -- 2.30.0.617.g56c4b15f3c-goog

4 years, 6 months

3
2
0 0

[PATCH] kunit: tool: Disable PAGE_POISONING under --alltests

by David Gow

kunit_tool maintains a list of config options which are broken under UML, which we exclude from an otherwise 'make ARCH=um allyesconfig' build used to run all tests with the --alltests option. Something in UML allyesconfig is causing segfaults when page poisining is enabled (and is poisoning with a non-zero value). Previously, this didn't occur, as allyesconfig enabled the CONFIG_PAGE_POISONING_ZERO option, which worked around the problem by zeroing memory. This option has since been removed, and memory is now poisoned with 0xAA, which triggers segfaults in many different codepaths, preventing UML from booting. Note that we have to disable both CONFIG_PAGE_POISONING and CONFIG_DEBUG_PAGEALLOC, as the latter will 'select' the former on architectures (such as UML) which don't implement __kernel_map_pages(). Ideally, we'd fix this properly by tracking down the real root cause, but since this is breaking KUnit's --alltests feature, it's worth disabling there in the meantime so the kernel can boot to the point where tests can actually run. Fixes: f289041ed4 ("mm, page_poison: remove CONFIG_PAGE_POISONING_ZERO") Signed-off-by: David Gow <davidgow(a)google.com> --- As described above, 'make ARCH=um allyesconfig' is broken. KUnit has been maintaining a list of configs to force-disable for this in tools/testing/kunit/configs/broken_on_uml.config. The kernels we've built with this have broken since CONFIG_PAGE_POISONING_ZERO was removed, panic-ing on startup with: <0>[ 0.100000][ T11] Kernel panic - not syncing: Segfault with no mm <4>[ 0.100000][ T11] CPU: 0 PID: 11 Comm: kdevtmpfs Not tainted 5.11.0-rc7-00003-g63381dc6f5f1-dirty #4 <4>[ 0.100000][ T11] Stack: <4>[ 0.100000][ T11] 677d3d40 677d3f10 0000000e 600c0bc0 <4>[ 0.100000][ T11] 677d3d90 603c99be 677d3d90 62529b93 <4>[ 0.100000][ T11] 603c9ac0 677d3f10 62529b00 603c98a0 <4>[ 0.100000][ T11] Call Trace: <4>[ 0.100000][ T11] [<600c0bc0>] ? set_signals+0x0/0x60 <4>[ 0.100000][ T11] [<603c99be>] lookup_mnt+0x11e/0x220 <4>[ 0.100000][ T11] [<62529b93>] ? down_write+0x93/0x180 <4>[ 0.100000][ T11] [<603c9ac0>] ? lock_mount+0x0/0x160 <4>[ 0.100000][ T11] [<62529b00>] ? down_write+0x0/0x180 <4>[ 0.100000][ T11] [<603c98a0>] ? lookup_mnt+0x0/0x220 <4>[ 0.100000][ T11] [<603c8160>] ? namespace_unlock+0x0/0x1a0 <4>[ 0.100000][ T11] [<603c9b25>] lock_mount+0x65/0x160 <4>[ 0.100000][ T11] [<6012f360>] ? up_write+0x0/0x40 <4>[ 0.100000][ T11] [<603cbbd2>] do_new_mount_fc+0xd2/0x220 <4>[ 0.100000][ T11] [<603eb560>] ? vfs_parse_fs_string+0x0/0xa0 <4>[ 0.100000][ T11] [<603cbf04>] do_new_mount+0x1e4/0x260 <4>[ 0.100000][ T11] [<603ccae9>] path_mount+0x1c9/0x6e0 <4>[ 0.100000][ T11] [<603a9f4f>] ? getname_kernel+0xaf/0x1a0 <4>[ 0.100000][ T11] [<603ab280>] ? kern_path+0x0/0x60 <4>[ 0.100000][ T11] [<600238ee>] 0x600238ee <4>[ 0.100000][ T11] [<62523baa>] devtmpfsd+0x52/0xb8 <4>[ 0.100000][ T11] [<62523b58>] ? devtmpfsd+0x0/0xb8 <4>[ 0.100000][ T11] [<600fffd8>] kthread+0x1d8/0x200 <4>[ 0.100000][ T11] [<600a4ea6>] new_thread_handler+0x86/0xc0 Disabling PAGE_POISONING fixes this. The issue can't be repoduced with just PAGE_POISONING, there's clearly something (or several things) also enabled by allyesconfig which contribute. Ideally, we'd track these down and fix this at its root cause, but in the meantime it'd be nice to disable PAGE_POISONING so we can at least get the kernel to boot. One way would be to add a 'depends on !UML' or similar, but since PAGE_POISONING does seem to work in the non-allyesconfig case, adding it to our list of broken configs seemed the better choice. Thoughts? (Note that to reproduce this, you'll want to run ./tools/testing/kunit/kunit.py run --alltests --raw_output It also depends on a couple of other fixes which are not upstream yet: https://www.spinics.net/lists/linux-rtc/msg08294.html https://lore.kernel.org/linux-i3c/20210127040636.1535722-1-davidgow@google.… Cheers, -- David tools/testing/kunit/configs/broken_on_uml.config | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/testing/kunit/configs/broken_on_uml.config b/tools/testing/kunit/configs/broken_on_uml.config index a7f0603d33f6..690870043ac0 100644 --- a/tools/testing/kunit/configs/broken_on_uml.config +++ b/tools/testing/kunit/configs/broken_on_uml.config @@ -40,3 +40,5 @@ # CONFIG_RESET_BRCMSTB_RESCAL is not set # CONFIG_RESET_INTEL_GW is not set # CONFIG_ADI_AXI_ADC is not set +# CONFIG_DEBUG_PAGEALLOC is not set +# CONFIG_PAGE_POISONING is not set -- 2.30.0.478.g8a0d178c01-goog

4 years, 6 months

3
2
0 0

general protection fault in kvm_hv_irq_routing_update

by syzbot

Hello, syzbot found the following issue on: HEAD commit: a99163e9 Merge tag 'devicetree-for-5.12' of git://git.kern.. git tree: upstream console output: https://syzkaller.appspot.com/x/log.txt?x=12d72682d00000 kernel config: https://syzkaller.appspot.com/x/.config?x=7a875029a795d230 dashboard link: https://syzkaller.appspot.com/bug?extid=6987f3b2dbd9eda95f12 syz repro: https://syzkaller.appspot.com/x/repro.syz?x=12faef12d00000 C reproducer: https://syzkaller.appspot.com/x/repro.c?x=163342ccd00000 The issue was bisected to: commit 8f014550dfb114cc7f42a517d20d2cf887a0b771 Author: Vitaly Kuznetsov <vkuznets(a)redhat.com> Date: Tue Jan 26 13:48:14 2021 +0000 KVM: x86: hyper-v: Make Hyper-V emulation enablement conditional bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=10df16a8d00000 final oops: https://syzkaller.appspot.com/x/report.txt?x=12df16a8d00000 console output: https://syzkaller.appspot.com/x/log.txt?x=14df16a8d00000 IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+6987f3b2dbd9eda95f12(a)syzkaller.appspotmail.com Fixes: 8f014550dfb1 ("KVM: x86: hyper-v: Make Hyper-V emulation enablement conditional") L1TF CPU bug present and SMT on, data leak possible. See CVE-2018-3646 and https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html for details. general protection fault, probably for non-canonical address 0xdffffc0000000028: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000140-0x0000000000000147] CPU: 1 PID: 8370 Comm: syz-executor859 Not tainted 5.11.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:synic_get arch/x86/kvm/hyperv.c:165 [inline] RIP: 0010:kvm_hv_set_sint_gsi arch/x86/kvm/hyperv.c:475 [inline] RIP: 0010:kvm_hv_irq_routing_update+0x230/0x460 arch/x86/kvm/hyperv.c:498 Code: 80 19 00 00 48 89 f8 48 c1 e8 03 80 3c 28 00 0f 85 ff 01 00 00 4d 8b ad 80 19 00 00 49 8d bd 40 01 00 00 48 89 f8 48 c1 e8 03 <0f> b6 04 28 84 c0 74 06 0f 8e d2 01 00 00 45 0f b6 bd 40 01 00 00 RSP: 0018:ffffc90001b3fac0 EFLAGS: 00010206 RAX: 0000000000000028 RBX: ffff888012df5900 RCX: 0000000000000000 RDX: ffff888022193780 RSI: ffffffff81174d43 RDI: 0000000000000140 RBP: dffffc0000000000 R08: 0000000000000000 R09: ffffc900018819eb R10: ffffffff81170f3e R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000001 FS: 0000000000a73300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000557e8c876888 CR3: 0000000013c0b000 CR4: 00000000001526e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: kvm_set_irq_routing+0x69b/0x940 arch/x86/kvm/../../../virt/kvm/irqchip.c:223 kvm_vm_ioctl+0x12d0/0x2800 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3959 vfs_ioctl fs/ioctl.c:48 [inline] __do_sys_ioctl fs/ioctl.c:753 [inline] __se_sys_ioctl fs/ioctl.c:739 [inline] __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:739 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x43ef29 Code: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffe391eb808 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 0000000000400488 RCX: 000000000043ef29 RDX: 0000000020000140 RSI: 000000004008ae6a RDI: 0000000000000004 RBP: 0000000000402f10 R08: 0000000000400488 R09: 0000000000400488 R10: 0000000000400488 R11: 0000000000000246 R12: 0000000000402fa0 R13: 0000000000000000 R14: 00000000004ac018 R15: 0000000000400488 Modules linked in: ---[ end trace 2aa75ec1dd148710 ]--- RIP: 0010:synic_get arch/x86/kvm/hyperv.c:165 [inline] RIP: 0010:kvm_hv_set_sint_gsi arch/x86/kvm/hyperv.c:475 [inline] RIP: 0010:kvm_hv_irq_routing_update+0x230/0x460 arch/x86/kvm/hyperv.c:498 Code: 80 19 00 00 48 89 f8 48 c1 e8 03 80 3c 28 00 0f 85 ff 01 00 00 4d 8b ad 80 19 00 00 49 8d bd 40 01 00 00 48 89 f8 48 c1 e8 03 <0f> b6 04 28 84 c0 74 06 0f 8e d2 01 00 00 45 0f b6 bd 40 01 00 00 RSP: 0018:ffffc90001b3fac0 EFLAGS: 00010206 RAX: 0000000000000028 RBX: ffff888012df5900 RCX: 0000000000000000 RDX: ffff888022193780 RSI: ffffffff81174d43 RDI: 0000000000000140 RBP: dffffc0000000000 R08: 0000000000000000 R09: ffffc900018819eb R10: ffffffff81170f3e R11: 0000000000000000 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000001 FS: 0000000000a73300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000557e8c876888 CR3: 0000000013c0b000 CR4: 00000000001526e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkaller(a)googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot. For information about bisection process see: https://goo.gl/tpsmEJ#bisection syzbot can test patches for this issue, for details see: https://goo.gl/tpsmEJ#testing-patches

4 years, 6 months

2
1
0 0

[RFC PATCH v2 0/7] Some improvement and a new test for kvm page table

by Yanan Wang

Hi, This v2 series can mainly include two parts. Based on kvm queue branch: https://git.kernel.org/pub/scm/virt/kvm/kvm.git/log/?h=queue Links of v1: https://lore.kernel.org/lkml/20210208090841.333724-1-wangyanan55@huawei.com/ In the first part, all the known hugetlb backing src types specified with different hugepage sizes are listed, so that we can specify use of hugetlb source of the exact granularity that we want, instead of the system default ones. And as all the known hugetlb page sizes are listed, it's appropriate for all architectures. Besides, a helper that can get granularity of different backing src types(anonumous/thp/hugetlb) is added, so that we can use the accurate backing src granularity for kinds of alignment or guest memory accessing of vcpus. In the second part, a new test is added: This test is added to serve as a performance tester and a bug reproducer for kvm page table code (GPA->HPA mappings), it gives guidance for the people trying to make some improvement for kvm. And the following explains what we can exactly do through this test. The function guest_code() can cover the conditions where a single vcpu or multiple vcpus access guest pages within the same memory region, in three VM stages(before dirty logging, during dirty logging, after dirty logging). Besides, the backing src memory type(ANONYMOUS/THP/HUGETLB) of the tested memory region can be specified by users, which means normal page mappings or block mappings can be chosen by users to be created in the test. If ANONYMOUS memory is specified, kvm will create normal page mappings for the tested memory region before dirty logging, and update attributes of the page mappings from RO to RW during dirty logging. If THP/HUGETLB memory is specified, kvm will create block mappings for the tested memory region before dirty logging, and split the blcok mappings into normal page mappings during dirty logging, and coalesce the page mappings back into block mappings after dirty logging is stopped. So in summary, as a performance tester, this test can present the performance of kvm creating/updating normal page mappings, or the performance of kvm creating/splitting/recovering block mappings, through execution time. When we need to coalesce the page mappings back to block mappings after dirty logging is stopped, we have to firstly invalidate *all* the TLB entries for the page mappings right before installation of the block entry, because a TLB conflict abort error could occur if we can't invalidate the TLB entries fully. We have hit this TLB conflict twice on aarch64 software implementation and fixed it. As this test can imulate process from dirty logging enabled to dirty logging stopped of a VM with block mappings, so it can also reproduce this TLB conflict abort due to inadequate TLB invalidation when coalescing tables. Links about the TLB conflict abort: https://lore.kernel.org/lkml/20201201201034.116760-3-wangyanan55@huawei.com/ Yanan Wang (7): tools include: sync head files of mmap flag encodings about hugetlb KVM: selftests: Use flag CLOCK_MONOTONIC_RAW for timing KVM: selftests: Make a generic helper to get vm guest mode strings KVM: selftests: Add a helper to get system configured THP page size KVM: selftests: List all hugetlb src types specified with page sizes KVM: selftests: Adapt vm_userspace_mem_region_add to new helpers KVM: selftests: Add a test for kvm page table code tools/include/asm-generic/hugetlb_encode.h | 3 + tools/testing/selftests/kvm/Makefile | 3 + .../selftests/kvm/demand_paging_test.c | 8 +- .../selftests/kvm/dirty_log_perf_test.c | 14 +- .../testing/selftests/kvm/include/kvm_util.h | 4 +- .../testing/selftests/kvm/include/test_util.h | 21 +- .../selftests/kvm/kvm_page_table_test.c | 476 ++++++++++++++++++ tools/testing/selftests/kvm/lib/kvm_util.c | 58 +-- tools/testing/selftests/kvm/lib/test_util.c | 92 +++- tools/testing/selftests/kvm/steal_time.c | 4 +- 10 files changed, 623 insertions(+), 60 deletions(-) create mode 100644 tools/testing/selftests/kvm/kvm_page_table_test.c -- 2.19.1

4 years, 6 months

4
17
0 0

[PATCH 0/5] userfaultfd: support minor fault handling for shmem

by Axel Rasmussen

Base ==== This series is based on top of my series which adds minor fault handling for hugetlbfs [1]. (And, therefore, it is based on linux-next/akpm and Peter Xu's series for disabling huge pmd sharing as well.) [1] https://lore.kernel.org/patchwork/cover/1384095/ Overview ======== See my original series linked above for a detailed overview of minor fault handling in general. The feature in this series works exactly like the hugetblfs version (from userspace's perspective). I'm sending this as a separate series because: - The original minor fault handling series has been through several rounds of review and seems close to being merged, so it seems reasonable to start looking at this next step. - shmem is different enough that this series may require some additional work before it's ready, and I don't want to delay the original series unnecessarily by bundling them together. Use Case ======== In some cases it is useful to have VM memory backed by tmpfs instead of hugetlbfs. So, this feature will be used to support the same VM live migration use case described in my original series. Additionally, Android folks (Lokesh Gidra <lokeshgidra(a)google.com>) hope to optimize the Android JVM garbage collector using this feature (a paper describing a somewhat similar approach: https://arxiv.org/pdf/1902.04738.pdf). Axel Rasmussen (5): userfaultfd: support minor fault handling for shmem userfaultfd/selftests: use memfd_create for shmem test type userfaultfd/selftests: create alias mappings in the shmem test userfaultfd/selftests: reinitialize test context in each test userfaultfd/selftests: exercise minor fault handling shmem support fs/userfaultfd.c | 6 +- include/linux/shmem_fs.h | 26 +- include/uapi/linux/userfaultfd.h | 4 +- mm/memory.c | 8 +- mm/shmem.c | 88 +++---- mm/userfaultfd.c | 27 +- tools/testing/selftests/vm/userfaultfd.c | 322 +++++++++++++++-------- 7 files changed, 293 insertions(+), 188 deletions(-) -- 2.30.0.617.g56c4b15f3c-goog

4 years, 6 months

1
6
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror