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

[PATCH -next 0/5] landlock: add chmod and chown support

by Xiu Jianfeng

hi, this patchset adds chmod and chown support for landlock Xiu Jianfeng (5): landlock: expand access_mask_t to u32 type landlock: add chmod and chown support landlock/selftests: add selftests for chmod and chown landlock/samples: add chmod and chown support landlock: update chmod and chown support in document Documentation/userspace-api/landlock.rst | 8 +- include/uapi/linux/landlock.h | 8 +- samples/landlock/sandboxer.c | 12 +- security/landlock/fs.c | 16 +- security/landlock/limits.h | 2 +- security/landlock/ruleset.h | 2 +- security/landlock/syscalls.c | 2 +- tools/testing/selftests/landlock/base_test.c | 2 +- tools/testing/selftests/landlock/fs_test.c | 234 ++++++++++++++++++- 9 files changed, 274 insertions(+), 12 deletions(-) -- 2.17.1

3 years, 2 months

5
26
0 0

[PATCH] selftests/bpf: declare subprog_noise as static in tailcall_bpf2bpf4

by James Hilliard

Due to bpf_map_lookup_elem being declared static we need to also declare subprog_noise as static. Fixes the following error: progs/tailcall_bpf2bpf4.c:26:9: error: 'bpf_map_lookup_elem' is static but used in inline function 'subprog_noise' which is not static [-Werror] 26 | bpf_map_lookup_elem(&nop_table, &key); | ^~~~~~~~~~~~~~~~~~~ Signed-off-by: James Hilliard <james.hilliard1(a)gmail.com> --- tools/testing/selftests/bpf/progs/tailcall_bpf2bpf4.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/bpf/progs/tailcall_bpf2bpf4.c b/tools/testing/selftests/bpf/progs/tailcall_bpf2bpf4.c index b67e8022d500..a017d6b2f1dd 100644 --- a/tools/testing/selftests/bpf/progs/tailcall_bpf2bpf4.c +++ b/tools/testing/selftests/bpf/progs/tailcall_bpf2bpf4.c @@ -19,7 +19,7 @@ struct { int count = 0; int noise = 0; -__always_inline int subprog_noise(void) +static __always_inline int subprog_noise(void) { __u32 key = 0; -- 2.34.1

3 years, 2 months

3
2
0 0

Re: linux-next: Tree for Aug 25 (kunit: virt/nitro_enclaves; also kexec)

by Randy Dunlap

On 8/24/22 22:44, Stephen Rothwell wrote: > Hi all, > > Changes since 20220824: > on x86_64: ld: vmlinux.o: in function `kunit_kcalloc': include/kunit/test.h:369: undefined reference to `kunit_kmalloc_array' ld: vmlinux.o: in function `ne_misc_dev_test_merge_phys_contig_memory_regions': drivers/virt/nitro_enclaves/ne_misc_dev_test.c:120: undefined reference to `kunit_do_failed_assertion' ld: drivers/virt/nitro_enclaves/ne_misc_dev_test.c:128: undefined reference to `kunit_binary_assert_format' ld: drivers/virt/nitro_enclaves/ne_misc_dev_test.c:128: undefined reference to `kunit_do_failed_assertion' ld: drivers/virt/nitro_enclaves/ne_misc_dev_test.c:129: undefined reference to `kunit_binary_assert_format' ld: drivers/virt/nitro_enclaves/ne_misc_dev_test.c:129: undefined reference to `kunit_do_failed_assertion' ld: drivers/virt/nitro_enclaves/ne_misc_dev_test.c:135: undefined reference to `kunit_binary_assert_format' ld: drivers/virt/nitro_enclaves/ne_misc_dev_test.c:135: undefined reference to `kunit_do_failed_assertion' ld: drivers/virt/nitro_enclaves/ne_misc_dev_test.c:137: undefined reference to `kunit_binary_assert_format' ld: drivers/virt/nitro_enclaves/ne_misc_dev_test.c:137: undefined reference to `kunit_do_failed_assertion' ld: drivers/virt/nitro_enclaves/ne_misc_dev_test.c:141: undefined reference to `kunit_kfree' ld: vmlinux.o: in function `kexec_purgatory_size': (.rodata+0x209ee0): undefined reference to `kunit_unary_assert_format' Full randconfig file is attached. -- ~Randy

3 years, 2 months

2
1
0 0

[PATCH] selftests/bpf: fix type conflict in test_tc_dtime

by James Hilliard

The sys/socket.h header isn't required to build test_tc_dtime and may cause a type conflict. Fixes the following error: In file included from /usr/include/x86_64-linux-gnu/sys/types.h:155, from /usr/include/x86_64-linux-gnu/bits/socket.h:29, from /usr/include/x86_64-linux-gnu/sys/socket.h:33, from progs/test_tc_dtime.c:18: /usr/include/x86_64-linux-gnu/bits/stdint-intn.h:24:18: error: conflicting types for 'int8_t'; have '__int8_t' {aka 'signed char'} 24 | typedef __int8_t int8_t; | ^~~~~~ In file included from progs/test_tc_dtime.c:5: /home/buildroot/opt/cross/lib/gcc/bpf/13.0.0/include/stdint.h:34:23: note: previous declaration of 'int8_t' with type 'int8_t' {aka 'char'} 34 | typedef __INT8_TYPE__ int8_t; | ^~~~~~ /usr/include/x86_64-linux-gnu/bits/stdint-intn.h:27:19: error: conflicting types for 'int64_t'; have '__int64_t' {aka 'long long int'} 27 | typedef __int64_t int64_t; | ^~~~~~~ /home/buildroot/opt/cross/lib/gcc/bpf/13.0.0/include/stdint.h:43:24: note: previous declaration of 'int64_t' with type 'int64_t' {aka 'long int'} 43 | typedef __INT64_TYPE__ int64_t; | ^~~~~~~ make: *** [Makefile:537: /home/buildroot/bpf-next/tools/testing/selftests/bpf/bpf_gcc/test_tc_dtime.o] Error 1 Signed-off-by: James Hilliard <james.hilliard1(a)gmail.com> --- tools/testing/selftests/bpf/progs/test_tc_dtime.c | 1 - 1 file changed, 1 deletion(-) diff --git a/tools/testing/selftests/bpf/progs/test_tc_dtime.c b/tools/testing/selftests/bpf/progs/test_tc_dtime.c index b596479a9ebe..125beec31834 100644 --- a/tools/testing/selftests/bpf/progs/test_tc_dtime.c +++ b/tools/testing/selftests/bpf/progs/test_tc_dtime.c @@ -15,7 +15,6 @@ #include <linux/udp.h> #include <bpf/bpf_helpers.h> #include <bpf/bpf_endian.h> -#include <sys/socket.h> /* veth_src --- veth_src_fwd --- veth_det_fwd --- veth_dst * | | -- 2.34.1

3 years, 2 months

3
2
0 0

[PATCH v2 0/8] Documentation: Kunit: clean kunit-tool.rst and start.rst

by Tales Aparecida

Hi, Continuing the documentation refactoring started by Harinder Singh[1], removes kunit-tool.rst, which had its information rearranged into run_wrapper, and employs further work in the index and the getting-started guide. This series was written on top of another[2] that haven't got applied yet, but the only dependency it has is the "kunit-on-qemu" anchor used in start.rst. Changelog: v1 -> v2: - Update expected output for `kunit.py run` from "Generating .config ..." to "Configuring KUnit Kernel ..." - Update run_wrapper titles as suggested by Sadiya Kazi - Remove confusing recommendation from start.rst intro, highlighted by Tim Bird - Fix grammars nits pointed by Maíra Canal and Sadiya Kazi - Add some reviewed-by Thanks again for your feedbacks, Tales [1] https://lore.kernel.org/r/20211217044911.798817-1-sharinder@google.com/ [2] https://lore.kernel.org/r/20220813042055.136832-1-tales.aparecida@gmail.com/ Tales Aparecida (8): Documentation: KUnit: remove duplicated docs for kunit_tool Documentation: KUnit: avoid repeating "kunit.py run" in start.rst Documentation: KUnit: add note about mrproper in start.rst Documentation: KUnit: Reword start guide for selecting tests Documentation: KUnit: add intro to the getting-started page Documentation: KUnit: update links in the index page lib: overflow: update reference to kunit-tool lib: stackinit: update reference to kunit-tool Documentation/dev-tools/kunit/index.rst | 16 +- Documentation/dev-tools/kunit/kunit-tool.rst | 232 ------------------ Documentation/dev-tools/kunit/run_wrapper.rst | 34 +-- Documentation/dev-tools/kunit/start.rst | 136 ++++++---- lib/overflow_kunit.c | 2 +- lib/stackinit_kunit.c | 2 +- 6 files changed, 117 insertions(+), 305 deletions(-) delete mode 100644 Documentation/dev-tools/kunit/kunit-tool.rst base-commit: 568035b01cfb107af8d2e4bd2fb9aea22cf5b868 prerequisite-patch-id: b794218cd939a6644aaf5fb2a73997c56a624c80 prerequisite-patch-id: ccd24491ae99152ebdc6dcb8ddb9499d3456a4a0 prerequisite-patch-id: cc17b80d42fd5f5049e144da5c04e922036a33eb prerequisite-patch-id: ba7edd270c6f285352e0e17bfe65ff6119192113 -- 2.37.2

3 years, 2 months

4
20
0 0

[PATCH 0/8] Documentation: Kunit: clean kunit-tool.rst and start.rst

by Tales Aparecida

Hi, Continuing the documentation refactoring started by Harinder Singh[1], removes kunit-tool.rst, which had its information rearranged into run_wrapper, and employs further work in the index and the getting-started guide. This series was written on top of another[2] that haven't got applied yet, but the only dependency it has is the "kunit-on-qemu" anchor used in start.rst. The patches working with the start.rst might be squashable, feel free to suggest so, if you concur. Still about this file, I realize the note about "mrproper" was removed in the recent refactoring, but having worked in the last months with people new to kunit, it showed itself as a common occurrence, so I'm suggesting here to restore it. Regarding the last two patches, I wasn't sure about either renaming run_wrapper to kunit-tool to keep old references working or do as I did, updating the references I could find. Thanks in advance for your feedbacks, Tales [1] https://lore.kernel.org/r/20211217044911.798817-1-sharinder@google.com/ [2] https://lore.kernel.org/r/20220813042055.136832-1-tales.aparecida@gmail.com/ Tales Aparecida (8): Documentation: KUnit: remove duplicated docs for kunit_tool Documentation: KUnit: avoid repeating "kunit.py run" in start.rst Documentation: KUnit: restore note about mrproper in start.rst Documentation: KUnit: Reword start guide for selecting tests Documentation: KUnit: add intro to the getting-started page Documentation: KUnit: update links in the index page lib: overflow: update reference to kunit-tool lib: stackinit: update reference to kunit-tool Documentation/dev-tools/kunit/index.rst | 16 +- Documentation/dev-tools/kunit/kunit-tool.rst | 232 ------------------ Documentation/dev-tools/kunit/run_wrapper.rst | 4 +- Documentation/dev-tools/kunit/start.rst | 137 +++++++---- lib/overflow_kunit.c | 2 +- lib/stackinit_kunit.c | 2 +- 6 files changed, 103 insertions(+), 290 deletions(-) delete mode 100644 Documentation/dev-tools/kunit/kunit-tool.rst base-commit: 568035b01cfb107af8d2e4bd2fb9aea22cf5b868 prerequisite-patch-id: b794218cd939a6644aaf5fb2a73997c56a624c80 prerequisite-patch-id: ccd24491ae99152ebdc6dcb8ddb9499d3456a4a0 prerequisite-patch-id: cc17b80d42fd5f5049e144da5c04e922036a33eb prerequisite-patch-id: ba7edd270c6f285352e0e17bfe65ff6119192113 -- 2.37.1

3 years, 2 months

8
22
0 0

[PATCH] Documentation: KUnit: Reword kunit_tool guide

by Sadiya Kazi

Updated the kunit_tool.rst guide to streamline it. The following changes were made: 1. Updated headings 2. Reworded content across sections 3. Added a cross reference to full list of command-line args Signed-off-by: Sadiya Kazi <sadiyakazi(a)google.com> --- Documentation/dev-tools/kunit/kunit-tool.rst | 82 ++++++++++---------- 1 file changed, 42 insertions(+), 40 deletions(-) diff --git a/Documentation/dev-tools/kunit/kunit-tool.rst b/Documentation/dev-tools/kunit/kunit-tool.rst index ae52e0f489f9..33186679f5de 100644 --- a/Documentation/dev-tools/kunit/kunit-tool.rst +++ b/Documentation/dev-tools/kunit/kunit-tool.rst @@ -1,8 +1,10 @@ .. SPDX-License-Identifier: GPL-2.0 -================= -kunit_tool How-To -================= +======================== +Understanding kunit_tool +======================== + +This page introduces the kunit_tool and covers the concepts and working of this tool. What is kunit_tool? =================== @@ -10,39 +12,37 @@ What is kunit_tool? kunit_tool is a script (``tools/testing/kunit/kunit.py``) that aids in building the Linux kernel as UML (`User Mode Linux <http://user-mode-linux.sourceforge.net/>`_), running KUnit tests, parsing -the test results and displaying them in a user friendly manner. +the test results and displaying them in a user-friendly manner. kunit_tool addresses the problem of being able to run tests without needing a virtual machine or actual hardware with User Mode Linux. User Mode Linux is a Linux architecture, like ARM or x86; however, unlike other architectures it -compiles the kernel as a standalone Linux executable that can be run like any +compiles the kernel as a standalone Linux executable. This executable can be run like any other program directly inside of a host operating system. To be clear, it does not require any virtualization support: it is just a regular program. -What is a .kunitconfig? -======================= +What is .kunitconfig? +===================== -It's just a defconfig that kunit_tool looks for in the build directory -(``.kunit`` by default). kunit_tool uses it to generate a .config as you might -expect. In addition, it verifies that the generated .config contains the CONFIG -options in the .kunitconfig; the reason it does this is so that it is easy to -be sure that a CONFIG that enables a test actually ends up in the .config. +.kunitconfig is a default configuration file (defconfig) that kunit_tool looks +for in the build directory (``.kunit``). The kunit_tool uses this file to +generate a .config. Additionally, it also verifies that the generated .config contains the CONFIG options in the .kunitconfig file. This is done to make sure that a CONFIG that enables a test is actually part of the .config file. -It's also possible to pass a separate .kunitconfig fragment to kunit_tool, +It is also possible to pass a separate .kunitconfig fragment to kunit_tool, which is useful if you have several different groups of tests you wish -to run independently, or if you want to use pre-defined test configs for +to run independently, or if you want to use pre-defined test configurations for certain subsystems. -Getting Started with kunit_tool +Getting started with kunit_tool =============================== -If a kunitconfig is present at the root directory, all you have to do is: +If a kunitconfig is present at the root directory, run the following command: .. code-block:: bash ./tools/testing/kunit/kunit.py run -However, you most likely want to use it with the following options: +However, most likely you may want to use it with the following options: .. code-block:: bash @@ -68,20 +68,20 @@ For a list of all the flags supported by kunit_tool, you can run: ./tools/testing/kunit/kunit.py run --help -Configuring, Building, and Running Tests +Configuring, building, and running tests ======================================== -It's also possible to run just parts of the KUnit build process independently, -which is useful if you want to make manual changes to part of the process. +It is also possible to run specific parts of the KUnit build process independently. +This is useful if you want to make manual changes to part of the process. -A .config can be generated from a .kunitconfig by using the ``config`` argument +If you want to generate a .config from a .kunitconfig, you can use the ``config`` argument when running kunit_tool: .. code-block:: bash ./tools/testing/kunit/kunit.py config -Similarly, if you just want to build a KUnit kernel from the current .config, +Similarly, if you want to build a KUnit kernel from the current .config, you can use the ``build`` argument: .. code-block:: bash @@ -95,33 +95,31 @@ run the kernel and display the test results with the ``exec`` argument: ./tools/testing/kunit/kunit.py exec -The ``run`` command which is discussed above is equivalent to running all three +The ``run`` command, discussed above is equivalent to running all three of these in sequence. All of these commands accept a number of optional command-line arguments. The ``--help`` flag will give a complete list of these, or keep reading this page for a guide to some of the more useful ones. -Parsing Test Results +Parsing test results ==================== -KUnit tests output their results in TAP (Test Anything Protocol) format. -kunit_tool will, when running tests, parse this output and print a summary -which is much more pleasant to read. If you wish to look at the raw test -results in TAP format, you can pass the ``--raw_output`` argument. +The output of the KUnit test results are displayed in TAP (Test Anything Protocol) format. +When running tests, the kunit_tool parses this output and prints a plaintext, human-readable summary. To view the raw test results in TAP format, you can use the ``--raw_output`` argument. .. code-block:: bash ./tools/testing/kunit/kunit.py run --raw_output The raw output from test runs may contain other, non-KUnit kernel log -lines. You can see just KUnit output with ``--raw_output=kunit``: +lines. To view only the KUnit output, you can use ``--raw_output=kunit``: .. code-block:: bash ./tools/testing/kunit/kunit.py run --raw_output=kunit -If you have KUnit results in their raw TAP format, you can parse them and print +If you have KUnit results in the raw TAP format, you can parse them and print the human-readable summary with the ``parse`` command for kunit_tool. This accepts a filename for an argument, or will read from standard input. @@ -135,11 +133,11 @@ accepts a filename for an argument, or will read from standard input. This is very useful if you wish to run tests in a configuration not supported by kunit_tool (such as on real hardware, or an unsupported architecture). -Filtering Tests +Filtering tests =============== -It's possible to run only a subset of the tests built into a kernel by passing -a filter to the ``exec`` or ``run`` commands. For example, if you only wanted +It is possible to run only a subset of the tests built into a kernel by passing +a filter to the ``exec`` or ``run`` commands. For example, if you want to run KUnit resource tests, you could use: .. code-block:: bash @@ -148,15 +146,14 @@ to run KUnit resource tests, you could use: This uses the standard glob format for wildcards. -Running Tests on QEMU +Running tests on QEMU ===================== -kunit_tool supports running tests on QEMU as well as via UML (as mentioned -elsewhere). The default way of running tests on QEMU requires two flags: +kunit_tool supports running tests on QEMU as well as via UML. The default way of running tests on QEMU requires two flags: ``--arch`` Selects a collection of configs (Kconfig as well as QEMU configs - options, etc) that allow KUnit tests to be run on the specified + options and so on) that allow KUnit tests to be run on the specified architecture in a minimal way; this is usually not much slower than using UML. The architecture argument is the same as the name of the option passed to the ``ARCH`` variable used by Kbuild. Not all @@ -196,8 +193,8 @@ look something like this: --jobs=12 \ --qemu_config=./tools/testing/kunit/qemu_configs/x86_64.py -Other Useful Options -==================== +Other useful options +====================== kunit_tool has a number of other command-line arguments which can be useful when adapting it to fit your environment or needs. @@ -228,5 +225,10 @@ Some of the more useful ones are: dependencies by adding ``CONFIG_KUNIT_ALL_TESTS=1`` to your .kunitconfig is preferable. -There are several other options (and new ones are often added), so do check +There are several other options (and new ones are often added), so do run ``--help`` if you're looking for something not mentioned here. +For more information on these options, see `Command-line-arguments +<https://www.kernel.org/doc/html/latest/dev-tools/kunit/run_wrapper.html#com…>`__ + + +. -- 2.37.1.595.g718a3a8f04-goog

3 years, 2 months

3
2
0 0

[PATCH v5 1/2] x86/fpu: Allow PKRU to be (once again) written by ptrace.

by Kyle Huey

From: Kyle Huey <me(a)kylehuey.com> When management of the PKRU register was moved away from XSTATE, emulation of PKRU's existence in XSTATE was added for APIs that read XSTATE, but not for APIs that write XSTATE. This can be seen by running gdb and executing `p $pkru`, `set $pkru = 42`, and `p $pkru`. On affected kernels (5.14+) the write to the PKRU register (which gdb performs through ptrace) is ignored. There are three relevant APIs: PTRACE_SETREGSET with NT_X86_XSTATE, sigreturn, and KVM_SET_XSAVE. KVM_SET_XSAVE has its own special handling to make PKRU writes take effect (in fpu_copy_uabi_to_guest_fpstate). Push that down into copy_uabi_to_xstate and have PTRACE_SETREGSET with NT_X86_XSTATE and sigreturn pass in pointers to the appropriate PKRU value. This also adds code to initialize the PKRU value to the hardware init value (namely 0) if the PKRU bit is not set in the XSTATE header to match XRSTOR. This is a change to the current KVM_SET_XSAVE behavior. Changelog since v4: - Selftest additionally checks PKRU readbacks through ptrace. - Selftest flips all PKRU bits (except the key used for PROT_EXEC). Changelog since v3: - The v3 patch is now part 1 of 2. - Adds a selftest in part 2 of 2. Changelog since v2: - Removed now unused variables in fpu_copy_uabi_to_guest_fpstate Changelog since v1: - Handles the error case of copy_to_buffer(). Signed-off-by: Kyle Huey <me(a)kylehuey.com> Cc: Dave Hansen <dave.hansen(a)linux.intel.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Borislav Petkov <bp(a)suse.de> Cc: kvm(a)vger.kernel.org # For edge case behavior of KVM_SET_XSAVE Cc: stable(a)vger.kernel.org # 5.14+ Fixes: e84ba47e313d ("x86/fpu: Hook up PKRU into ptrace()") --- arch/x86/kernel/fpu/core.c | 13 +------------ arch/x86/kernel/fpu/regset.c | 2 +- arch/x86/kernel/fpu/signal.c | 2 +- arch/x86/kernel/fpu/xstate.c | 28 +++++++++++++++++++++++----- arch/x86/kernel/fpu/xstate.h | 4 ++-- 5 files changed, 28 insertions(+), 21 deletions(-) diff --git a/arch/x86/kernel/fpu/core.c b/arch/x86/kernel/fpu/core.c index 3b28c5b25e12..46b935bc87c8 100644 --- a/arch/x86/kernel/fpu/core.c +++ b/arch/x86/kernel/fpu/core.c @@ -391,8 +391,6 @@ int fpu_copy_uabi_to_guest_fpstate(struct fpu_guest *gfpu, const void *buf, { struct fpstate *kstate = gfpu->fpstate; const union fpregs_state *ustate = buf; - struct pkru_state *xpkru; - int ret; if (!cpu_feature_enabled(X86_FEATURE_XSAVE)) { if (ustate->xsave.header.xfeatures & ~XFEATURE_MASK_FPSSE) @@ -406,16 +404,7 @@ int fpu_copy_uabi_to_guest_fpstate(struct fpu_guest *gfpu, const void *buf, if (ustate->xsave.header.xfeatures & ~xcr0) return -EINVAL; - ret = copy_uabi_from_kernel_to_xstate(kstate, ustate); - if (ret) - return ret; - - /* Retrieve PKRU if not in init state */ - if (kstate->regs.xsave.header.xfeatures & XFEATURE_MASK_PKRU) { - xpkru = get_xsave_addr(&kstate->regs.xsave, XFEATURE_PKRU); - *vpkru = xpkru->pkru; - } - return 0; + return copy_uabi_from_kernel_to_xstate(kstate, ustate, vpkru); } EXPORT_SYMBOL_GPL(fpu_copy_uabi_to_guest_fpstate); #endif /* CONFIG_KVM */ diff --git a/arch/x86/kernel/fpu/regset.c b/arch/x86/kernel/fpu/regset.c index 75ffaef8c299..6d056b68f4ed 100644 --- a/arch/x86/kernel/fpu/regset.c +++ b/arch/x86/kernel/fpu/regset.c @@ -167,7 +167,7 @@ int xstateregs_set(struct task_struct *target, const struct user_regset *regset, } fpu_force_restore(fpu); - ret = copy_uabi_from_kernel_to_xstate(fpu->fpstate, kbuf ?: tmpbuf); + ret = copy_uabi_from_kernel_to_xstate(fpu->fpstate, kbuf ?: tmpbuf, &target->thread.pkru); out: vfree(tmpbuf); diff --git a/arch/x86/kernel/fpu/signal.c b/arch/x86/kernel/fpu/signal.c index 91d4b6de58ab..558076dbde5b 100644 --- a/arch/x86/kernel/fpu/signal.c +++ b/arch/x86/kernel/fpu/signal.c @@ -396,7 +396,7 @@ static bool __fpu_restore_sig(void __user *buf, void __user *buf_fx, fpregs = &fpu->fpstate->regs; if (use_xsave() && !fx_only) { - if (copy_sigframe_from_user_to_xstate(fpu->fpstate, buf_fx)) + if (copy_sigframe_from_user_to_xstate(tsk, buf_fx)) return false; } else { if (__copy_from_user(&fpregs->fxsave, buf_fx, diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c index c8340156bfd2..e01d3514ae68 100644 --- a/arch/x86/kernel/fpu/xstate.c +++ b/arch/x86/kernel/fpu/xstate.c @@ -1197,7 +1197,7 @@ static int copy_from_buffer(void *dst, unsigned int offset, unsigned int size, static int copy_uabi_to_xstate(struct fpstate *fpstate, const void *kbuf, - const void __user *ubuf) + const void __user *ubuf, u32 *pkru) { struct xregs_state *xsave = &fpstate->regs.xsave; unsigned int offset, size; @@ -1235,6 +1235,24 @@ static int copy_uabi_to_xstate(struct fpstate *fpstate, const void *kbuf, for (i = 0; i < XFEATURE_MAX; i++) { mask = BIT_ULL(i); + if (i == XFEATURE_PKRU) { + /* + * Retrieve PKRU if not in init state, otherwise + * initialize it. + */ + if (hdr.xfeatures & mask) { + struct pkru_state xpkru = {0}; + + if (copy_from_buffer(&xpkru, xstate_offsets[i], + sizeof(xpkru), kbuf, ubuf)) + return -EFAULT; + + *pkru = xpkru.pkru; + } else { + *pkru = 0; + } + } + if (hdr.xfeatures & mask) { void *dst = __raw_xsave_addr(xsave, i); @@ -1264,9 +1282,9 @@ static int copy_uabi_to_xstate(struct fpstate *fpstate, const void *kbuf, * Convert from a ptrace standard-format kernel buffer to kernel XSAVE[S] * format and copy to the target thread. Used by ptrace and KVM. */ -int copy_uabi_from_kernel_to_xstate(struct fpstate *fpstate, const void *kbuf) +int copy_uabi_from_kernel_to_xstate(struct fpstate *fpstate, const void *kbuf, u32 *pkru) { - return copy_uabi_to_xstate(fpstate, kbuf, NULL); + return copy_uabi_to_xstate(fpstate, kbuf, NULL, pkru); } /* @@ -1274,10 +1292,10 @@ int copy_uabi_from_kernel_to_xstate(struct fpstate *fpstate, const void *kbuf) * XSAVE[S] format and copy to the target thread. This is called from the * sigreturn() and rt_sigreturn() system calls. */ -int copy_sigframe_from_user_to_xstate(struct fpstate *fpstate, +int copy_sigframe_from_user_to_xstate(struct task_struct *tsk, const void __user *ubuf) { - return copy_uabi_to_xstate(fpstate, NULL, ubuf); + return copy_uabi_to_xstate(tsk->thread.fpu.fpstate, NULL, ubuf, &tsk->thread.pkru); } static bool validate_independent_components(u64 mask) diff --git a/arch/x86/kernel/fpu/xstate.h b/arch/x86/kernel/fpu/xstate.h index 5ad47031383b..a4ecb04d8d64 100644 --- a/arch/x86/kernel/fpu/xstate.h +++ b/arch/x86/kernel/fpu/xstate.h @@ -46,8 +46,8 @@ extern void __copy_xstate_to_uabi_buf(struct membuf to, struct fpstate *fpstate, u32 pkru_val, enum xstate_copy_mode copy_mode); extern void copy_xstate_to_uabi_buf(struct membuf to, struct task_struct *tsk, enum xstate_copy_mode mode); -extern int copy_uabi_from_kernel_to_xstate(struct fpstate *fpstate, const void *kbuf); -extern int copy_sigframe_from_user_to_xstate(struct fpstate *fpstate, const void __user *ubuf); +extern int copy_uabi_from_kernel_to_xstate(struct fpstate *fpstate, const void *kbuf, u32 *pkru); +extern int copy_sigframe_from_user_to_xstate(struct task_struct *tsk, const void __user *ubuf); extern void fpu__init_cpu_xstate(void); -- 2.37.1

3 years, 2 months

3
6
0 0

[net-next] Fix reinitialization of TEST_PROGS in net self tests.

by Adel Abouchaev

Fix reinitialization of TEST_PROGS in net self tests. Signed-off-by: Adel Abouchaev <adel.abushaev(a)gmail.com> --- tools/testing/selftests/net/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/net/Makefile b/tools/testing/selftests/net/Makefile index 11a288b67e2f..4a5978eab848 100644 --- a/tools/testing/selftests/net/Makefile +++ b/tools/testing/selftests/net/Makefile @@ -42,7 +42,7 @@ TEST_PROGS += arp_ndisc_evict_nocarrier.sh TEST_PROGS += ndisc_unsolicited_na_test.sh TEST_PROGS += arp_ndisc_untracked_subnets.sh TEST_PROGS += stress_reuseport_listen.sh -TEST_PROGS := l2_tos_ttl_inherit.sh +TEST_PROGS += l2_tos_ttl_inherit.sh TEST_PROGS_EXTENDED := in_netns.sh setup_loopback.sh setup_veth.sh TEST_PROGS_EXTENDED += toeplitz_client.sh toeplitz.sh TEST_GEN_FILES = socket nettest -- 2.30.2

3 years, 2 months

3
2
0 0

Re: [PATCH v4 net-next 3/6] drivers: net: dsa: add locked fdb entry flag to drivers

by netdev＠kapio-technology.com

On 2022-08-11 13:28, Ido Schimmel wrote: >> > I'm talking about roaming, not forwarding. Let's say you have a locked >> > entry with MAC X pointing to port Y. Now you get a packet with SMAC X >> > from port Z which is unlocked. Will the FDB entry roam to port Z? I >> > think it should, but at least in current implementation it seems that >> > the "locked" flag will not be reset and having locked entries pointing >> > to an unlocked port looks like a bug. >> > >> In general I have been thinking that the said setup is a network configuration error as I was arguing in an earlier conversation with Vladimir. In this setup we must remember that SMAC X becomes DMAC X in the return traffic on the open port. But the question arises to me why MAC X would be behind the locked port without getting authed while being behind an open port too? In a real life setup, I don't think you would want random hosts behind a locked port in the MAB case, but only the hosts you will let through. Other hosts should be regarded as intruders. If we are talking about a station move, then the locked entry will age out and MAC X will function normally on the open port after the timeout, which was a case that was taken up in earlier discussions. But I will anyhow do some testing with this 'edge case' (of being behind both a locked and an unlocked port) if I may call it so, and see to that the offloaded and non-offloaded cases correspond to each other, and will work satisfactory. I think it will be good to have a flag to enable the mac-auth/MAB feature, and I suggest just calling the flag 'mab', as it is short. Otherwise I don't see any major issues with the whole feature as it is.

3 years, 2 months

2
21
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror