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

[PATCH v1 2/3] selftests/mm: allocate 6 hugepages in va_high_addr_switch.sh

by Chunyu Hu

The va_high_addr_switch test requires 6 hugepages, not 5. If running the test directly by: ./va_high_addr_switch.sh, the test will hit a mmap 'FAIL' caused by not enough hugepages: ``` mmap(addr_switch_hint - hugepagesize, 2*hugepagesize, MAP_HUGETLB): 0x7f330f800000 - OK mmap(addr_switch_hint , 2*hugepagesize, MAP_FIXED | MAP_HUGETLB): 0xffffffffffffffff - FAILED ``` The failure can't be hit if run the tests by running 'run_vmtests.sh -t hugevm' because the nr_hugepages is set to 128 at the beginning of run_vmtests.sh and va_high_addr_switch.sh skip the setup of nr_hugepages because already enough. CC: Luiz Capitulino <luizcap(a)redhat.com> Fixes: d9d957bd7b61 ("selftests/mm: alloc hugepages in va_high_addr_switch test") Signed-off-by: Chunyu Hu <chuhu(a)redhat.com> --- tools/testing/selftests/mm/va_high_addr_switch.sh | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/tools/testing/selftests/mm/va_high_addr_switch.sh b/tools/testing/selftests/mm/va_high_addr_switch.sh index f89fe078a8e6..98f3dfab62c5 100755 --- a/tools/testing/selftests/mm/va_high_addr_switch.sh +++ b/tools/testing/selftests/mm/va_high_addr_switch.sh @@ -111,8 +111,10 @@ setup_nr_hugepages() check_test_requirements save_nr_hugepages -# 4 keep_mapped pages, and one for tmp usage -setup_nr_hugepages 5 +# 5 keep_mapped hugepages are reserved in the first testings, and the last test +# requires two hugepages, with one verlaped with the last second test, so one +# extra, totally 6 hugepages +setup_nr_hugepages 6 ./va_high_addr_switch --run-hugetlb retcode=$? restore_nr_hugepages -- 2.49.0

1 hour, 16 minutes

1
1
0 0

[PATCH v1 1/3] selftests/mm: fix va_high_addr_switch.sh return value

by Chunyu Hu

Patch series "Fix va_high_addr_switch.sh test failure - again", v1. There are two issues exist for the va_high_addr_switch test. One issue is the test return value is ignored in va_high_addr_switch.sh. The second is the va_high_addr_switch requires 6 hugepages but it requires 5. Besides that, the nr_hugepages setup in run_vmtests.sh for arm64 can be done in va_high_addr_switch.sh too. This patch: (of 3) The return value should be return value of va_high_addr_switch, otherwise a test failure would be silently ignored. Fixes: d9d957bd7b61 ("selftests/mm: alloc hugepages in va_high_addr_switch test") CC: Luiz Capitulino <luizcap(a)redhat.com> Signed-off-by: Chunyu Hu <chuhu(a)redhat.com> --- tools/testing/selftests/mm/va_high_addr_switch.sh | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/testing/selftests/mm/va_high_addr_switch.sh b/tools/testing/selftests/mm/va_high_addr_switch.sh index a7d4b02b21dd..f89fe078a8e6 100755 --- a/tools/testing/selftests/mm/va_high_addr_switch.sh +++ b/tools/testing/selftests/mm/va_high_addr_switch.sh @@ -114,4 +114,6 @@ save_nr_hugepages # 4 keep_mapped pages, and one for tmp usage setup_nr_hugepages 5 ./va_high_addr_switch --run-hugetlb +retcode=$? restore_nr_hugepages +exit $retcode -- 2.49.0

1 hour, 16 minutes

1
0
0 0

[PATCH v8 00/13] Direct Map Removal Support for guest_memfd

by Kalyazin, Nikita

