January 2024 - Linux-kselftest-mirror

kselftest/fixes kselftest-cpufreq: 5 runs, 1 regressions (v6.8-rc1)

by kernelci.org bot

kselftest/fixes kselftest-cpufreq: 5 runs, 1 regressions (v6.8-rc1) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions ----------------+-------+---------------+----------+------------------------------+------------ mt8173-elm-hana | arm64 | lab-collabora | gcc-10 | defconfig+kse...4-chromebook | 1 Details: https://kernelci.org/test/job/kselftest/branch/fixes/kernel/v6.8-rc1/plan/k… Test: kselftest-cpufreq Tree: kselftest Branch: fixes Describe: v6.8-rc1 URL: https://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git SHA: 6613476e225e090cc9aad49be7fa504e290dd33d Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions ----------------+-------+---------------+----------+------------------------------+------------ mt8173-elm-hana | arm64 | lab-collabora | gcc-10 | defconfig+kse...4-chromebook | 1 Details: https://kernelci.org/test/plan/id/65adc33f0fad8dd25952a402 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+kselftest+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//kselftest/fixes/v6.8-rc1/arm64/defconfig+ksel… HTML log: https://storage.kernelci.org//kselftest/fixes/v6.8-rc1/arm64/defconfig+ksel… Rootfs: http://storage.kernelci.org/images/rootfs/debian/bullseye-kselftest/2023062… * kselftest-cpufreq.login: https://kernelci.org/test/case/id/65adc33f0fad8dd25952a403 failing since 459 days (last pass: linux-kselftest-fixes-6.0-rc3, first fail: v6.1-rc1-5-gcb05c81ada76)

1 year, 9 months

1
0
0 0

kselftest/fixes kselftest-lib: 3 runs, 2 regressions (v6.8-rc1)

by kernelci.org bot

kselftest/fixes kselftest-lib: 3 runs, 2 regressions (v6.8-rc1) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions -----------------------------+-------+---------------+----------+------------------------------+------------ meson-g12b-a311d-khadas-vim3 | arm64 | lab-collabora | gcc-10 | defconfig+kselftest | 1 mt8173-elm-hana | arm64 | lab-collabora | gcc-10 | defconfig+kse...4-chromebook | 1 Details: https://kernelci.org/test/job/kselftest/branch/fixes/kernel/v6.8-rc1/plan/k… Test: kselftest-lib Tree: kselftest Branch: fixes Describe: v6.8-rc1 URL: https://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git SHA: 6613476e225e090cc9aad49be7fa504e290dd33d Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions -----------------------------+-------+---------------+----------+------------------------------+------------ meson-g12b-a311d-khadas-vim3 | arm64 | lab-collabora | gcc-10 | defconfig+kselftest | 1 Details: https://kernelci.org/test/plan/id/65adc3e5ea9e3e489952a47f Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+kselftest Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//kselftest/fixes/v6.8-rc1/arm64/defconfig+ksel… HTML log: https://storage.kernelci.org//kselftest/fixes/v6.8-rc1/arm64/defconfig+ksel… Rootfs: http://storage.kernelci.org/images/rootfs/debian/bullseye-kselftest/2023062… * kselftest-lib.login: https://kernelci.org/test/case/id/65adc3e5ea9e3e489952a480 failing since 461 days (last pass: linux-kselftest-fixes-6.0-rc3, first fail: v6.1-rc1) platform | arch | lab | compiler | defconfig | regressions -----------------------------+-------+---------------+----------+------------------------------+------------ mt8173-elm-hana | arm64 | lab-collabora | gcc-10 | defconfig+kse...4-chromebook | 1 Details: https://kernelci.org/test/plan/id/65adc3434058ab4b2552a3fd Results: 0 PASS, 1 FAIL, 0 SKIP Full config: defconfig+kselftest+arm64-chromebook Compiler: gcc-10 (aarch64-linux-gnu-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//kselftest/fixes/v6.8-rc1/arm64/defconfig+ksel… HTML log: https://storage.kernelci.org//kselftest/fixes/v6.8-rc1/arm64/defconfig+ksel… Rootfs: http://storage.kernelci.org/images/rootfs/debian/bullseye-kselftest/2023062… * kselftest-lib.login: https://kernelci.org/test/case/id/65adc3434058ab4b2552a3fe failing since 459 days (last pass: linux-kselftest-fixes-6.0-rc3, first fail: v6.1-rc1-5-gcb05c81ada76)