[ based on kvm/next ] Unmapping virtual machine guest memory from the host kernel's direct map is a successful mitigation against Spectre-style transient execution issues: if the kernel page tables do not contain entries pointing to guest memory, then any attempted speculative read through the direct map will necessarily be blocked by the MMU before any observable microarchitectural side-effects happen. This means that Spectre-gadgets and similar cannot be used to target virtual machine memory. Roughly 60% of speculative execution issues fall into this category [1, Table 1]. This patch series extends guest_memfd with the ability to remove its memory from the host kernel's direct map, to be able to attain the above protection for KVM guests running inside guest_memfd. Additionally, a Firecracker branch with support for these VMs can be found on GitHub [2]. For more details, please refer to the v5 cover letter. No substantial changes in design have taken place since. See also related write() syscall support in guest_memfd [3] where the interoperation between the two features is described. Changes since v7: - David: separate patches for adding x86 and ARM support - Dave/Will: drop support for disabling TLB flushes v7: https://lore.kernel.org/kvm/20250924151101.2225820-1-patrick.roy@campus.lmu… v6: https://lore.kernel.org/kvm/20250912091708.17502-1-roypat@amazon.co.uk v5: https://lore.kernel.org/kvm/20250828093902.2719-1-roypat@amazon.co.uk v4: https://lore.kernel.org/kvm/20250221160728.1584559-1-roypat@amazon.co.uk RFCv3: https://lore.kernel.org/kvm/20241030134912.515725-1-roypat@amazon.co.uk RFCv2: https://lore.kernel.org/kvm/20240910163038.1298452-1-roypat@amazon.co.uk RFCv1: https://lore.kernel.org/kvm/20240709132041.3625501-1-roypat@amazon.co.uk [1] https://download.vusec.net/papers/quarantine_raid23.pdf [2] https://github.com/firecracker-microvm/firecracker/tree/feature/secret-hidi… [3] https://lore.kernel.org/kvm/20251114151828.98165-1-kalyazin@amazon.com Patrick Roy (13): x86: export set_direct_map_valid_noflush to KVM module x86/tlb: export flush_tlb_kernel_range to KVM module mm: introduce AS_NO_DIRECT_MAP KVM: guest_memfd: Add stub for kvm_arch_gmem_invalidate KVM: guest_memfd: Add flag to remove from direct map KVM: x86: define kvm_arch_gmem_supports_no_direct_map() KVM: arm64: define kvm_arch_gmem_supports_no_direct_map() KVM: selftests: load elf via bounce buffer KVM: selftests: set KVM_MEM_GUEST_MEMFD in vm_mem_add() if guest_memfd != -1 KVM: selftests: Add guest_memfd based vm_mem_backing_src_types KVM: selftests: cover GUEST_MEMFD_FLAG_NO_DIRECT_MAP in existing selftests KVM: selftests: stuff vm_mem_backing_src_type into vm_shape KVM: selftests: Test guest execution from direct map removed gmem Documentation/virt/kvm/api.rst | 22 ++++--- arch/arm64/include/asm/kvm_host.h | 13 ++++ arch/x86/include/asm/kvm_host.h | 9 +++ arch/x86/include/asm/tlbflush.h | 3 +- arch/x86/mm/pat/set_memory.c | 1 + arch/x86/mm/tlb.c | 1 + include/linux/kvm_host.h | 14 ++++ include/linux/pagemap.h | 16 +++++ include/linux/secretmem.h | 18 ------ include/uapi/linux/kvm.h | 1 + lib/buildid.c | 4 +- mm/gup.c | 19 ++---- mm/mlock.c | 2 +- mm/secretmem.c | 8 +-- .../testing/selftests/kvm/guest_memfd_test.c | 17 ++++- .../testing/selftests/kvm/include/kvm_util.h | 37 ++++++++--- .../testing/selftests/kvm/include/test_util.h | 8 +++ tools/testing/selftests/kvm/lib/elf.c | 8 +-- tools/testing/selftests/kvm/lib/io.c | 23 +++++++ tools/testing/selftests/kvm/lib/kvm_util.c | 59 +++++++++-------- tools/testing/selftests/kvm/lib/test_util.c | 8 +++ tools/testing/selftests/kvm/lib/x86/sev.c | 1 + .../selftests/kvm/pre_fault_memory_test.c | 1 + .../selftests/kvm/set_memory_region_test.c | 52 +++++++++++++-- .../kvm/x86/private_mem_conversions_test.c | 7 +- virt/kvm/guest_memfd.c | 64 +++++++++++++++++-- 26 files changed, 314 insertions(+), 102 deletions(-) base-commit: e0c26d47def7382d7dbd9cad58bc653aed75737a -- 2.50.1

10 hours, 25 minutes

4
17
0 0

[PATCH] kunit: make FAULT_TEST default to n when PANIC_ON_OOPS

by Brendan Jackman

As describe in the help string, the user might want to disable these tests if they don't like to see stacktraces/BUG etc in their kernel log. However, if they enable PANIC_ON_OOPS, these tests also crash the machine, which it's safe to assume _almost_ nobody wants. One might argue that _absolutely_ nobody ever wants their kernel to crash so this should just be a hard dependency instead of a default. However, since this is rather special code that's anyway concerned with deliberately doing "bad" things, the normal rules don't seem to apply, hence prefer flexibility and allow users to set up a crashing Kconfig if they so choose. Signed-off-by: Brendan Jackman <jackmanb(a)google.com> --- lib/kunit/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/kunit/Kconfig b/lib/kunit/Kconfig index 50ecf55d2b9c8a82f2aff7a0b4156bd6179b0a2f..498cc51e493dc9a819e012b8082fb765f25512b9 100644 --- a/lib/kunit/Kconfig +++ b/lib/kunit/Kconfig @@ -28,7 +28,7 @@ config KUNIT_FAULT_TEST bool "Enable KUnit tests which print BUG stacktraces" depends on KUNIT_TEST depends on !UML - default y + default !PANIC_ON_OOPS help Enables fault handling tests for the KUnit framework. These tests may trigger a kernel BUG(), and the associated stack trace, even when they --- base-commit: 7bc16e72ddb993d706f698c2f6cee694e485f557 change-id: 20251207-kunit-fault-no-panic-e9bdce848031 Best regards, -- Brendan Jackman <jackmanb(a)google.com>

11 hours, 21 minutes

1
0
0 0

Supporting glibc v2.35 and older in kernel selftests

by Guenter Roeck

Hi, the kernel selftests do not currently support glibc v2.35 and older. This is primarily because glibc v2.36 added support for syscall API functions such as fsopen, move_mount, fsmount, open_tree, and fsconfig, and those API functions are now used in several tests. As result, glibc v2.35 and older are no longer supported, at least not for affected tests. Historically the selftest framework implemented such functions with wrappers named sys_<syscall>. This means that sys_<syscall> and <syscall> functions are now used in parallel. I see a number of possibilities to solve the problem. 1) Do nothing. Document somewhere that glibc v2.35 and older is not supported by the kernel selftests. 2) Document that glibc v2.35 and older is not supported, drop all wrappers implementing the sys_<syscall> functions, and rename the calling code to <syscall>. 3) Rename all calls to sys_<syscall> to <syscall> and modify the wrapper code to only implement those functions for glibc v2.35 and older. 4) Add defines to the existing wrapper code to also define <syscall> in addition to sys_<syscall>, and leave the code otherwise alone. What would be the preferred solution ? My personal preference would be 3), followed by 4). Thanks, Guenter

18 hours, 29 minutes

1
0
0 0

[PATCH bpf v5 0/2] bpf: fix bpf_d_path() helper prototype

by Shuran Liu