1 year, 9 months

1
0
0 0

kselftest/next kselftest-lkdtm: 1 runs, 1 regressions (v6.8-rc1)

by kernelci.org bot

kselftest/next kselftest-lkdtm: 1 runs, 1 regressions (v6.8-rc1) Regressions Summary ------------------- platform | arch | lab | compiler | defconfig | regressions ----------------+------+---------------+----------+------------------------------+------------ imx6q-sabrelite | arm | lab-collabora | gcc-10 | multi_v7_defconfig+kselftest | 1 Details: https://kernelci.org/test/job/kselftest/branch/next/kernel/v6.8-rc1/plan/ks… Test: kselftest-lkdtm Tree: kselftest Branch: next Describe: v6.8-rc1 URL: https://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git SHA: 6613476e225e090cc9aad49be7fa504e290dd33d Test Regressions ---------------- platform | arch | lab | compiler | defconfig | regressions ----------------+------+---------------+----------+------------------------------+------------ imx6q-sabrelite | arm | lab-collabora | gcc-10 | multi_v7_defconfig+kselftest | 1 Details: https://kernelci.org/test/plan/id/65adc25caf68668b1c52a432 Results: 0 PASS, 1 FAIL, 0 SKIP Full config: multi_v7_defconfig+kselftest Compiler: gcc-10 (arm-linux-gnueabihf-gcc (Debian 10.2.1-6) 10.2.1 20210110) Plain log: https://storage.kernelci.org//kselftest/next/v6.8-rc1/arm/multi_v7_defconfi… HTML log: https://storage.kernelci.org//kselftest/next/v6.8-rc1/arm/multi_v7_defconfi… Rootfs: http://storage.kernelci.org/images/rootfs/debian/bullseye-kselftest/2023062… * kselftest-lkdtm.login: https://kernelci.org/test/case/id/65adc25caf68668b1c52a433 failing since 417 days (last pass: v6.1-rc1-23-g00dd59519141, first fail: v6.1-rc1-23-g8008d88e6d16)

1 year, 9 months

1
0
0 0

kselftest/fixes build: 5 builds: 2 failed, 3 passed, 2 errors, 5 warnings (v6.8-rc1)

by kernelci.org bot

kselftest/fixes build: 5 builds: 2 failed, 3 passed, 2 errors, 5 warnings (v6.8-rc1) Full Build Summary: https://kernelci.org/build/kselftest/branch/fixes/kernel/v6.8-rc1/ Tree: kselftest Branch: fixes Git Describe: v6.8-rc1 Git Commit: 6613476e225e090cc9aad49be7fa504e290dd33d Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git Built: 4 unique architectures Build Failures Detected: i386: i386_defconfig+kselftest: (gcc-10) FAIL x86_64: x86_64_defconfig+kselftest: (gcc-10) FAIL Errors and Warnings Detected: arm64: defconfig+kselftest (gcc-10): 1 warning defconfig+kselftest+arm64-chromebook (gcc-10): 1 warning arm: multi_v7_defconfig+kselftest (gcc-10): 1 warning i386: i386_defconfig+kselftest (gcc-10): 1 error, 1 warning x86_64: x86_64_defconfig+kselftest (gcc-10): 1 error, 1 warning Errors summary: 2 include/linux/fortify-string.h:57:29: error: ‘__builtin_memcpy’ offset 32 is out of the bounds [0, 0] [-Werror=array-bounds] Warnings summary: 3 include/linux/fortify-string.h:57:29: warning: ‘__builtin_memcpy’ offset 32 is out of the bounds [0, 0] [-Warray-bounds] 2 cc1: all warnings being treated as errors ================================================================================ Detailed per-defconfig build reports: -------------------------------------------------------------------------------- defconfig+kselftest (arm64, gcc-10) — PASS, 0 errors, 1 warning, 0 section mismatches Warnings: include/linux/fortify-string.h:57:29: warning: ‘__builtin_memcpy’ offset 32 is out of the bounds [0, 0] [-Warray-bounds] -------------------------------------------------------------------------------- defconfig+kselftest+arm64-chromebook (arm64, gcc-10) — PASS, 0 errors, 1 warning, 0 section mismatches Warnings: include/linux/fortify-string.h:57:29: warning: ‘__builtin_memcpy’ offset 32 is out of the bounds [0, 0] [-Warray-bounds] -------------------------------------------------------------------------------- i386_defconfig+kselftest (i386, gcc-10) — FAIL, 1 error, 1 warning, 0 section mismatches Errors: include/linux/fortify-string.h:57:29: error: ‘__builtin_memcpy’ offset 32 is out of the bounds [0, 0] [-Werror=array-bounds] Warnings: cc1: all warnings being treated as errors -------------------------------------------------------------------------------- multi_v7_defconfig+kselftest (arm, gcc-10) — PASS, 0 errors, 1 warning, 0 section mismatches Warnings: include/linux/fortify-string.h:57:29: warning: ‘__builtin_memcpy’ offset 32 is out of the bounds [0, 0] [-Warray-bounds] -------------------------------------------------------------------------------- x86_64_defconfig+kselftest (x86_64, gcc-10) — FAIL, 1 error, 1 warning, 0 section mismatches Errors: include/linux/fortify-string.h:57:29: error: ‘__builtin_memcpy’ offset 32 is out of the bounds [0, 0] [-Werror=array-bounds] Warnings: cc1: all warnings being treated as errors --- For more info write to <info(a)kernelci.org>