Hi, This series fixes a verifier issue with bpf_d_path() and adds a regression test to cover its use within a hook function. Patch 1 updates the bpf_d_path() helper prototype so that the second argument is marked as MEM_WRITE. This makes it explicit to the verifier that the helper writes into the provided buffer. Patch 2 extends the existing d_path selftest to cover incorrect verifier assumptions caused by an incorrect function prototype. The test program calls bpf_d_path() and checks if the first character of the path can be read. It ensures the verifier does not assume the buffer remains unwritten. Changelog ========= v5: - Moved the temporary file for the fallocate test from /tmp to /dev/shm Since bpf CI's 9P filesystem under /tmp does not support fallocate. v4: - Use the fallocate hook instead of an LSM hook to simplify the selftest, as suggested by Matt and Alexei. - Add a utility function in test_d_path.c to load the BPF program, improving code reuse. v3: - Switch the pathname prefix loop to use bpf_for() instead of #pragma unroll, as suggested by Matt. - Remove /tmp/bpf_d_path_test in the test cleanup path. - Add the missing Reviewed-by tags. v2: - Merge the new test into the existing d_path selftest rather than creating new files. - Add PID filtering in the LSM program to avoid nondeterministic failures due to unrelated processes triggering bprm_check_security. - Synchronize child execution using a pipe to ensure deterministic updates to the PID. Thanks for your time and reviews. Shuran Liu (2): bpf: mark bpf_d_path() buffer as writeable selftests/bpf: add regression test for bpf_d_path() kernel/trace/bpf_trace.c | 2 +- .../testing/selftests/bpf/prog_tests/d_path.c | 91 +++++++++++++++---- .../testing/selftests/bpf/progs/test_d_path.c | 23 +++++ 3 files changed, 97 insertions(+), 19 deletions(-) -- 2.52.0

23 hours, 26 minutes

1
2
0 0

[PATCH bpf v4 0/2] bpf: fix bpf_d_path() helper prototype

by Shuran Liu

Hi, This series fixes a verifier issue with bpf_d_path() and adds a regression test to cover its use within a hook function. Patch 1 updates the bpf_d_path() helper prototype so that the second argument is marked as MEM_WRITE. This makes it explicit to the verifier that the helper writes into the provided buffer. Patch 2 extends the existing d_path selftest to cover incorrect verifier assumptions caused by an incorrect function prototype. The test program calls bpf_d_path() and checks if the first character of the path is '/'. It ensures the verifier does not assume the buffer remains unwritten. Changelog ========= v4: - Use the fallocate hook instead of an LSM hook to simplify the selftest, as suggested by Matt and Alexei. - Add a utility function in test_d_path.c to load the BPF program, improving code reuse. v3: - Switch the pathname prefix loop to use bpf_for() instead of #pragma unroll, as suggested by Matt. - Remove /tmp/bpf_d_path_test in the test cleanup path. - Add the missing Reviewed-by tags. v2: - Merge the new test into the existing d_path selftest rather than creating new files. - Add PID filtering in the LSM program to avoid nondeterministic failures due to unrelated processes triggering bprm_check_security. - Synchronize child execution using a pipe to ensure deterministic updates to the PID. Thanks for your time and reviews. Shuran Liu (2): bpf: mark bpf_d_path() buffer as writeable selftests/bpf: add regression test for bpf_d_path() kernel/trace/bpf_trace.c | 2 +- .../testing/selftests/bpf/prog_tests/d_path.c | 90 +++++++++++++++---- .../testing/selftests/bpf/progs/test_d_path.c | 23 +++++ 3 files changed, 96 insertions(+), 19 deletions(-) -- 2.52.0

23 hours, 32 minutes

2
5
0 0

[PATCH net-next v2] selftests: tls: fix warning of uninitialized variable

by Ankit Khushwaha

In 'poll_partial_rec_async' a uninitialized char variable 'token' with is used for write/read instruction to synchronize between threads via a pipe. tls.c:2833:26: warning: variable 'token' is uninitialized when passed as a const pointer argument Initialize 'token' to '\0' to silence compiler warning. Signed-off-by: Ankit Khushwaha <ankitkhushwaha.linux(a)gmail.com> --- compiler used: clang version 21.1.5 (Fedora 21.1.5-1.fc43). changelog: v2: - update patch name and msg v1: https://lore.kernel.org/all/20251129063726.31210-1-ankitkhushwaha.linux@gma… --- tools/testing/selftests/net/tls.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/net/tls.c b/tools/testing/selftests/net/tls.c index a3ef4b57eb5f..a4d16a460fbe 100644 --- a/tools/testing/selftests/net/tls.c +++ b/tools/testing/selftests/net/tls.c @@ -2786,10 +2786,10 @@ TEST_F(tls_err, epoll_partial_rec) TEST_F(tls_err, poll_partial_rec_async) { struct pollfd pfd = { }; + char token = '\0'; ssize_t rec_len; char rec[256]; char buf[128]; - char token; int p[2]; int ret; -- 2.52.0

1 day, 3 hours

2
1
0 0

[PATCH bpf-next v2 0/5] Add cryptographic hash and signature verification kfuncs to BPF

by Daniel Hodges

This series extends BPF's cryptographic capabilities by adding kfuncs for SHA hashing and ECDSA signature verification. These functions enable BPF programs to perform cryptographic operations for use cases such as content verification, integrity checking, and data authentication. BPF programs increasingly need to verify data integrity and authenticity in networking, security, and observability contexts. While BPF already supports symmetric encryption/decryption, it lacks support for: 1. Cryptographic hashing - needed for content verification, fingerprinting, and preparing message digests for signature operations 2. Asymmetric signature verification - needed to verify signed data without requiring the signing key in the datapath These capabilities enable use cases such as: - Verifying signed network packets or application data in XDP/TC programs - Implementing integrity checks in tracing and security monitoring - Building zero-trust security models where BPF programs verify credentials - Content-addressed storage and deduplication in BPF-based filesystems Implementation: The implementation follows BPF's existing crypto patterns: 1. Uses bpf_dynptr for safe memory access without page fault risks 2. Leverages the kernel's existing crypto library (lib/crypto/sha256.c and crypto/ecdsa.c) rather than reimplementing algorithms 3. Provides context-based API for ECDSA to enable key reuse and support multiple program types (syscall, XDP, TC) 4. Includes comprehensive selftests with NIST test vectors Patch 1: crypto: Add BPF hash algorithm type registration module - Adds bpf_crypto_shash module in crypto/ subsystem - Registers hash type with BPF crypto infrastructure - Enables hash algorithm access through unified bpf_crypto_type interface - Implements callbacks: alloc_tfm, free_tfm, hash, digestsize, get_flags - Manages shash_desc lifecycle internally Patch 2: bpf: Add SHA hash kfunc for cryptographic hashing - Adds bpf_crypto_hash() kfunc for SHA-256/384/512 - Extends bpf_crypto_type structure with hash operations - Updates bpf_crypto_ctx_create() to support keyless operations - Protected by CONFIG_CRYPTO_HASH2 guards - Uses kernel's crypto library implementations Patch 3: selftests/bpf: Add tests for bpf_crypto_hash kfunc - Tests basic functionality with NIST "abc" test vectors - Validates error handling for invalid parameters (zero-length input) - Ensures correct hash output for SHA-256, SHA-384, and SHA-512 - Adds CONFIG_CRYPTO_HASH2 and CONFIG_CRYPTO_SHA512 to selftest config Patch 4: bpf: Add ECDSA signature verification kfuncs - Context-based API: bpf_ecdsa_ctx_create/acquire/release pattern - Supports NIST curves (P-256, P-384, P-521) - Adds bpf_ecdsa_verify() for signature verification - Includes size query functions: keysize, digestsize, maxsize - Enables use in non-sleepable contexts via pre-allocated contexts - Uses crypto_sig API with p1363 format (r || s signatures) Patch 5: selftests/bpf: Add tests for ECDSA signature verification - Tests valid signature acceptance with RFC 6979 test vectors for P-256 - Tests invalid signature rejection - Tests size query functions (keysize, digestsize, maxsize) - Uses well-known NIST test vectors with "sample" message v2: - Fixed redundant __bpf_dynptr_is_rdonly() checks (Vadim) - Added BPF hash algorithm type registration module in crypto/ subsystem - Added CONFIG_CRYPTO_HASH2 guards around bpf_crypto_hash() kfunc and its BTF registration, matching the pattern used for CONFIG_CRYPTO_ECDSA - Added mandatory digestsize validation for hash operations Test Results ============ All tests pass on x86_64 for both crypto_hash and ecdsa_verify test suites. Daniel Hodges (5): crypto: Add BPF hash algorithm type registration module bpf: Add SHA hash kfunc for cryptographic hashing selftests/bpf: Add tests for bpf_crypto_hash kfunc bpf: Add ECDSA signature verification kfuncs selftests/bpf: Add tests for ECDSA signature verification kfuncs crypto/Makefile | 3 + crypto/bpf_crypto_shash.c | 94 ++++++ include/linux/bpf_crypto.h | 2 + kernel/bpf/crypto.c | 306 ++++++++++++++++++++- tools/testing/selftests/bpf/config | 2 + .../testing/selftests/bpf/prog_tests/crypto_hash.c | 158 +++++++++++ .../selftests/bpf/prog_tests/ecdsa_verify.c | 74 +++++ tools/testing/selftests/bpf/progs/crypto_hash.c | 141 ++++++++++ tools/testing/selftests/bpf/progs/ecdsa_verify.c | 159 +++++++++++ 9 files changed, 931 insertions(+), 8 deletions(-) create mode 100644 crypto/bpf_crypto_shash.c create mode 100644 tools/testing/selftests/bpf/prog_tests/crypto_hash.c create mode 100644 tools/testing/selftests/bpf/prog_tests/ecdsa_verify.c create mode 100644 tools/testing/selftests/bpf/progs/crypto_hash.c create mode 100644 tools/testing/selftests/bpf/progs/ecdsa_verify.c -- 2.51.0