1 year, 9 months

1
0
0 0

kselftest/next build: 5 builds: 2 failed, 3 passed, 2 errors, 5 warnings (v6.8-rc1)

by kernelci.org bot

kselftest/next build: 5 builds: 2 failed, 3 passed, 2 errors, 5 warnings (v6.8-rc1) Full Build Summary: https://kernelci.org/build/kselftest/branch/next/kernel/v6.8-rc1/ Tree: kselftest Branch: next Git Describe: v6.8-rc1 Git Commit: 6613476e225e090cc9aad49be7fa504e290dd33d Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git Built: 4 unique architectures Build Failures Detected: i386: i386_defconfig+kselftest: (gcc-10) FAIL x86_64: x86_64_defconfig+kselftest: (gcc-10) FAIL Errors and Warnings Detected: arm64: defconfig+kselftest (gcc-10): 1 warning arm: multi_v7_defconfig+kselftest (gcc-10): 1 warning i386: i386_defconfig+kselftest (gcc-10): 1 error, 1 warning x86_64: x86_64_defconfig+kselftest (gcc-10): 1 error, 1 warning x86_64_defconfig+kselftest (clang-16): 1 warning Errors summary: 2 include/linux/fortify-string.h:57:29: error: ‘__builtin_memcpy’ offset 32 is out of the bounds [0, 0] [-Werror=array-bounds] Warnings summary: 2 include/linux/fortify-string.h:57:29: warning: ‘__builtin_memcpy’ offset 32 is out of the bounds [0, 0] [-Warray-bounds] 2 cc1: all warnings being treated as errors 1 vmlinux.o: warning: objtool: set_ftrace_ops_ro+0x39: relocation to !ENDBR: .text+0x14cfd6 ================================================================================ Detailed per-defconfig build reports: -------------------------------------------------------------------------------- defconfig+kselftest (arm64, gcc-10) — PASS, 0 errors, 1 warning, 0 section mismatches Warnings: include/linux/fortify-string.h:57:29: warning: ‘__builtin_memcpy’ offset 32 is out of the bounds [0, 0] [-Warray-bounds] -------------------------------------------------------------------------------- i386_defconfig+kselftest (i386, gcc-10) — FAIL, 1 error, 1 warning, 0 section mismatches Errors: include/linux/fortify-string.h:57:29: error: ‘__builtin_memcpy’ offset 32 is out of the bounds [0, 0] [-Werror=array-bounds] Warnings: cc1: all warnings being treated as errors -------------------------------------------------------------------------------- multi_v7_defconfig+kselftest (arm, gcc-10) — PASS, 0 errors, 1 warning, 0 section mismatches Warnings: include/linux/fortify-string.h:57:29: warning: ‘__builtin_memcpy’ offset 32 is out of the bounds [0, 0] [-Warray-bounds] -------------------------------------------------------------------------------- x86_64_defconfig+kselftest (x86_64, gcc-10) — FAIL, 1 error, 1 warning, 0 section mismatches Errors: include/linux/fortify-string.h:57:29: error: ‘__builtin_memcpy’ offset 32 is out of the bounds [0, 0] [-Werror=array-bounds] Warnings: cc1: all warnings being treated as errors -------------------------------------------------------------------------------- x86_64_defconfig+kselftest (x86_64, clang-16) — PASS, 0 errors, 1 warning, 0 section mismatches Warnings: vmlinux.o: warning: objtool: set_ftrace_ops_ro+0x39: relocation to !ENDBR: .text+0x14cfd6 --- For more info write to <info(a)kernelci.org>

1 year, 9 months

1
0
0 0

[PATCH net v2] selftests: net: fix rps_default_mask with >32 CPUs

by Jakub Kicinski

If there is more than 32 cpus the bitmask will start to contain commas, leading to: ./rps_default_mask.sh: line 36: [: 00000000,00000000: integer expression expected Remove the commas, bash doesn't interpret leading zeroes as oct so that should be good enough. Fixes: c12e0d5f267d ("self-tests: introduce self-tests for RPS default mask") Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> --- v2: - remove all commas v1: https://lore.kernel.org/all/20240119151248.3476897-1-kuba@kernel.org/ CC: shuah(a)kernel.org CC: horms(a)kernel.org CC: linux-kselftest(a)vger.kernel.org --- tools/testing/selftests/net/rps_default_mask.sh | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/tools/testing/selftests/net/rps_default_mask.sh b/tools/testing/selftests/net/rps_default_mask.sh index a26c5624429f..4729e7026a73 100755 --- a/tools/testing/selftests/net/rps_default_mask.sh +++ b/tools/testing/selftests/net/rps_default_mask.sh @@ -33,6 +33,10 @@ chk_rps() { rps_mask=$($cmd /sys/class/net/$dev_name/queues/rx-0/rps_cpus) printf "%-60s" "$msg" + + # In case there is more than 32 CPUs we need to remove commas from masks + rps_mask=${rps_mask//,} + expected_rps_mask=${expected_rps_mask//,} if [ $rps_mask -eq $expected_rps_mask ]; then echo "[ ok ]" else -- 2.43.0

1 year, 9 months

2
2
0 0

[RFC PATCH v3 00/11] Introduce mseal()

by jeffxu＠chromium.org

From: Jeff Xu <jeffxu(a)chromium.org> This patchset proposes a new mseal() syscall for the Linux kernel. In a nutshell, mseal() protects the VMAs of a given virtual memory range against modifications, such as changes to their permission bits. Modern CPUs support memory permissions, such as the read/write (RW) and no-execute (NX) bits. Linux has supported NX since the release of kernel version 2.6.8 in August 2004 [1]. The memory permission feature improves the security stance on memory corruption bugs, as an attacker cannot simply write to arbitrary memory and point the code to it. The memory must be marked with the X bit, or else an exception will occur. Internally, the kernel maintains the memory permissions in a data structure called VMA (vm_area_struct). mseal() additionally protects the VMA itself against modifications of the selected seal type. Memory sealing is useful to mitigate memory corruption issues where a corrupted pointer is passed to a memory management system. For example, such an attacker primitive can break control-flow integrity guarantees since read-only memory that is supposed to be trusted can become writable or .text pages can get remapped. Memory sealing can automatically be applied by the runtime loader to seal .text and .rodata pages and applications can additionally seal security critical data at runtime. A similar feature already exists in the XNU kernel with the VM_FLAGS_PERMANENT [3] flag and on OpenBSD with the mimmutable syscall [4]. Also, Chrome wants to adopt this feature for their CFI work [2] and this patchset has been designed to be compatible with the Chrome use case. The new mseal() is an architecture independent syscall, and with following signature: mseal(void addr, size_t len, unsigned long types, unsigned long flags) addr/len: memory range. Must be continuous/allocated memory, or else mseal() will fail and no VMA is updated. For details on acceptable arguments, please refer to documentation patch (mseal.rst) of this patch set. Those are also fully covered by the selftest. types: bit mask to specify the sealing types. MM_SEAL_BASE MM_SEAL_PROT_PKEY MM_SEAL_DISCARD_RO_ANON MM_SEAL_SEAL The MM_SEAL_BASE: The base package includes the features common to all VMA sealing types. It prevents sealed VMAs from: 1> Unmapping, moving to another location, and shrinking the size, via munmap() and mremap(), can leave an empty space, therefore can be replaced with a VMA with a new set of attributes. 2> Move or expand a different vma into the current location, via mremap(). 3> Modifying sealed VMA via mmap(MAP_FIXED). 4> Size expansion, via mremap(), does not appear to pose any specific risks to sealed VMAs. It is included anyway because the use case is unclear. In any case, users can rely on merging to expand a sealed VMA. We consider the MM_SEAL_BASE feature, on which other sealing features will depend. For instance, it probably does not make sense to seal PROT_PKEY without sealing the BASE, and the kernel will implicitly add SEAL_BASE for SEAL_PROT_PKEY. The MM_SEAL_PROT_PKEY: Seal PROT and PKEY of the address range, i.e. mprotect() and pkey_mprotect() will be denied if the memory is sealed with MM_SEAL_PROT_PKEY. The MM_SEAL_DISCARD_RO_ANON Certain types of madvise() operations are destructive [6], such as MADV_DONTNEED, which can effectively alter region contents by discarding pages, especially when memory is anonymous. This blocks such operations for anonymous memory which is not writable to the user. The MM_SEAL_SEAL MM_SEAL_SEAL denies adding a new seal for an VMA. This is similar to F_SEAL_SEAL in fcntl. The idea that inspired this patch comes from Stephen Röttger’s work in V8 CFI [5]. Chrome browser in ChromeOS will be the first user of this API. Indeed, the Chrome browser has very specific requirements for sealing, which are distinct from those of most applications. For example, in the case of libc, sealing is only applied to read-only (RO) or read-execute (RX) memory segments (such as .text and .RELRO) to prevent them from becoming writable, the lifetime of those mappings are tied to the lifetime of the process. Chrome wants to seal two large address space reservations that are managed by different allocators. The memory is mapped RW- and RWX respectively but write access to it is restricted using pkeys (or in the future ARM permission overlay extensions). The lifetime of those mappings are not tied to the lifetime of the process, therefore, while the memory is sealed, the allocators still need to free or discard the unused memory. For example, with madvise(DONTNEED). However, always allowing madvise(DONTNEED) on this range poses a security risk. For example if a jump instruction crosses a page boundary and the second page gets discarded, it will overwrite the target bytes with zeros and change the control flow. Checking write-permission before the discard operation allows us to control when the operation is valid. In this case, the madvise will only succeed if the executing thread has PKEY write permissions and PKRU changes are protected in software by control-flow integrity. Although the initial version of this patch series is targeting the Chrome browser as its first user, it became evident during upstream discussions that we would also want to ensure that the patch set eventually is a complete solution for memory sealing and compatible with other use cases. The specific scenario currently in mind is glibc's use case of loading and sealing ELF executables. To this end, Stephen is working on a change to glibc to add sealing support to the dynamic linker, which will seal all non-writable segments at startup. Once this work is completed, all applications will be able to automatically benefit from these new protections. -------------------------------------------------------------------- Change history: =============== V3: - Abandon per-syscall approach, (Suggested by Linus Torvalds). - Organize sealing types around their functionality, such as MM_SEAL_BASE, MM_SEAL_PROT_PKEY. - Extend the scope of sealing from calls originated in userspace to both kernel and userspace. (Suggested by Linus Torvalds) - Add seal type support in mmap(). (Suggested by Pedro Falcato) - Add a new sealing type: MM_SEAL_DISCARD_RO_ANON to prevent destructive operations of madvise. (Suggested by Jann Horn and Stephen Röttger) - Make sealed VMAs mergeable. (Suggested by Jann Horn) - Add MAP_SEALABLE to mmap() (Detail see new discussions) - Add documentation - mseal.rst Work in progress: ================= - update man page for mseal() and mmap() Open discussions: ================= Several open discussions from V1/V2 were not incorporated into V3. I believe these are worth more discussion for future versions of this patch series. 1> mseal() vs mimmutable() mseal(bitmasks for multiple seal types) BASE + PROT_PKEY+ MM_SEAL_DISCARD_RO_ANON Apply PROT_PKEY implies BASE, same for DISCARD_RO_ANON mimmutable() (openBSD) This is equal to SEAL_BASE + SEAL_PROT_PKEY in mseal() Plus allowing downgrade from W=>NW (OpenBSD) Doesn’t have MM_SEAL_DISCARD_RO_ANON mimmutable() is designed for memory sealing in libc, and mseal() is designed for both Chrome browser and libc. For the two memory ranges that Chrome browser wants to seal, as discussed previously, the allocator still needs to free or discard memory for the sealed memory. For performance reasons, we have explored two solutions in the past: first, using PKEY-based munmap() [7], and second, separating SEAL_MPROTECT (v1 of this patch set). Recently, we have experimented with an alternative approach that allows us to remove the separation of SEAL_MPROTECT. For those two memory ranges, Chrome browser will use BASE + PROT_PKEY + DISCARD_RO_ANON for all its sealing needs. In the case of libc, the .text segment can be sealed with the BASE and PROT_PKEY, and the RO data segments can be sealed with the BASE + PROT_PKEY + DISCARD_RO_ANON. From a flexibility standpoint, separating BASE out could be beneficial for future extensions of sealing features. For instance, applications might desire downgradable "prot" permissions (X=>NX, W=>NW, R=>NR), which would conflict with SEAL_PROT_PKEY. The more sealing features integrated into a single sealing type, the fewer applications can utilize these features. For example, some applications might programmatically require DISCARD_RO_ANON memory, which would render such VMA unsuitable for sealing. I'd like to get the community's input on this. From Chrome's perspective, the separation isn't as important anymore, at least in the short term. However, I prefer the multiple bits approach because it's more extensible in the long term. 2> mseal() vs mprotect() vs madvise() for setting the seal. mprotect(): Using prot field, but prot supports unset. It's workable, i.e. let applications carry the sealing type and set in all subsequent calls to mprotect(), but it feels like this is an extra thing to care about. madvise(): uses enum, multiple sealing types might require multiple roundtrips. IMO: sealing is a major departure from other memory syscalls because it takes away capabilities. The other memory APIs add behaviors or change attributes, but sealing does the opposite: it reduces capabilities. The name of the syscall, mseal(), can help emphasize the "taking away" part. My second choice would be madvise(). 3> Other: There is also a topic about ptrace/, /proc/self/mem, Userfaultfd, which I think can be followed up using v1 thread, where it has the most context. New discussions topics: ======================= During the development of V3, I had new questions and thoughts and wished to discuss. 1> shm/aio From reading the code, it seems to me that aio/shm can mmap/munmap maps on behalf of userspace, e.g. ksys_shmdt() in shm.c. The lifetime of those mapping are not tied to the lifetime of the process. If those memories are sealed from userspace, then unmap will fail. This isn’t a huge problem, since the memory will eventually be freed at exit or exec. However, it feels like the solution is not complete, because of the leaks in VMA address space during the lifetime of the process. There could be two solutions to address this, which I will discuss later. 2> Brk (heap/stack) Currently, userspace applications can seal parts of the heap by calling malloc() and mseal(). This raises the question of what the expected behavior is when sealing the heap is attempted. let's assume following calls from user space: ptr = malloc(size); mprotect(ptr, size, RO); mseal(ptr, size, SEAL_PROT_PKEY); free(ptr); Technically, before mseal() is added, the user can change the protection of the heap by calling mprotect(RO). As long as the user changes the protection back to RW before free(), the memory can be reused. Adding mseal() into picture, however, the heap is then sealed partially, user can still free it, but the memory remains to be RO, and the result of brk-shrink is nondeterministic, depending on if munmap() will try to free the sealed memory.(brk uses munmap to shrink the heap). 3> Above two cases led to the third topic: There are two options to address the problem mentioned above. Option 1: A “MAP_SEALABLE” flag in mmap(). If a map is created without this flag, the mseal() operation will fail. Applications that are not concerned with sealing will expect their behavior to be unchanged. For those that are concerned, adding a flag at mmap time to opt in is not difficult. For the short term, this solves problems 1 and 2 above. The memory in shm/aio/brk will not have the MAP_SEALABLE flag at mmap(), and the same is true for the heap. Option 2: Add MM_SEAL_SEAL during mmap() It is possible to defensively set MM_SEAL_SEAL for the selected mappings at creation time. Specifically, we can find all the mmaps that we do not want to seal, and add the MM_SEAL_SEAL flag in the mmap() call. The difference between MAP_SEALABLE and MM_SEAL_SEAL is that the first option starts from a small size and incrementally increases, while the second option is the opposite. In my opinion, MAP_SEALABLE is the preferred option. Only a limited set of mappings need to be sealed, and these are typically created by the runtime. For the few dedicated applications that manage their own mappings, such as Chrome, adding an extra flag at mmap() is not a difficult task. It is also a safer option in terms of regression risk. This is the option included in this version. 4> I think it might be possible to seal the stack or other special mappings created at runtime (vdso, vsyscall, vvar). This means we can enforce and seal W^X for certain types of application. For instance, the stack is typically used in read-write mode, but in some cases, it can become executable. To defend against unintented addition of executable bit to stack, we could let the application to seal it. Sealing the heap (for adding X) requires special handling, since the heap can shrink, and shrink is implemented through munmap(). Indeed, it might be possible that all virtual memory accessible to user space, regardless of its usage pattern, could be sealed. However, this would require additional research and development work. ------------------------------------------------------------------------ v2: Use _BITUL to define MM_SEAL_XX type. Use unsigned long for seal type in sys_mseal() and other functions. Remove internal VM_SEAL_XX type and convert_user_seal_type(). Remove MM_ACTION_XX type. Remove caller_origin(ON_BEHALF_OF_XX) and replace with sealing bitmask. Add more comments in code. Add a detailed commit message. https://lore.kernel.org/lkml/20231017090815.1067790-1-jeffxu@chromium.org/ v1: https://lore.kernel.org/lkml/20231016143828.647848-1-jeffxu@chromium.org/ ---------------------------------------------------------------- [1] https://kernelnewbies.org/Linux_2_6_8 [2] https://v8.dev/blog/control-flow-integrity [3] https://github.com/apple-oss-distributions/xnu/blob/1031c584a5e37aff177559b… [4] https://man.openbsd.org/mimmutable.2 [5] https://docs.google.com/document/d/1O2jwK4dxI3nRcOJuPYkonhTkNQfbmwdvxQMyXge… [6] https://lore.kernel.org/lkml/CAG48ez3ShUYey+ZAFsU2i1RpQn0a5eOs2hzQ426Fkcgnf… [7] https://lore.kernel.org/lkml/20230515130553.2311248-1-jeffxu@chromium.org/ Jeff Xu (11): mseal: Add mseal syscall. mseal: Wire up mseal syscall mseal: add can_modify_mm and can_modify_vma mseal: add MM_SEAL_BASE mseal: add MM_SEAL_PROT_PKEY mseal: add sealing support for mmap mseal: make sealed VMA mergeable. mseal: add MM_SEAL_DISCARD_RO_ANON mseal: add MAP_SEALABLE to mmap() selftest mm/mseal memory sealing mseal:add documentation Documentation/userspace-api/mseal.rst | 189 ++ arch/alpha/kernel/syscalls/syscall.tbl | 1 + arch/arm/tools/syscall.tbl | 1 + arch/arm64/include/asm/unistd.h | 2 +- arch/arm64/include/asm/unistd32.h | 2 + arch/ia64/kernel/syscalls/syscall.tbl | 1 + arch/m68k/kernel/syscalls/syscall.tbl | 1 + arch/microblaze/kernel/syscalls/syscall.tbl | 1 + arch/mips/kernel/syscalls/syscall_n32.tbl | 1 + arch/mips/kernel/syscalls/syscall_n64.tbl | 1 + arch/mips/kernel/syscalls/syscall_o32.tbl | 1 + arch/mips/kernel/vdso.c | 10 +- arch/parisc/kernel/syscalls/syscall.tbl | 1 + arch/powerpc/kernel/syscalls/syscall.tbl | 1 + arch/s390/kernel/syscalls/syscall.tbl | 1 + arch/sh/kernel/syscalls/syscall.tbl | 1 + arch/sparc/kernel/syscalls/syscall.tbl | 1 + arch/x86/entry/syscalls/syscall_32.tbl | 1 + arch/x86/entry/syscalls/syscall_64.tbl | 1 + arch/xtensa/kernel/syscalls/syscall.tbl | 1 + fs/userfaultfd.c | 8 +- include/linux/mm.h | 178 +- include/linux/mm_types.h | 8 + include/linux/syscalls.h | 2 + include/uapi/asm-generic/mman-common.h | 16 + include/uapi/asm-generic/unistd.h | 5 +- include/uapi/linux/mman.h | 5 + kernel/sys_ni.c | 1 + mm/Kconfig | 9 + mm/Makefile | 1 + mm/madvise.c | 14 +- mm/mempolicy.c | 2 +- mm/mlock.c | 2 +- mm/mmap.c | 77 +- mm/mprotect.c | 12 +- mm/mremap.c | 44 +- mm/mseal.c | 376 ++++ tools/testing/selftests/mm/.gitignore | 1 + tools/testing/selftests/mm/Makefile | 1 + tools/testing/selftests/mm/config | 1 + tools/testing/selftests/mm/mseal_test.c | 2141 +++++++++++++++++++ 41 files changed, 3091 insertions(+), 32 deletions(-) create mode 100644 Documentation/userspace-api/mseal.rst create mode 100644 mm/mseal.c create mode 100644 tools/testing/selftests/mm/mseal_test.c -- 2.43.0.472.g3155946c3a-goog

1 year, 9 months

9
27
0 0

lsm_cgroup.c selftest fails to compile when CONFIG_PACKET!=y

by Shung-Hsi Yu

Hi, Compilation of lsm_cgroup.c will fail if the vmlinux.h comes from a kernel that does _not_ have CONFIG_PACKET=y. The reason is that the definition of struct sockaddr_ll is not present in vmlinux.h and the compiler will complain that is has an incomplete type. CLNG-BPF [test_maps] lsm_cgroup.bpf.o progs/lsm_cgroup.c:105:21: error: variable has incomplete type 'struct sockaddr_ll' 105 | struct sockaddr_ll sa = {}; | ^ progs/lsm_cgroup.c:105:9: note: forward declaration of 'struct sockaddr_ll' 105 | struct sockaddr_ll sa = {}; | ^ 1 error generated. While including linux/if_packet.h somehow made the compilation works for me, IIUC this isn't a proper solution because vmlinux.h and kernel headers should not be used at the same time (and would lead to redefinition error when the kernel is built with CONFIG_PACKET=y, e.g. on BPF CI). What would be the suggested way to work around this? Thanks, Shung-Hsi --- tools/testing/selftests/bpf/progs/lsm_cgroup.c | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/testing/selftests/bpf/progs/lsm_cgroup.c b/tools/testing/selftests/bpf/progs/lsm_cgroup.c index 02c11d16b692..5394ec7ae1d8 100644 --- a/tools/testing/selftests/bpf/progs/lsm_cgroup.c +++ b/tools/testing/selftests/bpf/progs/lsm_cgroup.c @@ -2,6 +2,7 @@ #include "vmlinux.h" #include "bpf_tracing_net.h" +#include <linux/if_packet.h> #include <bpf/bpf_helpers.h> #include <bpf/bpf_tracing.h>

1 year, 9 months

6
10
0 0

[PATCH net] selftests: net: fix rps_default_mask with >32 CPUs

by Jakub Kicinski

If there is more than 32 cpus the bitmask will start to contain commas, leading to: ./rps_default_mask.sh: line 36: [: 00000000,00000000: integer expression expected Remove the commas, bash doesn't interpret leading zeroes as oct so that should be good enough. Fixes: c12e0d5f267d ("self-tests: introduce self-tests for RPS default mask") Signed-off-by: Jakub Kicinski <kuba(a)kernel.org> --- CC: shuah(a)kernel.org CC: horms(a)kernel.org CC: linux-kselftest(a)vger.kernel.org --- tools/testing/selftests/net/rps_default_mask.sh | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/tools/testing/selftests/net/rps_default_mask.sh b/tools/testing/selftests/net/rps_default_mask.sh index a26c5624429f..f8e786e220b6 100755 --- a/tools/testing/selftests/net/rps_default_mask.sh +++ b/tools/testing/selftests/net/rps_default_mask.sh @@ -33,6 +33,10 @@ chk_rps() { rps_mask=$($cmd /sys/class/net/$dev_name/queues/rx-0/rps_cpus) printf "%-60s" "$msg" + + # In case there is more than 32 CPUs we need to remove commas from masks + rps_mask=${rps_mask/,} + expected_rps_mask=${expected_rps_mask/,} if [ $rps_mask -eq $expected_rps_mask ]; then echo "[ ok ]" else -- 2.43.0

1 year, 9 months

2
2
0 0

[PATCH net 0/2] selftests: net: Small fixes

by Benjamin Poirier

From: Benjamin Poirier <benjamin.poirier(a)gmail.com> Two small fixes for net selftests. These patches were carved out of the following RFC series: https://lore.kernel.org/netdev/20231222135836.992841-1-bpoirier@nvidia.com/ I'm planning to send the rest of the series to net-next after it opens up. Benjamin Poirier (2): selftests: bonding: Change script interpreter selftests: forwarding: Remove executable bits from lib.sh .../selftests/drivers/net/bonding/mode-1-recovery-updelay.sh | 2 +- .../selftests/drivers/net/bonding/mode-2-recovery-updelay.sh | 2 +- tools/testing/selftests/net/forwarding/lib.sh | 0 3 files changed, 2 insertions(+), 2 deletions(-) mode change 100755 => 100644 tools/testing/selftests/net/forwarding/lib.sh -- 2.43.0

1 year, 9 months

4
8
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-kselftest-mirror January 2024