1 day, 12 hours

4
10
0 0

[PATCH] iommufd/selftest: Make it clearer to gcc that the access is not out of bounds

by Jason Gunthorpe

GCC gets a bit confused and reports: In function '_test_cmd_get_hw_info', inlined from 'iommufd_ioas_get_hw_info' at iommufd.c:779:3, inlined from 'wrapper_iommufd_ioas_get_hw_info' at iommufd.c:752:1: >> iommufd_utils.h:804:37: warning: array subscript 'struct iommu_test_hw_info[0]' is partly outside array bounds of 'struct iommu_test_hw_info_buffer_smaller[1]' [-Warray-bounds=] 804 | assert(!info->flags); | ~~~~^~~~~~~ iommufd.c: In function 'wrapper_iommufd_ioas_get_hw_info': iommufd.c:761:11: note: object 'buffer_smaller' of size 4 761 | } buffer_smaller; | ^~~~~~~~~~~~~~ While it is true that "struct iommu_test_hw_info[0]" is partly out of bounds of the input pointer, it is not true that info->flags is out of bounds. Unclear why it warns on this. Reuse an existing properly sized stack buffer and pass a truncated length instead to test the same thing. Fixes: af4fde93c319 ("iommufd/selftest: Add coverage for IOMMU_GET_HW_INFO ioctl") Reported-by: kernel test robot <lkp(a)intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202512032344.kaAcKFIM-lkp@intel.com/ Signed-off-by: Jason Gunthorpe <jgg(a)nvidia.com> --- tools/testing/selftests/iommu/iommufd.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/tools/testing/selftests/iommu/iommufd.c b/tools/testing/selftests/iommu/iommufd.c index 10e051b6f592df..dadad277f4eb2e 100644 --- a/tools/testing/selftests/iommu/iommufd.c +++ b/tools/testing/selftests/iommu/iommufd.c @@ -755,9 +755,6 @@ TEST_F(iommufd_ioas, get_hw_info) struct iommu_test_hw_info info; uint64_t trailing_bytes; } buffer_larger; - struct iommu_test_hw_info_buffer_smaller { - __u32 flags; - } buffer_smaller; if (self->device_id) { uint8_t max_pasid = 0; @@ -789,8 +786,9 @@ TEST_F(iommufd_ioas, get_hw_info) * the fields within the size range still gets updated. */ test_cmd_get_hw_info(self->device_id, - IOMMU_HW_INFO_TYPE_DEFAULT, - &buffer_smaller, sizeof(buffer_smaller)); + IOMMU_HW_INFO_TYPE_DEFAULT, &buffer_exact, + offsetofend(struct iommu_test_hw_info, + flags)); test_cmd_get_hw_info_pasid(self->device_id, &max_pasid); ASSERT_EQ(0, max_pasid); if (variant->pasid_capable) { base-commit: 93013488dd77dd2ea8bd23355a5587d9e6dac185 -- 2.43.0

1 day, 12 hours

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror