* [PATCH v2 1/2] selftests: Centralize include path for kselftest.h and kselftest_harness.h
From: Bala-Vignesh-Reddy @ 2025-08-30 16:39 UTC (permalink / raw)
To: reddybalavignesh9979, akpm, richard.weiyang
Cc: Liam.Howlett, davem, david, edumazet, gnoack, horms, kuba,
linux-kernel, linux-kselftest, linux-mm, linux-security-module,
lorenzo.stoakes, mhocko, mic, ming.lei, pabeni, rppt, shuah,
skhan, surenb, vbabka
In-Reply-To: <20250830163949.20952-1-reddybalavignesh9979@gmail.com>
Add compile flag in lib.mk, to include the selftest/
directory while building.
Suggested-by: Wei Yang <richard.weiyang@gmail.com>
Signed-off-by: Bala-Vignesh-Reddy <reddybalavignesh9979@gmail.com>
---
tools/testing/selftests/lib.mk | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/testing/selftests/lib.mk b/tools/testing/selftests/lib.mk
index 530390033929..975840bb5477 100644
--- a/tools/testing/selftests/lib.mk
+++ b/tools/testing/selftests/lib.mk
@@ -199,6 +199,8 @@ clean: $(if $(TEST_GEN_MODS_DIR),clean_mods_dir)
# Build with _GNU_SOURCE by default
CFLAGS += -D_GNU_SOURCE=
+CFLAGS += -I${top_srcdir}/tools/testing/selftests
+
# Enables to extend CFLAGS and LDFLAGS from command line, e.g.
# make USERCFLAGS=-Werror USERLDFLAGS=-static
CFLAGS += $(USERCFLAGS)
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/2] selftests: Centralize kselftest headers to avoid relative includes
From: Bala-Vignesh-Reddy @ 2025-08-30 16:39 UTC (permalink / raw)
To: reddybalavignesh9979, akpm, richard.weiyang
Cc: Liam.Howlett, davem, david, edumazet, gnoack, horms, kuba,
linux-kernel, linux-kselftest, linux-mm, linux-security-module,
lorenzo.stoakes, mhocko, mic, ming.lei, pabeni, rppt, shuah,
skhan, surenb, vbabka
In-Reply-To: <20250827144733.82277-1-reddybalavignesh9979@gmail.com>
This series centralize the handling of kselftest.h and
kselftest_harness.h includes in selftests, replacing relative
paths with a non-relative approach using shared -I path.
Patch-1 updates the build files lib.mk and
include CFLAGS in sync/Makefile to resolve not found error
Patch-2 applies bulk source changes
In v2, the include path for selftests headers is added once in
lib.mk via top_srcdir, by which top level selftests build and
direct subdirectory builds work.
Tested with gcc-13.3 and clang-18.1.
Suggested-by: Andrew Morton <akpm@linux-foundation.org>
Link: https://lore.kernel.org/lkml/20250820143954.33d95635e504e94df01930d0@linux-foundation.org/
Signed-off-by: Bala-Vignesh-Reddy <reddybalavignesh9979@gmail.com>
---
Changes in v2:
Patch 1: Move include path into lib.mk using top_srcdir; drop Makefile change;
Patch 2 unchanged.
Suggested-by: Wei Yang <richard.weiyang@gmail.com>
---
Bala-Vignesh-Reddy (2):
selftests: Centralize include path for kselftest.h and
kselftest_harness.h
selftests: Replace relative includes with non-relative for kselftest.h
and kselftest_harness.h
tools/testing/selftests/acct/acct_syscall.c | 2 +-
tools/testing/selftests/alsa/conf.c | 2 +-
tools/testing/selftests/alsa/mixer-test.c | 2 +-
tools/testing/selftests/alsa/pcm-test.c | 2 +-
tools/testing/selftests/alsa/test-pcmtest-driver.c | 2 +-
tools/testing/selftests/alsa/utimer-test.c | 2 +-
tools/testing/selftests/arm64/abi/hwcap.c | 2 +-
tools/testing/selftests/arm64/abi/ptrace.c | 2 +-
tools/testing/selftests/arm64/abi/syscall-abi.c | 2 +-
tools/testing/selftests/arm64/fp/fp-ptrace.c | 2 +-
tools/testing/selftests/arm64/fp/fp-stress.c | 2 +-
tools/testing/selftests/arm64/fp/sve-probe-vls.c | 2 +-
tools/testing/selftests/arm64/fp/sve-ptrace.c | 2 +-
tools/testing/selftests/arm64/fp/vec-syscfg.c | 2 +-
tools/testing/selftests/arm64/fp/za-ptrace.c | 2 +-
tools/testing/selftests/arm64/fp/zt-ptrace.c | 2 +-
tools/testing/selftests/arm64/gcs/gcs-stress.c | 2 +-
tools/testing/selftests/arm64/pauth/pac.c | 2 +-
tools/testing/selftests/arm64/tags/tags_test.c | 2 +-
tools/testing/selftests/bpf/xskxceiver.c | 2 +-
tools/testing/selftests/breakpoints/breakpoint_test.c | 2 +-
tools/testing/selftests/breakpoints/breakpoint_test_arm64.c | 2 +-
tools/testing/selftests/breakpoints/step_after_suspend_test.c | 2 +-
tools/testing/selftests/cachestat/test_cachestat.c | 2 +-
tools/testing/selftests/capabilities/test_execve.c | 2 +-
tools/testing/selftests/capabilities/validate_cap.c | 2 +-
tools/testing/selftests/cgroup/test_core.c | 2 +-
tools/testing/selftests/cgroup/test_cpu.c | 2 +-
tools/testing/selftests/cgroup/test_cpuset.c | 2 +-
tools/testing/selftests/cgroup/test_freezer.c | 2 +-
tools/testing/selftests/cgroup/test_hugetlb_memcg.c | 2 +-
tools/testing/selftests/cgroup/test_kill.c | 2 +-
tools/testing/selftests/cgroup/test_kmem.c | 2 +-
tools/testing/selftests/cgroup/test_memcontrol.c | 2 +-
tools/testing/selftests/cgroup/test_pids.c | 2 +-
tools/testing/selftests/cgroup/test_zswap.c | 2 +-
tools/testing/selftests/clone3/clone3.c | 2 +-
.../testing/selftests/clone3/clone3_cap_checkpoint_restore.c | 2 +-
tools/testing/selftests/clone3/clone3_clear_sighand.c | 2 +-
tools/testing/selftests/clone3/clone3_selftests.h | 2 +-
tools/testing/selftests/clone3/clone3_set_tid.c | 2 +-
tools/testing/selftests/connector/proc_filter.c | 2 +-
tools/testing/selftests/core/close_range_test.c | 2 +-
tools/testing/selftests/core/unshare_test.c | 2 +-
tools/testing/selftests/coredump/stackdump_test.c | 2 +-
tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c | 2 +-
tools/testing/selftests/drivers/dma-buf/udmabuf.c | 2 +-
tools/testing/selftests/drivers/ntsync/ntsync.c | 2 +-
.../testing/selftests/drivers/s390x/uvdevice/test_uvdevice.c | 2 +-
tools/testing/selftests/exec/check-exec.c | 2 +-
tools/testing/selftests/exec/execveat.c | 2 +-
tools/testing/selftests/exec/load_address.c | 2 +-
tools/testing/selftests/exec/non-regular.c | 2 +-
tools/testing/selftests/exec/null-argv.c | 2 +-
tools/testing/selftests/exec/recursion-depth.c | 2 +-
tools/testing/selftests/fchmodat2/fchmodat2_test.c | 2 +-
tools/testing/selftests/filelock/ofdlocks.c | 2 +-
tools/testing/selftests/filesystems/anon_inode_test.c | 2 +-
tools/testing/selftests/filesystems/binderfs/binderfs_test.c | 2 +-
tools/testing/selftests/filesystems/devpts_pts.c | 2 +-
tools/testing/selftests/filesystems/epoll/epoll_wakeup_test.c | 2 +-
tools/testing/selftests/filesystems/eventfd/eventfd_test.c | 2 +-
tools/testing/selftests/filesystems/file_stressor.c | 2 +-
tools/testing/selftests/filesystems/kernfs_test.c | 2 +-
.../selftests/filesystems/mount-notify/mount-notify_test.c | 2 +-
.../selftests/filesystems/mount-notify/mount-notify_test_ns.c | 2 +-
tools/testing/selftests/filesystems/nsfs/iterate_mntns.c | 2 +-
tools/testing/selftests/filesystems/overlayfs/dev_in_maps.c | 2 +-
.../selftests/filesystems/overlayfs/set_layers_via_fds.c | 2 +-
.../testing/selftests/filesystems/statmount/listmount_test.c | 2 +-
.../testing/selftests/filesystems/statmount/statmount_test.c | 2 +-
.../selftests/filesystems/statmount/statmount_test_ns.c | 2 +-
tools/testing/selftests/filesystems/utils.c | 2 +-
tools/testing/selftests/hid/hid_common.h | 2 +-
tools/testing/selftests/intel_pstate/aperf.c | 2 +-
tools/testing/selftests/iommu/iommufd_utils.h | 2 +-
tools/testing/selftests/ipc/msgque.c | 2 +-
tools/testing/selftests/ir/ir_loopback.c | 2 +-
tools/testing/selftests/kcmp/kcmp_test.c | 2 +-
tools/testing/selftests/kselftest_harness.h | 2 +-
tools/testing/selftests/kselftest_harness/harness-selftest.c | 2 +-
tools/testing/selftests/landlock/audit.h | 2 +-
tools/testing/selftests/landlock/common.h | 2 +-
tools/testing/selftests/lib.mk | 2 ++
tools/testing/selftests/lsm/lsm_get_self_attr_test.c | 2 +-
tools/testing/selftests/lsm/lsm_list_modules_test.c | 2 +-
tools/testing/selftests/lsm/lsm_set_self_attr_test.c | 2 +-
tools/testing/selftests/media_tests/media_device_open.c | 2 +-
tools/testing/selftests/media_tests/media_device_test.c | 2 +-
tools/testing/selftests/membarrier/membarrier_test_impl.h | 2 +-
tools/testing/selftests/mincore/mincore_selftest.c | 4 ++--
tools/testing/selftests/mm/compaction_test.c | 2 +-
tools/testing/selftests/mm/cow.c | 2 +-
tools/testing/selftests/mm/droppable.c | 2 +-
tools/testing/selftests/mm/guard-regions.c | 2 +-
tools/testing/selftests/mm/gup_longterm.c | 2 +-
tools/testing/selftests/mm/gup_test.c | 2 +-
tools/testing/selftests/mm/hmm-tests.c | 2 +-
tools/testing/selftests/mm/hugepage-mmap.c | 2 +-
tools/testing/selftests/mm/hugepage-mremap.c | 2 +-
tools/testing/selftests/mm/hugetlb-madvise.c | 2 +-
tools/testing/selftests/mm/hugetlb-read-hwpoison.c | 2 +-
tools/testing/selftests/mm/hugetlb-soft-offline.c | 2 +-
tools/testing/selftests/mm/hugetlb_dio.c | 2 +-
tools/testing/selftests/mm/hugetlb_fault_after_madv.c | 2 +-
tools/testing/selftests/mm/hugetlb_madv_vs_map.c | 2 +-
tools/testing/selftests/mm/ksm_functional_tests.c | 2 +-
tools/testing/selftests/mm/ksm_tests.c | 2 +-
tools/testing/selftests/mm/madv_populate.c | 2 +-
tools/testing/selftests/mm/map_fixed_noreplace.c | 2 +-
tools/testing/selftests/mm/map_hugetlb.c | 2 +-
tools/testing/selftests/mm/map_populate.c | 2 +-
tools/testing/selftests/mm/mdwe_test.c | 2 +-
tools/testing/selftests/mm/memfd_secret.c | 2 +-
tools/testing/selftests/mm/merge.c | 2 +-
tools/testing/selftests/mm/migration.c | 2 +-
tools/testing/selftests/mm/mkdirty.c | 2 +-
tools/testing/selftests/mm/mlock-random-test.c | 2 +-
tools/testing/selftests/mm/mlock2-tests.c | 2 +-
tools/testing/selftests/mm/mrelease_test.c | 2 +-
tools/testing/selftests/mm/mremap_dontunmap.c | 2 +-
tools/testing/selftests/mm/mremap_test.c | 2 +-
tools/testing/selftests/mm/mseal_test.c | 2 +-
tools/testing/selftests/mm/on-fault-limit.c | 2 +-
tools/testing/selftests/mm/pagemap_ioctl.c | 2 +-
tools/testing/selftests/mm/pfnmap.c | 2 +-
tools/testing/selftests/mm/pkey-helpers.h | 2 +-
tools/testing/selftests/mm/process_madv.c | 2 +-
tools/testing/selftests/mm/soft-dirty.c | 2 +-
tools/testing/selftests/mm/split_huge_page_test.c | 2 +-
tools/testing/selftests/mm/thuge-gen.c | 2 +-
tools/testing/selftests/mm/transhuge-stress.c | 2 +-
tools/testing/selftests/mm/uffd-common.h | 2 +-
tools/testing/selftests/mm/uffd-wp-mremap.c | 2 +-
tools/testing/selftests/mm/va_high_addr_switch.c | 2 +-
tools/testing/selftests/mm/virtual_address_range.c | 2 +-
tools/testing/selftests/mm/vm_util.c | 2 +-
tools/testing/selftests/mm/vm_util.h | 2 +-
tools/testing/selftests/mount_setattr/mount_setattr_test.c | 2 +-
.../move_mount_set_group/move_mount_set_group_test.c | 2 +-
tools/testing/selftests/mqueue/mq_open_tests.c | 2 +-
tools/testing/selftests/mqueue/mq_perf_tests.c | 2 +-
.../selftests/mseal_system_mappings/sysmap_is_sealed.c | 4 ++--
tools/testing/selftests/nci/nci_dev.c | 2 +-
tools/testing/selftests/net/af_unix/diag_uid.c | 2 +-
tools/testing/selftests/net/af_unix/msg_oob.c | 2 +-
tools/testing/selftests/net/af_unix/scm_inq.c | 2 +-
tools/testing/selftests/net/af_unix/scm_pidfd.c | 2 +-
tools/testing/selftests/net/af_unix/scm_rights.c | 2 +-
tools/testing/selftests/net/af_unix/unix_connect.c | 2 +-
tools/testing/selftests/net/bind_timewait.c | 2 +-
tools/testing/selftests/net/bind_wildcard.c | 2 +-
tools/testing/selftests/net/can/test_raw_filter.c | 2 +-
tools/testing/selftests/net/cmsg_sender.c | 2 +-
tools/testing/selftests/net/epoll_busy_poll.c | 2 +-
tools/testing/selftests/net/gro.c | 2 +-
tools/testing/selftests/net/ip_local_port_range.c | 2 +-
tools/testing/selftests/net/ipsec.c | 2 +-
tools/testing/selftests/net/netfilter/conntrack_dump_flush.c | 2 +-
tools/testing/selftests/net/netlink-dumps.c | 2 +-
tools/testing/selftests/net/proc_net_pktgen.c | 2 +-
tools/testing/selftests/net/psock_fanout.c | 2 +-
tools/testing/selftests/net/psock_tpacket.c | 2 +-
tools/testing/selftests/net/reuseaddr_ports_exhausted.c | 2 +-
tools/testing/selftests/net/reuseport_bpf.c | 2 +-
tools/testing/selftests/net/reuseport_bpf_numa.c | 2 +-
tools/testing/selftests/net/rxtimestamp.c | 2 +-
tools/testing/selftests/net/sk_so_peek_off.c | 2 +-
tools/testing/selftests/net/so_incoming_cpu.c | 2 +-
tools/testing/selftests/net/socket.c | 2 +-
tools/testing/selftests/net/tap.c | 2 +-
tools/testing/selftests/net/tcp_ao/lib/setup.c | 2 +-
tools/testing/selftests/net/tcp_fastopen_backup_key.c | 2 +-
tools/testing/selftests/net/tls.c | 2 +-
tools/testing/selftests/net/toeplitz.c | 2 +-
tools/testing/selftests/net/tun.c | 2 +-
tools/testing/selftests/net/udpgso_bench_tx.c | 2 +-
tools/testing/selftests/openat2/helpers.h | 2 +-
tools/testing/selftests/openat2/openat2_test.c | 2 +-
tools/testing/selftests/openat2/rename_attack_test.c | 2 +-
tools/testing/selftests/openat2/resolve_test.c | 2 +-
tools/testing/selftests/pci_endpoint/pci_endpoint_test.c | 2 +-
tools/testing/selftests/perf_events/mmap.c | 2 +-
tools/testing/selftests/perf_events/remove_on_exec.c | 2 +-
tools/testing/selftests/perf_events/sigtrap_threads.c | 2 +-
tools/testing/selftests/perf_events/watermark_signal.c | 2 +-
tools/testing/selftests/pid_namespace/pid_max.c | 2 +-
tools/testing/selftests/pid_namespace/regression_enomem.c | 2 +-
tools/testing/selftests/pidfd/pidfd.h | 2 +-
tools/testing/selftests/pidfd/pidfd_bind_mount.c | 2 +-
tools/testing/selftests/pidfd/pidfd_fdinfo_test.c | 2 +-
tools/testing/selftests/pidfd/pidfd_file_handle_test.c | 2 +-
tools/testing/selftests/pidfd/pidfd_getfd_test.c | 2 +-
tools/testing/selftests/pidfd/pidfd_info_test.c | 2 +-
tools/testing/selftests/pidfd/pidfd_open_test.c | 2 +-
tools/testing/selftests/pidfd/pidfd_poll_test.c | 2 +-
tools/testing/selftests/pidfd/pidfd_setattr_test.c | 2 +-
tools/testing/selftests/pidfd/pidfd_setns_test.c | 2 +-
tools/testing/selftests/pidfd/pidfd_test.c | 2 +-
tools/testing/selftests/pidfd/pidfd_wait.c | 2 +-
tools/testing/selftests/pidfd/pidfd_xattr_test.c | 2 +-
tools/testing/selftests/prctl/set-anon-vma-name-test.c | 2 +-
tools/testing/selftests/prctl/set-process-name.c | 2 +-
tools/testing/selftests/proc/proc-maps-race.c | 2 +-
tools/testing/selftests/proc/proc-pid-vm.c | 2 +-
tools/testing/selftests/ptrace/get_set_sud.c | 2 +-
tools/testing/selftests/ptrace/get_syscall_info.c | 2 +-
tools/testing/selftests/ptrace/set_syscall_info.c | 2 +-
tools/testing/selftests/ptrace/vmaccess.c | 2 +-
tools/testing/selftests/resctrl/resctrl.h | 2 +-
tools/testing/selftests/ring-buffer/map_test.c | 2 +-
tools/testing/selftests/riscv/abi/pointer_masking.c | 2 +-
tools/testing/selftests/riscv/hwprobe/cbo.c | 2 +-
tools/testing/selftests/riscv/hwprobe/hwprobe.c | 2 +-
tools/testing/selftests/riscv/hwprobe/which-cpus.c | 2 +-
tools/testing/selftests/riscv/mm/mmap_bottomup.c | 2 +-
tools/testing/selftests/riscv/mm/mmap_default.c | 2 +-
tools/testing/selftests/riscv/mm/mmap_test.h | 2 +-
tools/testing/selftests/riscv/sigreturn/sigreturn.c | 2 +-
tools/testing/selftests/riscv/vector/v_initval.c | 2 +-
tools/testing/selftests/riscv/vector/vstate_prctl.c | 2 +-
tools/testing/selftests/rseq/basic_percpu_ops_test.c | 2 +-
tools/testing/selftests/rseq/rseq.c | 2 +-
tools/testing/selftests/rtc/rtctest.c | 2 +-
tools/testing/selftests/seccomp/seccomp_benchmark.c | 2 +-
tools/testing/selftests/seccomp/seccomp_bpf.c | 2 +-
tools/testing/selftests/sgx/main.c | 2 +-
tools/testing/selftests/signal/mangle_uc_sigmask.c | 2 +-
tools/testing/selftests/signal/sas.c | 2 +-
tools/testing/selftests/sparc64/drivers/adi-test.c | 2 +-
tools/testing/selftests/sync/Makefile | 2 +-
tools/testing/selftests/sync/sync_test.c | 2 +-
tools/testing/selftests/sync/synctest.h | 2 +-
tools/testing/selftests/syscall_user_dispatch/sud_test.c | 2 +-
tools/testing/selftests/tdx/tdx_guest_test.c | 2 +-
tools/testing/selftests/timens/timens.h | 2 +-
tools/testing/selftests/timers/adjtick.c | 2 +-
tools/testing/selftests/timers/alarmtimer-suspend.c | 2 +-
tools/testing/selftests/timers/change_skew.c | 2 +-
tools/testing/selftests/timers/clocksource-switch.c | 2 +-
tools/testing/selftests/timers/freq-step.c | 2 +-
tools/testing/selftests/timers/inconsistency-check.c | 2 +-
tools/testing/selftests/timers/leap-a-day.c | 2 +-
tools/testing/selftests/timers/leapcrash.c | 2 +-
tools/testing/selftests/timers/mqueue-lat.c | 2 +-
tools/testing/selftests/timers/nanosleep.c | 2 +-
tools/testing/selftests/timers/nsleep-lat.c | 2 +-
tools/testing/selftests/timers/posix_timers.c | 2 +-
tools/testing/selftests/timers/raw_skew.c | 2 +-
tools/testing/selftests/timers/rtcpie.c | 2 +-
tools/testing/selftests/timers/set-2038.c | 2 +-
tools/testing/selftests/timers/set-tai.c | 2 +-
tools/testing/selftests/timers/set-timer-lat.c | 2 +-
tools/testing/selftests/timers/set-tz.c | 2 +-
tools/testing/selftests/timers/skew_consistency.c | 2 +-
tools/testing/selftests/timers/threadtest.c | 2 +-
tools/testing/selftests/timers/valid-adjtimex.c | 2 +-
tools/testing/selftests/tmpfs/bug-link-o-tmpfile.c | 2 +-
tools/testing/selftests/tty/tty_tstamp_update.c | 2 +-
tools/testing/selftests/uevent/uevent_filtering.c | 2 +-
tools/testing/selftests/user_events/abi_test.c | 2 +-
tools/testing/selftests/user_events/dyn_test.c | 2 +-
tools/testing/selftests/user_events/ftrace_test.c | 2 +-
tools/testing/selftests/user_events/perf_test.c | 2 +-
tools/testing/selftests/user_events/user_events_selftests.h | 2 +-
tools/testing/selftests/vDSO/vdso_test_abi.c | 2 +-
tools/testing/selftests/vDSO/vdso_test_chacha.c | 2 +-
tools/testing/selftests/vDSO/vdso_test_clock_getres.c | 2 +-
tools/testing/selftests/vDSO/vdso_test_correctness.c | 2 +-
tools/testing/selftests/vDSO/vdso_test_getcpu.c | 2 +-
tools/testing/selftests/vDSO/vdso_test_getrandom.c | 2 +-
tools/testing/selftests/vDSO/vdso_test_gettimeofday.c | 2 +-
tools/testing/selftests/x86/corrupt_xstate_header.c | 2 +-
tools/testing/selftests/x86/helpers.h | 2 +-
tools/testing/selftests/x86/lam.c | 2 +-
tools/testing/selftests/x86/syscall_numbering.c | 2 +-
tools/testing/selftests/x86/test_mremap_vdso.c | 2 +-
tools/testing/selftests/x86/test_vsyscall.c | 2 +-
tools/testing/selftests/x86/xstate.h | 2 +-
279 files changed, 282 insertions(+), 280 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH v6 1/4] Audit: Create audit_stamp structure
From: Casey Schaufler @ 2025-08-30 15:42 UTC (permalink / raw)
To: Paul Moore, eparis, linux-security-module, audit
Cc: jmorris, serge, keescook, john.johansen, penguin-kernel,
stephen.smalley.work, linux-kernel, selinux, Casey Schaufler
In-Reply-To: <e6e9ea4bacac5553810f7963533a71ca@paul-moore.com>
On 8/30/2025 7:14 AM, Paul Moore wrote:
> On Aug 16, 2025 Casey Schaufler <casey@schaufler-ca.com> wrote:
>> Replace the timestamp and serial number pair used in audit records
>> with a structure containing the two elements.
>>
>> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
>> ---
>> kernel/audit.c | 17 +++++++++--------
>> kernel/audit.h | 13 +++++++++----
>> kernel/auditsc.c | 22 +++++++++-------------
>> 3 files changed, 27 insertions(+), 25 deletions(-)
> Merged into audit/dev, thanks.
Thank you.
>
> --
> paul-moore.com
>
^ permalink raw reply
* Re: [PATCH v6 4/4] Audit: Add record for multiple object contexts
From: Paul Moore @ 2025-08-30 14:15 UTC (permalink / raw)
To: Casey Schaufler, casey, eparis, linux-security-module, audit
Cc: jmorris, serge, keescook, john.johansen, penguin-kernel,
stephen.smalley.work, linux-kernel, selinux
In-Reply-To: <20250816172859.6437-5-casey@schaufler-ca.com>
On Aug 16, 2025 Casey Schaufler <casey@schaufler-ca.com> wrote:
>
> Create a new audit record AUDIT_MAC_OBJ_CONTEXTS.
> An example of the MAC_OBJ_CONTEXTS record is:
>
> type=MAC_OBJ_CONTEXTS
> msg=audit(1601152467.009:1050):
> obj_selinux=unconfined_u:object_r:user_home_t:s0
>
> When an audit event includes a AUDIT_MAC_OBJ_CONTEXTS record
> the "obj=" field in other records in the event will be "obj=?".
> An AUDIT_MAC_OBJ_CONTEXTS record is supplied when the system has
> multiple security modules that may make access decisions based
> on an object security context.
>
> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
> ---
> include/linux/audit.h | 7 +++++
> include/uapi/linux/audit.h | 1 +
> kernel/audit.c | 58 +++++++++++++++++++++++++++++++++++++-
> kernel/auditsc.c | 38 +++++--------------------
> security/selinux/hooks.c | 4 ++-
> security/smack/smack_lsm.c | 4 ++-
> 6 files changed, 78 insertions(+), 34 deletions(-)
Merged into audit/dev, thanks.
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH v6 3/4] Audit: Add record for multiple task security contexts
From: Paul Moore @ 2025-08-30 14:15 UTC (permalink / raw)
To: Casey Schaufler, casey, eparis, linux-security-module, audit
Cc: jmorris, serge, keescook, john.johansen, penguin-kernel,
stephen.smalley.work, linux-kernel, selinux
In-Reply-To: <20250816172859.6437-4-casey@schaufler-ca.com>
On Aug 16, 2025 Casey Schaufler <casey@schaufler-ca.com> wrote:
>
> Replace the single skb pointer in an audit_buffer with a list of
> skb pointers. Add the audit_stamp information to the audit_buffer as
> there's no guarantee that there will be an audit_context containing
> the stamp associated with the event. At audit_log_end() time create
> auxiliary records as have been added to the list. Functions are
> created to manage the skb list in the audit_buffer.
>
> Create a new audit record AUDIT_MAC_TASK_CONTEXTS.
> An example of the MAC_TASK_CONTEXTS record is:
>
> type=MAC_TASK_CONTEXTS
> msg=audit(1600880931.832:113)
> subj_apparmor=unconfined
> subj_smack=_
>
> When an audit event includes a AUDIT_MAC_TASK_CONTEXTS record the
> "subj=" field in other records in the event will be "subj=?".
> An AUDIT_MAC_TASK_CONTEXTS record is supplied when the system has
> multiple security modules that may make access decisions based on a
> subject security context.
>
> Refactor audit_log_task_context(), creating a new audit_log_subj_ctx().
> This is used in netlabel auditing to provide multiple subject security
> contexts as necessary.
>
> Suggested-by: Paul Moore <paul@paul-moore.com>
> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
> ---
> include/linux/audit.h | 16 +++
> include/uapi/linux/audit.h | 1 +
> kernel/audit.c | 208 +++++++++++++++++++++++++++++------
> net/netlabel/netlabel_user.c | 9 +-
> security/apparmor/lsm.c | 3 +
> security/selinux/hooks.c | 3 +
> security/smack/smack_lsm.c | 3 +
> 7 files changed, 202 insertions(+), 41 deletions(-)
Merged into audit/dev, thanks.
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH v6 2/4] LSM: security_lsmblob_to_secctx module selection
From: Paul Moore @ 2025-08-30 14:14 UTC (permalink / raw)
To: Casey Schaufler, casey, eparis, linux-security-module, audit
Cc: jmorris, serge, keescook, john.johansen, penguin-kernel,
stephen.smalley.work, linux-kernel, selinux
In-Reply-To: <20250816172859.6437-3-casey@schaufler-ca.com>
On Aug 16, 2025 Casey Schaufler <casey@schaufler-ca.com> wrote:
>
> Add a parameter lsmid to security_lsmblob_to_secctx() to identify which
> of the security modules that may be active should provide the security
> context. If the value of lsmid is LSM_ID_UNDEF the first LSM providing
> a hook is used. security_secid_to_secctx() is unchanged, and will
> always report the first LSM providing a hook.
>
> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
> ---
> include/linux/security.h | 6 ++++--
> kernel/audit.c | 4 ++--
> kernel/auditsc.c | 8 +++++---
> net/netlabel/netlabel_user.c | 3 ++-
> security/security.c | 18 ++++++++++++++++--
> 5 files changed, 29 insertions(+), 10 deletions(-)
Merged into audit/dev, thanks.
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH v6 1/4] Audit: Create audit_stamp structure
From: Paul Moore @ 2025-08-30 14:14 UTC (permalink / raw)
To: Casey Schaufler, casey, eparis, linux-security-module, audit
Cc: jmorris, serge, keescook, john.johansen, penguin-kernel,
stephen.smalley.work, linux-kernel, selinux
In-Reply-To: <20250816172859.6437-2-casey@schaufler-ca.com>
On Aug 16, 2025 Casey Schaufler <casey@schaufler-ca.com> wrote:
>
> Replace the timestamp and serial number pair used in audit records
> with a structure containing the two elements.
>
> Signed-off-by: Casey Schaufler <casey@schaufler-ca.com>
> ---
> kernel/audit.c | 17 +++++++++--------
> kernel/audit.h | 13 +++++++++----
> kernel/auditsc.c | 22 +++++++++-------------
> 3 files changed, 27 insertions(+), 25 deletions(-)
Merged into audit/dev, thanks.
--
paul-moore.com
^ permalink raw reply
* [RFC PATCH] selftests/landlock: Support running the full fs test suite on another FS
From: Tingmao Wang @ 2025-08-30 3:47 UTC (permalink / raw)
To: Mickaël Salaün, Günther Noack
Cc: Tingmao Wang, linux-security-module, Mikhail Ivanov, Jann Horn
Adds a TMP_BIND_TO environment variable which the test binary will check,
and if present, instead of mounting a tmpfs on ./tmp, it will bind mount
that path to ./tmp instead.
Currently there is the layout3_fs tests which runs a few tests (but not
the full set of Landlock tests) in separate filesystems, notably no file
creation/write/rename etc. This is necessary for certain special fs such
as proc or sysfs, as the tests can only read a specific path. However,
for a more typical fs like v9fs, this is limitting.
This test makes it possible to run the full set on any filesystem (even
though this is still not automated). Note that there are some expected
failures, such as v9fs not supporting RENAME_EXCHANGE, as well as the
known issue of ephemeral inodes, which may be fixed by a later revision of
[1].
Suggestions for alternatives welcome. Maybe we need to also detect the
fs, and disable known-unsupported tests like RENAME_EXCHANGE?
Link: https://lore.kernel.org/v9fs/cover.1743971855.git.m@maowtm.org/ [1]
Signed-off-by: Tingmao Wang <m@maowtm.org>
---
tools/testing/selftests/landlock/fs_test.c | 20 +++++++++++++++++++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/landlock/fs_test.c b/tools/testing/selftests/landlock/fs_test.c
index fa0f18ec62c4..847be67fff9e 100644
--- a/tools/testing/selftests/landlock/fs_test.c
+++ b/tools/testing/selftests/landlock/fs_test.c
@@ -285,6 +285,22 @@ static const struct mnt_opt mnt_tmp = {
.data = MNT_TMP_DATA,
};
+static struct mnt_opt get_tmp_mnt_opt(void)
+{
+ const char *const tmp_bind_to = getenv("TMP_BIND_TO");
+
+ if (tmp_bind_to) {
+ struct mnt_opt mnt = {
+ .flags = MS_BIND,
+ .source = tmp_bind_to
+ };
+
+ return mnt;
+ }
+
+ return mnt_tmp;
+}
+
static int mount_opt(const struct mnt_opt *const mnt, const char *const target)
{
return mount(mnt->source ?: mnt->type, target, mnt->type, mnt->flags,
@@ -322,7 +338,9 @@ static void prepare_layout_opt(struct __test_metadata *const _metadata,
static void prepare_layout(struct __test_metadata *const _metadata)
{
- prepare_layout_opt(_metadata, &mnt_tmp);
+ struct mnt_opt mnt = get_tmp_mnt_opt();
+
+ prepare_layout_opt(_metadata, &mnt);
}
static void cleanup_layout(struct __test_metadata *const _metadata)
base-commit: 1b237f190eb3d36f52dffe07a40b5eb210280e00
--
2.51.0
^ permalink raw reply related
* Re: [PATCH 2/2] selftests: Replace relative includes with non-relative for kselftest.h and kselftest_harness.h
From: Wei Yang @ 2025-08-30 0:55 UTC (permalink / raw)
To: Bala-Vignesh-Reddy
Cc: richard.weiyang, Liam.Howlett, akpm, davem, david, edumazet,
gnoack, horms, kuba, linux-kernel, linux-kselftest, linux-mm,
linux-security-module, lorenzo.stoakes, mhocko, mic, ming.lei,
pabeni, rppt, shuah, skhan, surenb, vbabka
In-Reply-To: <20250829105306.6638-1-reddybalavignesh9979@gmail.com>
On Fri, Aug 29, 2025 at 04:23:06PM +0530, Bala-Vignesh-Reddy wrote:
>
>>+ifeq ($(KSFT_INCLUDES),)
>>+KSFT_INCLUDES := -I../
>>+endif
>>+
>
>This makes sense, but if we do it for mm/ then we have to
>follow this for all subdirectories in selftests.. that might
>cause problems if subdirectories are nested ones likes filesystems/.
>Duplicating this across all subdir Makefile adds churn and can
>lead to errors.
>
>Another way, is adding `CFLAGS += -I../` as is done in net/Makefile,
>but this also doesn't solve the problem completely as this also
>remain to relative addressing.
>
>But, if preferred we can add this snippet in Makefile to
>resolve the error temporarily.
Well, maybe I find a way.
Since we already get the top_srcdir in lib.mk, sounds we can add the include
path directly in lib.mk.
Some quick build looks good, not fully tested.
diff --git a/tools/testing/selftests/lib.mk b/tools/testing/selftests/lib.mk
index 530390033929..1d3d0ad037d7 100644
--- a/tools/testing/selftests/lib.mk
+++ b/tools/testing/selftests/lib.mk
@@ -199,11 +199,18 @@ clean: $(if $(TEST_GEN_MODS_DIR),clean_mods_dir)
# Build with _GNU_SOURCE by default
CFLAGS += -D_GNU_SOURCE=
+CFLAGS += -I${top_srcdir}/tools/testing/selftests
+
# Enables to extend CFLAGS and LDFLAGS from command line, e.g.
# make USERCFLAGS=-Werror USERLDFLAGS=-static
CFLAGS += $(USERCFLAGS)
LDFLAGS += $(USERLDFLAGS)
>
>Thanks,
>Bala Vignesh
--
Wei Yang
Help you, Help me
^ permalink raw reply related
* Re: [PATCH] memfd,selinux: call security_inode_init_security_anon
From: Paul Moore @ 2025-08-29 10:56 UTC (permalink / raw)
To: Stephen Smalley
Cc: Thiébaud Weksteen, James Morris, Hugh Dickins,
Jeff Vander Stoep, Nick Kralevich, Jeff Xu, linux-kernel,
linux-security-module, selinux, linux-mm
In-Reply-To: <CAEjxPJ70O5SY=XYJKrQDLkHOO3spD4VSjYCv0LkhYKCvK=GP7Q@mail.gmail.com>
On Thu, Aug 28, 2025 at 9:30 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
> On Wed, Aug 27, 2025 at 9:23 AM Stephen Smalley
> <stephen.smalley.work@gmail.com> wrote:
> > On Mon, Aug 25, 2025 at 11:18 PM Thiébaud Weksteen <tweek@google.com> wrote:
> > >
> > > Prior to this change, no security hooks were called at the creation of a
> > > memfd file. It means that, for SELinux as an example, it will receive
> > > the default type of the filesystem that backs the in-memory inode ...
>
> Also, we'll need a corresponding patch to define the new policy
> capability in libsepol, and will need to de-conflict with the other
> pending patches that are also trying to claim the next available
> policy capability bit (so you may end up with a different one
> upstream).
My apologies for the late reply, I have limited network access this
week and haven't yet been able to give this a proper review, but I
expect things to get back to normal next week. That said, Stephen's
comments about a test suite addition are important, and I would like
to see a test addition before merging this code both to ensure this
works on a wider range of SELinux based systems beyond Android (you
should also test this on something other than Android, e.g. a modern
Fedora system) and to provide a reliable test that we can use to test
for regressions in the future.
As far as the policy capability bit offset is concerned, don't worry
too much about that right now. Allocated magic numbers like the
policy capability bits are never really fixed until they land in an
upstream tree (technically not until they land in a proper tagged
release from Linus); if/when a patch is merged that requires a new
capability bit I simply assign it the next unused offset at the time
the patch is merged. Other approaches either end up potentially
creating holes in the capability bitmap (yuck) or creating merge
dependencies between otherwise independent pact{sets} (extra double
yuck).
--
paul-moore.com
^ permalink raw reply
* Re: [PATCH 2/2] selftests: Replace relative includes with non-relative for kselftest.h and kselftest_harness.h
From: Bala-Vignesh-Reddy @ 2025-08-29 10:53 UTC (permalink / raw)
To: richard.weiyang
Cc: Liam.Howlett, akpm, davem, david, edumazet, gnoack, horms, kuba,
linux-kernel, linux-kselftest, linux-mm, linux-security-module,
lorenzo.stoakes, mhocko, mic, ming.lei, pabeni,
reddybalavignesh9979, rppt, shuah, skhan, surenb, vbabka
In-Reply-To: <20250829014358.qk3zme4qlaojun53@master>
>+ifeq ($(KSFT_INCLUDES),)
>+KSFT_INCLUDES := -I../
>+endif
>+
This makes sense, but if we do it for mm/ then we have to
follow this for all subdirectories in selftests.. that might
cause problems if subdirectories are nested ones likes filesystems/.
Duplicating this across all subdir Makefile adds churn and can
lead to errors.
Another way, is adding `CFLAGS += -I../` as is done in net/Makefile,
but this also doesn't solve the problem completely as this also
remain to relative addressing.
But, if preferred we can add this snippet in Makefile to
resolve the error temporarily.
Thanks,
Bala Vignesh
^ permalink raw reply
* Re: [PATCH] fs: Replace offsetof() with struct_size() in ioctl_file_dedupe_range()
From: Christian Brauner @ 2025-08-29 10:01 UTC (permalink / raw)
To: Xichao Zhao
Cc: Christian Brauner, jack, gnoack, linux-fsdevel,
linux-security-module, linux-kernel, viro, mic
In-Reply-To: <20250829091510.597858-1-zhao.xichao@vivo.com>
On Fri, 29 Aug 2025 17:15:10 +0800, Xichao Zhao wrote:
> When dealing with structures containing flexible arrays, struct_size()
> provides additional compile-time checks compared to offsetof(). This
> enhances code robustness and reduces the risk of potential errors.
>
>
Applied to the vfs-6.18.misc branch of the vfs/vfs.git tree.
Patches in the vfs-6.18.misc branch should appear in linux-next soon.
Please report any outstanding bugs that were missed during review in a
new review to the original patch series allowing us to drop it.
It's encouraged to provide Acked-bys and Reviewed-bys even though the
patch has now been applied. If possible patch trailers will be updated.
Note that commit hashes shown below are subject to change due to rebase,
trailer updates or similar. If in doubt, please check the listed branch.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs.git
branch: vfs-6.18.misc
[1/1] fs: Replace offsetof() with struct_size() in ioctl_file_dedupe_range()
https://git.kernel.org/vfs/vfs/c/38d1227fa71d
^ permalink raw reply
* Re: [PATCH] fs: Replace offsetof() with struct_size() in ioctl_file_dedupe_range()
From: Jan Kara @ 2025-08-29 9:27 UTC (permalink / raw)
To: Xichao Zhao
Cc: viro, brauner, mic, jack, gnoack, linux-fsdevel,
linux-security-module, linux-kernel
In-Reply-To: <20250829091510.597858-1-zhao.xichao@vivo.com>
On Fri 29-08-25 17:15:10, Xichao Zhao wrote:
> When dealing with structures containing flexible arrays, struct_size()
> provides additional compile-time checks compared to offsetof(). This
> enhances code robustness and reduces the risk of potential errors.
>
> Signed-off-by: Xichao Zhao <zhao.xichao@vivo.com>
Indeed. Also with struct_size() it is more obvious what was the intention.
Feel free to add:
Reviewed-by: Jan Kara <jack@suse.cz>
Honza
> ---
> fs/ioctl.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/ioctl.c b/fs/ioctl.c
> index 0248cb8db2d3..83d07218b6cd 100644
> --- a/fs/ioctl.c
> +++ b/fs/ioctl.c
> @@ -426,7 +426,7 @@ static int ioctl_file_dedupe_range(struct file *file,
> goto out;
> }
>
> - size = offsetof(struct file_dedupe_range, info[count]);
> + size = struct_size(same, info, count);
> if (size > PAGE_SIZE) {
> ret = -ENOMEM;
> goto out;
> --
> 2.34.1
>
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
^ permalink raw reply
* [PATCH] fs: Replace offsetof() with struct_size() in ioctl_file_dedupe_range()
From: Xichao Zhao @ 2025-08-29 9:15 UTC (permalink / raw)
To: viro, brauner, mic
Cc: jack, gnoack, linux-fsdevel, linux-security-module, linux-kernel,
Xichao Zhao
When dealing with structures containing flexible arrays, struct_size()
provides additional compile-time checks compared to offsetof(). This
enhances code robustness and reduces the risk of potential errors.
Signed-off-by: Xichao Zhao <zhao.xichao@vivo.com>
---
fs/ioctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/ioctl.c b/fs/ioctl.c
index 0248cb8db2d3..83d07218b6cd 100644
--- a/fs/ioctl.c
+++ b/fs/ioctl.c
@@ -426,7 +426,7 @@ static int ioctl_file_dedupe_range(struct file *file,
goto out;
}
- size = offsetof(struct file_dedupe_range, info[count]);
+ size = struct_size(same, info, count);
if (size > PAGE_SIZE) {
ret = -ENOMEM;
goto out;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] memfd,selinux: call security_inode_init_security_anon
From: Thiébaud Weksteen @ 2025-08-29 3:17 UTC (permalink / raw)
To: Stephen Smalley
Cc: Paul Moore, James Morris, Hugh Dickins, Jeff Vander Stoep,
Nick Kralevich, Jeff Xu, linux-kernel, linux-security-module,
selinux, linux-mm
In-Reply-To: <CAEjxPJ70O5SY=XYJKrQDLkHOO3spD4VSjYCv0LkhYKCvK=GP7Q@mail.gmail.com>
On Thu, Aug 28, 2025 at 11:30 PM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>
> On Wed, Aug 27, 2025 at 9:23 AM Stephen Smalley
> <stephen.smalley.work@gmail.com> wrote:
> >
> > On Mon, Aug 25, 2025 at 11:18 PM Thiébaud Weksteen <tweek@google.com> wrote:
> > >
> > > Prior to this change, no security hooks were called at the creation of a
> > > memfd file. It means that, for SELinux as an example, it will receive
> > > the default type of the filesystem that backs the in-memory inode. In
> > > most cases, that would be tmpfs, but if MFD_HUGETLB is passed, it will
> > > be hugetlbfs. Both can be considered implementation details of memfd.
> > >
> > > It also means that it is not possible to differentiate between a file
> > > coming from memfd_create and a file coming from a standard tmpfs mount
> > > point.
> > >
> > > Additionally, no permission is validated at creation, which differs from
> > > the similar memfd_secret syscall.
> > >
> > > Call security_inode_init_security_anon during creation. This ensures
> > > that the file is setup similarly to other anonymous inodes. On SELinux,
> > > it means that the file will receive the security context of its task.
> > >
> > > The ability to limit fexecve on memfd has been of interest to avoid
> > > potential pitfalls where /proc/self/exe or similar would be executed
> > > [1][2]. Reuse the "execute_no_trans" and "entrypoint" access vectors,
> > > similarly to the file class. These access vectors may not make sense for
> > > the existing "anon_inode" class. Therefore, define and assign a new
> > > class "memfd_file" to support such access vectors.
> > >
> > > Guard these changes behind a new policy capability named "memfd_class".
> > >
> > > [1] https://crbug.com/1305267
> > > [2] https://lore.kernel.org/lkml/20221215001205.51969-1-jeffxu@google.com/
> > >
> > > Signed-off-by: Thiébaud Weksteen <tweek@google.com>
> >
> > This looks good to me, but do you have a test for it, preferably via
> > patch for the selinux-testsuite?
> > See https://github.com/SELinuxProject/selinux-testsuite/commit/023b79b8319e5fe222fb5af892c579593e1cbc50
> > for an example.
Not yet, I only tested internally on Android. Let me get a change
ready for selinux-testsuite.
> >
> > Otherwise, you can add my:
> > Acked-by: Stephen Smalley <stephen.smalley.work@gmail.com>
Thanks for the review!
>
> Also, we'll need a corresponding patch to define the new policy
> capability in libsepol, and will need to de-conflict with the other
> pending patches that are also trying to claim the next available
> policy capability bit (so you may end up with a different one
> upstream).
Ack. Thanks for the heads-up. Happy to rebase the commit if that helps.
^ permalink raw reply
* Re: [PATCH 2/2] selftests: Replace relative includes with non-relative for kselftest.h and kselftest_harness.h
From: Wei Yang @ 2025-08-29 1:43 UTC (permalink / raw)
To: Bala-Vignesh-Reddy
Cc: richard.weiyang, Liam.Howlett, akpm, davem, david, edumazet,
gnoack, horms, kuba, linux-kernel, linux-kselftest, linux-mm,
linux-security-module, lorenzo.stoakes, mhocko, mic, ming.lei,
pabeni, rppt, shuah, skhan, surenb, vbabka
In-Reply-To: <20250828094016.18063-1-reddybalavignesh9979@gmail.com>
On Thu, Aug 28, 2025 at 03:10:16PM +0530, Bala-Vignesh-Reddy wrote:
>Hi Wei,
>
>Thanks for testing and for your feedback.
>
>Yeah, if you try to build inside a subdirectory, the top level
>export may not apply, so CFLAGS don't get updated, and even if
>they did, the path could be pointing to wrong location.
>
>As the docs recommend, building selftest using TARGETS,
>either from kernel source or "tools/testing/selftests/"
>works fine and doesn't fail.
>
But this breaks current behavior. There might be users for this form.
>If you really want to build from selftests/mm/ directory then
>defining KSFT_INCLUDES with a fallback in the Makefile will
>resolve it, but there is no need of it if we stick with "TARGETS=mm".
>
How about add this in local Makefile ?
For example:
diff --git a/tools/testing/selftests/mm/Makefile b/tools/testing/selftests/mm/Makefile
index 810bd615b8c3..52f023071619 100644
--- a/tools/testing/selftests/mm/Makefile
+++ b/tools/testing/selftests/mm/Makefile
@@ -158,6 +158,10 @@ TEST_FILES += test_page_frag.sh
# required by charge_reserved_hugetlb.sh
TEST_FILES += write_hugetlb_memory.sh
+ifeq ($(KSFT_INCLUDES),)
+KSFT_INCLUDES := -I../
+endif
+
include ../lib.mk
$(TEST_GEN_PROGS): vm_util.c thp_settings.c
>Thanks
>Bala Vignesh
--
Wei Yang
Help you, Help me
^ permalink raw reply related
* Re: [RFC PATCH v1 0/2] Add O_DENY_WRITE (complement AT_EXECVE_CHECK)
From: Serge E. Hallyn @ 2025-08-28 21:01 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Aleksa Sarai, Mickaël Salaün, Christian Brauner,
Al Viro, Kees Cook, Paul Moore, Serge Hallyn, Arnd Bergmann,
Christian Heimes, Dmitry Vyukov, Elliott Hughes, Fan Wu,
Florian Weimer, Jann Horn, Jeff Xu, Jonathan Corbet,
Jordan R Abrahams, Lakshmi Ramasubramanian, Luca Boccassi,
Matt Bobrowski, Miklos Szeredi, Mimi Zohar, Nicolas Bouchinet,
Robert Waite, Roberto Sassu, Scott Shell, Steve Dower,
Steve Grubb, kernel-hardening, linux-api, linux-fsdevel,
linux-integrity, linux-kernel, linux-security-module
In-Reply-To: <CALCETrWHKga33bvzUHnd-mRQUeNXTtXSS8Y8+40d5bxv-CqBhw@mail.gmail.com>
On Wed, Aug 27, 2025 at 05:32:02PM -0700, Andy Lutomirski wrote:
> On Wed, Aug 27, 2025 at 5:14 PM Aleksa Sarai <cyphar@cyphar.com> wrote:
> >
> > On 2025-08-26, Mickaël Salaün <mic@digikod.net> wrote:
> > > On Tue, Aug 26, 2025 at 11:07:03AM +0200, Christian Brauner wrote:
> > > > Nothing has changed in that regard and I'm not interested in stuffing
> > > > the VFS APIs full of special-purpose behavior to work around the fact
> > > > that this is work that needs to be done in userspace. Change the apps,
> > > > stop pushing more and more cruft into the VFS that has no business
> > > > there.
> > >
> > > It would be interesting to know how to patch user space to get the same
> > > guarantees... Do you think I would propose a kernel patch otherwise?
> >
> > You could mmap the script file with MAP_PRIVATE. This is the *actual*
> > protection the kernel uses against overwriting binaries (yes, ETXTBSY is
> > nice but IIRC there are ways to get around it anyway).
>
> Wait, really? MAP_PRIVATE prevents writes to the mapping from
> affecting the file, but I don't think that writes to the file will
> break the MAP_PRIVATE CoW if it's not already broken.
>
> IPython says:
>
> In [1]: import mmap, tempfile
>
> In [2]: f = tempfile.TemporaryFile()
>
> In [3]: f.write(b'initial contents')
> Out[3]: 16
>
> In [4]: f.flush()
>
> In [5]: map = mmap.mmap(f.fileno(), f.tell(), flags=mmap.MAP_PRIVATE,
> prot=mmap.PROT_READ)
>
> In [6]: map[:]
> Out[6]: b'initial contents'
>
> In [7]: f.seek(0)
> Out[7]: 0
>
> In [8]: f.write(b'changed')
> Out[8]: 7
>
> In [9]: f.flush()
>
> In [10]: map[:]
> Out[10]: b'changed contents'
That was surprising to me, however, if I split the reader
and writer into different processes, so
P1:
f = open("/tmp/3", "w")
f.write('initial contents')
f.flush()
P2:
import mmap
f = open("/tmp/3", "r")
map = mmap.mmap(f.fileno(), f.tell(), flags=mmap.MAP_PRIVATE, prot=mmap.PROT_READ)
Back to P1:
f.seek(0)
f.write('changed')
Back to P2:
map[:]
Then P2 gives me:
b'initial contents'
-serge
^ permalink raw reply
* Re: [RFC PATCH v1 1/2] fs: Add O_DENY_WRITE
From: Jeff Xu @ 2025-08-28 20:17 UTC (permalink / raw)
To: Mickaël Salaün
Cc: Jeff Xu, Andy Lutomirski, Jann Horn, Al Viro, Christian Brauner,
Kees Cook, Paul Moore, Serge Hallyn, Andy Lutomirski,
Arnd Bergmann, Christian Heimes, Dmitry Vyukov, Elliott Hughes,
Fan Wu, Florian Weimer, Jonathan Corbet, Jordan R Abrahams,
Lakshmi Ramasubramanian, Luca Boccassi, Matt Bobrowski,
Miklos Szeredi, Mimi Zohar, Nicolas Bouchinet, Robert Waite,
Roberto Sassu, Scott Shell, Steve Dower, Steve Grubb,
kernel-hardening, linux-api, linux-fsdevel, linux-integrity,
linux-kernel, linux-security-module
In-Reply-To: <20250827.ieRaeNg4pah3@digikod.net>
Hi Mickaël
On Wed, Aug 27, 2025 at 1:19 AM Mickaël Salaün <mic@digikod.net> wrote:
>
> On Tue, Aug 26, 2025 at 01:29:55PM -0700, Jeff Xu wrote:
> > Hi Mickaël
> >
> > On Tue, Aug 26, 2025 at 5:39 AM Mickaël Salaün <mic@digikod.net> wrote:
> > >
> > > On Mon, Aug 25, 2025 at 10:57:57AM -0700, Jeff Xu wrote:
> > > > Hi Mickaël
> > > >
> > > > On Mon, Aug 25, 2025 at 2:31 AM Mickaël Salaün <mic@digikod.net> wrote:
> > > > >
> > > > > On Sun, Aug 24, 2025 at 11:04:03AM -0700, Andy Lutomirski wrote:
> > > > > > On Sun, Aug 24, 2025 at 4:03 AM Mickaël Salaün <mic@digikod.net> wrote:
> > > > > > >
> > > > > > > On Fri, Aug 22, 2025 at 09:45:32PM +0200, Jann Horn wrote:
> > > > > > > > On Fri, Aug 22, 2025 at 7:08 PM Mickaël Salaün <mic@digikod.net> wrote:
> > > > > > > > > Add a new O_DENY_WRITE flag usable at open time and on opened file (e.g.
> > > > > > > > > passed file descriptors). This changes the state of the opened file by
> > > > > > > > > making it read-only until it is closed. The main use case is for script
> > > > > > > > > interpreters to get the guarantee that script' content cannot be altered
> > > > > > > > > while being read and interpreted. This is useful for generic distros
> > > > > > > > > that may not have a write-xor-execute policy. See commit a5874fde3c08
> > > > > > > > > ("exec: Add a new AT_EXECVE_CHECK flag to execveat(2)")
> > > > > > > > >
> > > > > > > > > Both execve(2) and the IOCTL to enable fsverity can already set this
> > > > > > > > > property on files with deny_write_access(). This new O_DENY_WRITE make
> > > > > > > >
> > > > > > > > The kernel actually tried to get rid of this behavior on execve() in
> > > > > > > > commit 2a010c41285345da60cece35575b4e0af7e7bf44.; but sadly that had
> > > > > > > > to be reverted in commit 3b832035387ff508fdcf0fba66701afc78f79e3d
> > > > > > > > because it broke userspace assumptions.
> > > > > > >
> > > > > > > Oh, good to know.
> > > > > > >
> > > > > > > >
> > > > > > > > > it widely available. This is similar to what other OSs may provide
> > > > > > > > > e.g., opening a file with only FILE_SHARE_READ on Windows.
> > > > > > > >
> > > > > > > > We used to have the analogous mmap() flag MAP_DENYWRITE, and that was
> > > > > > > > removed for security reasons; as
> > > > > > > > https://man7.org/linux/man-pages/man2/mmap.2.html says:
> > > > > > > >
> > > > > > > > | MAP_DENYWRITE
> > > > > > > > | This flag is ignored. (Long ago—Linux 2.0 and earlier—it
> > > > > > > > | signaled that attempts to write to the underlying file
> > > > > > > > | should fail with ETXTBSY. But this was a source of denial-
> > > > > > > > | of-service attacks.)"
> > > > > > > >
> > > > > > > > It seems to me that the same issue applies to your patch - it would
> > > > > > > > allow unprivileged processes to essentially lock files such that other
> > > > > > > > processes can't write to them anymore. This might allow unprivileged
> > > > > > > > users to prevent root from updating config files or stuff like that if
> > > > > > > > they're updated in-place.
> > > > > > >
> > > > > > > Yes, I agree, but since it is the case for executed files I though it
> > > > > > > was worth starting a discussion on this topic. This new flag could be
> > > > > > > restricted to executable files, but we should avoid system-wide locks
> > > > > > > like this. I'm not sure how Windows handle these issues though.
> > > > > > >
> > > > > > > Anyway, we should rely on the access control policy to control write and
> > > > > > > execute access in a consistent way (e.g. write-xor-execute). Thanks for
> > > > > > > the references and the background!
> > > > > >
> > > > > > I'm confused. I understand that there are many contexts in which one
> > > > > > would want to prevent execution of unapproved content, which might
> > > > > > include preventing a given process from modifying some code and then
> > > > > > executing it.
> > > > > >
> > > > > > I don't understand what these deny-write features have to do with it.
> > > > > > These features merely prevent someone from modifying code *that is
> > > > > > currently in use*, which is not at all the same thing as preventing
> > > > > > modifying code that might get executed -- one can often modify
> > > > > > contents *before* executing those contents.
> > > > >
> > > > > The order of checks would be:
> > > > > 1. open script with O_DENY_WRITE
> > > > > 2. check executability with AT_EXECVE_CHECK
> > > > > 3. read the content and interpret it
> > > > >
> > > > I'm not sure about the O_DENY_WRITE approach, but the problem is worth solving.
> > > >
> > > > AT_EXECVE_CHECK is not just for scripting languages. It could also
> > > > work with bytecodes like Java, for example. If we let the Java runtime
> > > > call AT_EXECVE_CHECK before loading the bytecode, the LSM could
> > > > develop a policy based on that.
> > >
> > > Sure, I'm using "script" to make it simple, but this applies to other
> > > use cases.
> > >
> > That makes sense.
> >
> > > >
> > > > > The deny-write feature was to guarantee that there is no race condition
> > > > > between step 2 and 3. All these checks are supposed to be done by a
> > > > > trusted interpreter (which is allowed to be executed). The
> > > > > AT_EXECVE_CHECK call enables the caller to know if the kernel (and
> > > > > associated security policies) allowed the *current* content of the file
> > > > > to be executed. Whatever happen before or after that (wrt.
> > > > > O_DENY_WRITE) should be covered by the security policy.
> > > > >
> > > > Agree, the race problem needs to be solved in order for AT_EXECVE_CHECK.
> > > >
> > > > Enforcing non-write for the path that stores scripts or bytecodes can
> > > > be challenging due to historical or backward compatibility reasons.
> > > > Since AT_EXECVE_CHECK provides a mechanism to check the file right
> > > > before it is used, we can assume it will detect any "problem" that
> > > > happened before that, (e.g. the file was overwritten). However, that
> > > > also imposes two additional requirements:
> > > > 1> the file doesn't change while AT_EXECVE_CHECK does the check.
> > >
> > > This is already the case, so any kind of LSM checks are good.
> > >
> > May I ask how this is done? some code in do_open_execat() does this ?
> > Apologies if this is a basic question.
>
> do_open_execat() calls exe_file_deny_write_access()
>
Thanks for pointing.
With that, now I read the full history of discussion regarding this :-)
> >
> > > > 2>The file content kept by the process remains unchanged after passing
> > > > the AT_EXECVE_CHECK.
> > >
> > > The goal of this patch was to avoid such race condition in the case
> > > where executable files can be updated. But in most cases it should not
> > > be a security issue (because processes allowed to write to executable
> > > files should be trusted), but this could still lead to bugs (because of
> > > inconsistent file content, half-updated).
> > >
> > There is also a time gap between:
> > a> the time of AT_EXECVE_CHECK
> > b> the time that the app opens the file for execution.
> > right ? another potential attack path (though this is not the case I
> > mentioned previously).
>
> As explained in the documentation, to avoid this specific race
> condition, interpreters should open the script once, check the FD with
> AT_EXECVE_CHECK, and then read the content with the same FD.
>
Ya, now I see that in the description of this patch, sorry that I
missed that previously.
> >
> > For the case I mentioned previously, I have to think more if the race
> > condition is a bug or security issue.
> > IIUC, two solutions are discussed so far:
> > 1> the process could write to fs to update the script. However, for
> > execution, the process still uses the copy that passed the
> > AT_EXECVE_CHECK. (snapshot solution by Andy Lutomirski)
>
> Yes, the snapshot solution would be the best, but I guess it would rely
> on filesystems to support this feature.
>
snapshot seems to be the reasonable direction to go
Is this something related to the VMA ? e.g. preserve the in-memory
copy of the file when the file on fs was updated.
According to man mmap:
MAP_PRIVATE
Create a private copy-on-write mapping. Updates to the
mapping are not visible to other processes mapping the same
file, and are not carried through to the underlying file.
It is unspecified whether changes made to the file after
the mmap() call are visible in the mapped region.
so the direction here is
the process -> update the vma -> doesn't carry to the file.
What we want is the reverse direction: (the unspecified part in the man page)
file updated on fs -> doesn't carry to the vma of this process.
> > or 2> the process blocks the write while opening the file as read only
> > and executing the script. (this seems to be the approach of this
> > patch).
>
> Yes, and this is not something we want anymore.
>
right. Thank you for clarifying this.
> >
> > I wonder if there are other ideas.
>
> I don't see other efficient ways to give the same guarantees.
right, me neither.
Thanks and regards,
-Jeff
^ permalink raw reply
* Re: [PATCH] memfd,selinux: call security_inode_init_security_anon
From: Stephen Smalley @ 2025-08-28 13:29 UTC (permalink / raw)
To: Thiébaud Weksteen
Cc: Paul Moore, James Morris, Hugh Dickins, Jeff Vander Stoep,
Nick Kralevich, Jeff Xu, linux-kernel, linux-security-module,
selinux, linux-mm
In-Reply-To: <CAEjxPJ6G2iK9Yp8eCwbwHQfF1J3WBEVU42kAMQHNuuC_H5QHNw@mail.gmail.com>
On Wed, Aug 27, 2025 at 9:23 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>
> On Mon, Aug 25, 2025 at 11:18 PM Thiébaud Weksteen <tweek@google.com> wrote:
> >
> > Prior to this change, no security hooks were called at the creation of a
> > memfd file. It means that, for SELinux as an example, it will receive
> > the default type of the filesystem that backs the in-memory inode. In
> > most cases, that would be tmpfs, but if MFD_HUGETLB is passed, it will
> > be hugetlbfs. Both can be considered implementation details of memfd.
> >
> > It also means that it is not possible to differentiate between a file
> > coming from memfd_create and a file coming from a standard tmpfs mount
> > point.
> >
> > Additionally, no permission is validated at creation, which differs from
> > the similar memfd_secret syscall.
> >
> > Call security_inode_init_security_anon during creation. This ensures
> > that the file is setup similarly to other anonymous inodes. On SELinux,
> > it means that the file will receive the security context of its task.
> >
> > The ability to limit fexecve on memfd has been of interest to avoid
> > potential pitfalls where /proc/self/exe or similar would be executed
> > [1][2]. Reuse the "execute_no_trans" and "entrypoint" access vectors,
> > similarly to the file class. These access vectors may not make sense for
> > the existing "anon_inode" class. Therefore, define and assign a new
> > class "memfd_file" to support such access vectors.
> >
> > Guard these changes behind a new policy capability named "memfd_class".
> >
> > [1] https://crbug.com/1305267
> > [2] https://lore.kernel.org/lkml/20221215001205.51969-1-jeffxu@google.com/
> >
> > Signed-off-by: Thiébaud Weksteen <tweek@google.com>
>
> This looks good to me, but do you have a test for it, preferably via
> patch for the selinux-testsuite?
> See https://github.com/SELinuxProject/selinux-testsuite/commit/023b79b8319e5fe222fb5af892c579593e1cbc50
> for an example.
>
> Otherwise, you can add my:
> Acked-by: Stephen Smalley <stephen.smalley.work@gmail.com>
Also, we'll need a corresponding patch to define the new policy
capability in libsepol, and will need to de-conflict with the other
pending patches that are also trying to claim the next available
policy capability bit (so you may end up with a different one
upstream).
>
> > ---
> > Changes since RFC:
> > - Remove enum argument, simply compare the anon inode name
> > - Introduce a policy capability for compatility
> > - Add validation of class in selinux_bprm_creds_for_exec
> >
> > include/linux/memfd.h | 2 ++
> > mm/memfd.c | 14 +++++++++--
> > security/selinux/hooks.c | 27 ++++++++++++++++++----
> > security/selinux/include/classmap.h | 2 ++
> > security/selinux/include/policycap.h | 1 +
> > security/selinux/include/policycap_names.h | 1 +
> > security/selinux/include/security.h | 5 ++++
> > 7 files changed, 46 insertions(+), 6 deletions(-)
> >
> > diff --git a/include/linux/memfd.h b/include/linux/memfd.h
> > index 6f606d9573c3..cc74de3dbcfe 100644
> > --- a/include/linux/memfd.h
> > +++ b/include/linux/memfd.h
> > @@ -4,6 +4,8 @@
> >
> > #include <linux/file.h>
> >
> > +#define MEMFD_ANON_NAME "[memfd]"
> > +
> > #ifdef CONFIG_MEMFD_CREATE
> > extern long memfd_fcntl(struct file *file, unsigned int cmd, unsigned int arg);
> > struct folio *memfd_alloc_folio(struct file *memfd, pgoff_t idx);
> > diff --git a/mm/memfd.c b/mm/memfd.c
> > index bbe679895ef6..63b439eb402a 100644
> > --- a/mm/memfd.c
> > +++ b/mm/memfd.c
> > @@ -433,6 +433,8 @@ static struct file *alloc_file(const char *name, unsigned int flags)
> > {
> > unsigned int *file_seals;
> > struct file *file;
> > + struct inode *inode;
> > + int err = 0;
> >
> > if (flags & MFD_HUGETLB) {
> > file = hugetlb_file_setup(name, 0, VM_NORESERVE,
> > @@ -444,12 +446,20 @@ static struct file *alloc_file(const char *name, unsigned int flags)
> > }
> > if (IS_ERR(file))
> > return file;
> > +
> > + inode = file_inode(file);
> > + err = security_inode_init_security_anon(inode,
> > + &QSTR(MEMFD_ANON_NAME), NULL);
> > + if (err) {
> > + fput(file);
> > + file = ERR_PTR(err);
> > + return file;
> > + }
> > +
> > file->f_mode |= FMODE_LSEEK | FMODE_PREAD | FMODE_PWRITE;
> > file->f_flags |= O_LARGEFILE;
> >
> > if (flags & MFD_NOEXEC_SEAL) {
> > - struct inode *inode = file_inode(file);
> > -
> > inode->i_mode &= ~0111;
> > file_seals = memfd_file_seals_ptr(file);
> > if (file_seals) {
> > diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
> > index c95a5874bf7d..429b2269b35a 100644
> > --- a/security/selinux/hooks.c
> > +++ b/security/selinux/hooks.c
> > @@ -93,6 +93,7 @@
> > #include <linux/fanotify.h>
> > #include <linux/io_uring/cmd.h>
> > #include <uapi/linux/lsm.h>
> > +#include <linux/memfd.h>
> >
> > #include "avc.h"
> > #include "objsec.h"
> > @@ -2366,9 +2367,12 @@ static int selinux_bprm_creds_for_exec(struct linux_binprm *bprm)
> > ad.type = LSM_AUDIT_DATA_FILE;
> > ad.u.file = bprm->file;
> >
> > + if (isec->sclass != SECCLASS_FILE && isec->sclass != SECCLASS_MEMFD_FILE)
> > + return -EPERM;
> > +
> > if (new_tsec->sid == old_tsec->sid) {
> > - rc = avc_has_perm(old_tsec->sid, isec->sid,
> > - SECCLASS_FILE, FILE__EXECUTE_NO_TRANS, &ad);
> > + rc = avc_has_perm(old_tsec->sid, isec->sid, isec->sclass,
> > + FILE__EXECUTE_NO_TRANS, &ad);
> > if (rc)
> > return rc;
> > } else {
> > @@ -2378,8 +2382,8 @@ static int selinux_bprm_creds_for_exec(struct linux_binprm *bprm)
> > if (rc)
> > return rc;
> >
> > - rc = avc_has_perm(new_tsec->sid, isec->sid,
> > - SECCLASS_FILE, FILE__ENTRYPOINT, &ad);
> > + rc = avc_has_perm(new_tsec->sid, isec->sid, isec->sclass,
> > + FILE__ENTRYPOINT, &ad);
> > if (rc)
> > return rc;
> >
> > @@ -2974,10 +2978,18 @@ static int selinux_inode_init_security_anon(struct inode *inode,
> > struct common_audit_data ad;
> > struct inode_security_struct *isec;
> > int rc;
> > + bool is_memfd = false;
> >
> > if (unlikely(!selinux_initialized()))
> > return 0;
> >
> > + if (name != NULL && name->name != NULL &&
> > + !strcmp(name->name, MEMFD_ANON_NAME)) {
> > + if (!selinux_policycap_memfd_class())
> > + return 0;
> > + is_memfd = true;
> > + }
> > +
> > isec = selinux_inode(inode);
> >
> > /*
> > @@ -2996,6 +3008,13 @@ static int selinux_inode_init_security_anon(struct inode *inode,
> >
> > isec->sclass = context_isec->sclass;
> > isec->sid = context_isec->sid;
> > + } else if (is_memfd) {
> > + isec->sclass = SECCLASS_MEMFD_FILE;
> > + rc = security_transition_sid(
> > + sid, sid,
> > + isec->sclass, name, &isec->sid);
> > + if (rc)
> > + return rc;
> > } else {
> > isec->sclass = SECCLASS_ANON_INODE;
> > rc = security_transition_sid(
> > diff --git a/security/selinux/include/classmap.h b/security/selinux/include/classmap.h
> > index 5665aa5e7853..3ec85142771f 100644
> > --- a/security/selinux/include/classmap.h
> > +++ b/security/selinux/include/classmap.h
> > @@ -179,6 +179,8 @@ const struct security_class_mapping secclass_map[] = {
> > { "anon_inode", { COMMON_FILE_PERMS, NULL } },
> > { "io_uring", { "override_creds", "sqpoll", "cmd", "allowed", NULL } },
> > { "user_namespace", { "create", NULL } },
> > + { "memfd_file",
> > + { COMMON_FILE_PERMS, "execute_no_trans", "entrypoint", NULL } },
> > /* last one */ { NULL, {} }
> > };
> >
> > diff --git a/security/selinux/include/policycap.h b/security/selinux/include/policycap.h
> > index 7405154e6c42..dabcc9f14dde 100644
> > --- a/security/selinux/include/policycap.h
> > +++ b/security/selinux/include/policycap.h
> > @@ -17,6 +17,7 @@ enum {
> > POLICYDB_CAP_NETLINK_XPERM,
> > POLICYDB_CAP_NETIF_WILDCARD,
> > POLICYDB_CAP_GENFS_SECLABEL_WILDCARD,
> > + POLICYDB_CAP_MEMFD_CLASS,
> > __POLICYDB_CAP_MAX
> > };
> > #define POLICYDB_CAP_MAX (__POLICYDB_CAP_MAX - 1)
> > diff --git a/security/selinux/include/policycap_names.h b/security/selinux/include/policycap_names.h
> > index d8962fcf2ff9..8e96f2a816b6 100644
> > --- a/security/selinux/include/policycap_names.h
> > +++ b/security/selinux/include/policycap_names.h
> > @@ -20,6 +20,7 @@ const char *const selinux_policycap_names[__POLICYDB_CAP_MAX] = {
> > "netlink_xperm",
> > "netif_wildcard",
> > "genfs_seclabel_wildcard",
> > + "memfd_class",
> > };
> > /* clang-format on */
> >
> > diff --git a/security/selinux/include/security.h b/security/selinux/include/security.h
> > index 8201e6a3ac0f..72c963f54148 100644
> > --- a/security/selinux/include/security.h
> > +++ b/security/selinux/include/security.h
> > @@ -209,6 +209,11 @@ static inline bool selinux_policycap_netif_wildcard(void)
> > selinux_state.policycap[POLICYDB_CAP_NETIF_WILDCARD]);
> > }
> >
> > +static inline bool selinux_policycap_memfd_class(void)
> > +{
> > + return READ_ONCE(selinux_state.policycap[POLICYDB_CAP_MEMFD_CLASS]);
> > +}
> > +
> > struct selinux_policy_convert_data;
> >
> > struct selinux_load_state {
> > --
> > 2.51.0.261.g7ce5a0a67e-goog
> >
^ permalink raw reply
* Re: [PATCH kvm-next V11 0/7] Add NUMA mempolicy support for KVM guest-memfd
From: David Hildenbrand @ 2025-08-28 12:44 UTC (permalink / raw)
To: Shivank Garg, willy, akpm, pbonzini, shuah, seanjc, vbabka
Cc: brauner, viro, dsterba, xiang, chao, jaegeuk, clm, josef,
kent.overstreet, zbestahu, jefflexu, dhavale, lihongbo22,
lorenzo.stoakes, Liam.Howlett, rppt, surenb, mhocko, ziy,
matthew.brost, joshua.hahnjy, rakie.kim, byungchul, gourry,
ying.huang, apopple, tabba, ackerleytng, paul, jmorris, serge,
pvorel, bfoster, vannapurve, chao.gao, bharata, nikunj,
michael.day, shdhiman, yan.y.zhao, Neeraj.Upadhyay,
thomas.lendacky, michael.roth, aik, jgg, kalyazin, peterx, jack,
hch, cgzones, ira.weiny, rientjes, roypat, chao.p.peng, amit,
ddutile, dan.j.williams, ashish.kalra, gshan, jgowans,
pankaj.gupta, papaluri, yuzhao, suzuki.poulose, quic_eberman,
linux-bcachefs, linux-btrfs, linux-erofs, linux-f2fs-devel,
linux-fsdevel, linux-mm, linux-kernel, linux-security-module, kvm,
linux-kselftest, linux-coco
In-Reply-To: <20250827175247.83322-2-shivankg@amd.com>
On 27.08.25 19:52, Shivank Garg wrote:
> This series introduces NUMA-aware memory placement support for KVM guests
> with guest_memfd memory backends. It builds upon Fuad Tabba's work (V17)
> that enabled host-mapping for guest_memfd memory [1] and can be applied
> directly applied on KVM tree [2] (branch kvm-next, base commit: a6ad5413,
> Merge branch 'guest-memfd-mmap' into HEAD)
As discussed, I'll be maintaining a guestmemfd-preview branch where I
just pile patch sets to see how it will all look together. It's
currently based on kvm/next where "stage 1" resides:
https://git.kernel.org/pub/scm/linux/kernel/git/david/linux.git/log/?h=guestmemfd-preview
--
Cheers
David / dhildenb
^ permalink raw reply
* Re: [PATCH kvm-next V11 4/7] KVM: guest_memfd: Use guest mem inodes instead of anonymous inodes
From: David Hildenbrand @ 2025-08-28 10:06 UTC (permalink / raw)
To: Ackerley Tng, Shivank Garg, willy, akpm, pbonzini, shuah, seanjc,
vbabka
Cc: brauner, viro, dsterba, xiang, chao, jaegeuk, clm, josef,
kent.overstreet, zbestahu, jefflexu, dhavale, lihongbo22,
lorenzo.stoakes, Liam.Howlett, rppt, surenb, mhocko, ziy,
matthew.brost, joshua.hahnjy, rakie.kim, byungchul, gourry,
ying.huang, apopple, tabba, paul, jmorris, serge, pvorel, bfoster,
vannapurve, chao.gao, bharata, nikunj, michael.day, shdhiman,
yan.y.zhao, Neeraj.Upadhyay, thomas.lendacky, michael.roth, aik,
jgg, kalyazin, peterx, jack, hch, cgzones, ira.weiny, rientjes,
roypat, chao.p.peng, amit, ddutile, dan.j.williams, ashish.kalra,
gshan, jgowans, pankaj.gupta, papaluri, yuzhao, suzuki.poulose,
quic_eberman, linux-bcachefs, linux-btrfs, linux-erofs,
linux-f2fs-devel, linux-fsdevel, linux-mm, linux-kernel,
linux-security-module, kvm, linux-kselftest, linux-coco
In-Reply-To: <diqztt1sbd2v.fsf@google.com>
On 28.08.25 00:43, Ackerley Tng wrote:
> Shivank Garg <shivankg@amd.com> writes:
>
>>
>> [...snip...]
>>
>
> I meant to send this to you before this version went out but you were
> too quick!
>
> Here's a new version, Fuad and I reviewed this again internally. The
> changes are:
>
> + Sort linux/pseudo_fs.h after linux/pagemap.h (alphabetical)
> + Don't set MNT_NOEXEC on the mount, since SB_I_NOEXEC was already set
> on the superblock
> + Rename kvm_gmem_inode_make_secure_inode() to kvm_gmem_inode_create()
> + Emphasizes that there is a creation in this function
> + Remove "secure" from the function name to remove confusion that
> there may be a "non-secure" version
> + In kvm_gmem_inode_create_getfile()'s error path, return ERR_PTR(err)
> directly instead of having a goto
>
>
> From ada9814b216eac129ed44dffd3acf76fce2cc08a Mon Sep 17 00:00:00 2001
> From: Ackerley Tng <ackerleytng@google.com>
> Date: Sun, 13 Jul 2025 17:43:35 +0000
> Subject: [PATCH] KVM: guest_memfd: Use guest mem inodes instead of anonymous
> inodes
>
> guest_memfd's inode represents memory the guest_memfd is
> providing. guest_memfd's file represents a struct kvm's view of that
> memory.
>
> Using a custom inode allows customization of the inode teardown
> process via callbacks. For example, ->evict_inode() allows
> customization of the truncation process on file close, and
> ->destroy_inode() and ->free_inode() allow customization of the inode
> freeing process.
>
> Customizing the truncation process allows flexibility in management of
> guest_memfd memory and customization of the inode freeing process
> allows proper cleanup of memory metadata stored on the inode.
>
> Memory metadata is more appropriately stored on the inode (as opposed
> to the file), since the metadata is for the memory and is not unique
> to a specific binding and struct kvm.
>
> Co-developed-by: Fuad Tabba <tabba@google.com>
> Signed-off-by: Fuad Tabba <tabba@google.com>
> Signed-off-by: Shivank Garg <shivankg@amd.com>
> Signed-off-by: Ackerley Tng <ackerleytng@google.com>
Acked-by: David Hildenbrand <david@redhat.com>
--
Cheers
David / dhildenb
^ permalink raw reply
* Re: [PATCH 2/2] selftests: Replace relative includes with non-relative for kselftest.h and kselftest_harness.h
From: Bala-Vignesh-Reddy @ 2025-08-28 9:40 UTC (permalink / raw)
To: richard.weiyang
Cc: Liam.Howlett, akpm, davem, david, edumazet, gnoack, horms, kuba,
linux-kernel, linux-kselftest, linux-mm, linux-security-module,
lorenzo.stoakes, mhocko, mic, ming.lei, pabeni,
reddybalavignesh9979, rppt, shuah, skhan, surenb, vbabka
In-Reply-To: <20250828081026.yx6vgphtsf4pmr3y@master>
Hi Wei,
Thanks for testing and for your feedback.
Yeah, if you try to build inside a subdirectory, the top level
export may not apply, so CFLAGS don't get updated, and even if
they did, the path could be pointing to wrong location.
As the docs recommend, building selftest using TARGETS,
either from kernel source or "tools/testing/selftests/"
works fine and doesn't fail.
If you really want to build from selftests/mm/ directory then
defining KSFT_INCLUDES with a fallback in the Makefile will
resolve it, but there is no need of it if we stick with "TARGETS=mm".
Thanks
Bala Vignesh
^ permalink raw reply
* Re: [PATCH 2/2] selftests: Replace relative includes with non-relative for kselftest.h and kselftest_harness.h
From: Wei Yang @ 2025-08-28 8:10 UTC (permalink / raw)
To: Bala-Vignesh-Reddy
Cc: akpm, shuah, mic, gnoack, david, lorenzo.stoakes, Liam.Howlett,
vbabka, rppt, surenb, mhocko, davem, edumazet, kuba, pabeni,
horms, ming.lei, skhan, linux-kselftest, linux-kernel,
linux-security-module, linux-mm
In-Reply-To: <20250827144733.82277-3-reddybalavignesh9979@gmail.com>
On Wed, Aug 27, 2025 at 08:17:33PM +0530, Bala-Vignesh-Reddy wrote:
>Replaced relative path of kselftest.h and kselftest_harness.h
>to a non-relative path
>
>Signed-off-by: Bala-Vignesh-Reddy <reddybalavignesh9979@gmail.com>
>
[...]
>diff --git a/tools/testing/selftests/mm/cow.c b/tools/testing/selftests/mm/cow.c
>index d30625c18259..ccbb1958d467 100644
>--- a/tools/testing/selftests/mm/cow.c
>+++ b/tools/testing/selftests/mm/cow.c
>@@ -27,7 +27,7 @@
> #endif /* LOCAL_CONFIG_HAVE_LIBURING */
>
> #include "../../../../mm/gup_test.h"
>-#include "../kselftest.h"
>+#include "kselftest.h"
> #include "vm_util.h"
> #include "thp_settings.h"
>
Well there are too many changes and I failed to apply this one on current
mm-new. So I just manually change this with patch 1 applied.
This fails when I "cd tools/testing/selftests/mm/" and then make.
The Makefile in selftests/mm doesn't include ../Makefile so ../lib.mk doesn't
know the new CFLAGS when I do build in selftests/mm directory.
--
Wei Yang
Help you, Help me
^ permalink raw reply
* Re: [PATCH kvm-next V11 4/7] KVM: guest_memfd: Use guest mem inodes instead of anonymous inodes
From: Garg, Shivank @ 2025-08-28 5:49 UTC (permalink / raw)
To: Ackerley Tng, willy, akpm, david, pbonzini, shuah, seanjc, vbabka
Cc: brauner, viro, dsterba, xiang, chao, jaegeuk, clm, josef,
kent.overstreet, zbestahu, jefflexu, dhavale, lihongbo22,
lorenzo.stoakes, Liam.Howlett, rppt, surenb, mhocko, ziy,
matthew.brost, joshua.hahnjy, rakie.kim, byungchul, gourry,
ying.huang, apopple, tabba, paul, jmorris, serge, pvorel, bfoster,
vannapurve, chao.gao, bharata, nikunj, shdhiman, yan.y.zhao,
Neeraj.Upadhyay, thomas.lendacky, michael.roth, aik, jgg,
kalyazin, peterx, jack, hch, cgzones, ira.weiny, rientjes, roypat,
chao.p.peng, amit, ddutile, dan.j.williams, ashish.kalra, gshan,
jgowans, pankaj.gupta, papaluri, yuzhao, suzuki.poulose,
linux-bcachefs, linux-btrfs, linux-erofs, linux-f2fs-devel,
linux-fsdevel, linux-mm, linux-kernel, linux-security-module, kvm,
linux-kselftest, linux-coco
In-Reply-To: <diqztt1sbd2v.fsf@google.com>
On 8/28/2025 4:13 AM, Ackerley Tng wrote:
> Shivank Garg <shivankg@amd.com> writes:
>
>>
>> [...snip...]
>>
>
> I meant to send this to you before this version went out but you were
> too quick!
I wanted to get it merged quickly ;)
>
> Here's a new version, Fuad and I reviewed this again internally. The
> changes are:
>
> + Sort linux/pseudo_fs.h after linux/pagemap.h (alphabetical)
> + Don't set MNT_NOEXEC on the mount, since SB_I_NOEXEC was already set
> on the superblock
> + Rename kvm_gmem_inode_make_secure_inode() to kvm_gmem_inode_create()
> + Emphasizes that there is a creation in this function
> + Remove "secure" from the function name to remove confusion that
> there may be a "non-secure" version
> + In kvm_gmem_inode_create_getfile()'s error path, return ERR_PTR(err)
> directly instead of having a goto
>
Thanks for the quick update! The changes look good. I'll incorporate them
in the next version.
Best Regards,
Shivank
^ permalink raw reply
* Re: [RFC PATCH v1 0/2] Add O_DENY_WRITE (complement AT_EXECVE_CHECK)
From: Aleksa Sarai @ 2025-08-28 0:52 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Mickaël Salaün, Christian Brauner, Al Viro, Kees Cook,
Paul Moore, Serge Hallyn, Arnd Bergmann, Christian Heimes,
Dmitry Vyukov, Elliott Hughes, Fan Wu, Florian Weimer, Jann Horn,
Jeff Xu, Jonathan Corbet, Jordan R Abrahams,
Lakshmi Ramasubramanian, Luca Boccassi, Matt Bobrowski,
Miklos Szeredi, Mimi Zohar, Nicolas Bouchinet, Robert Waite,
Roberto Sassu, Scott Shell, Steve Dower, Steve Grubb,
kernel-hardening, linux-api, linux-fsdevel, linux-integrity,
linux-kernel, linux-security-module
In-Reply-To: <CALCETrWHKga33bvzUHnd-mRQUeNXTtXSS8Y8+40d5bxv-CqBhw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2052 bytes --]
On 2025-08-27, Andy Lutomirski <luto@kernel.org> wrote:
> On Wed, Aug 27, 2025 at 5:14 PM Aleksa Sarai <cyphar@cyphar.com> wrote:
> >
> > On 2025-08-26, Mickaël Salaün <mic@digikod.net> wrote:
> > > On Tue, Aug 26, 2025 at 11:07:03AM +0200, Christian Brauner wrote:
> > > > Nothing has changed in that regard and I'm not interested in stuffing
> > > > the VFS APIs full of special-purpose behavior to work around the fact
> > > > that this is work that needs to be done in userspace. Change the apps,
> > > > stop pushing more and more cruft into the VFS that has no business
> > > > there.
> > >
> > > It would be interesting to know how to patch user space to get the same
> > > guarantees... Do you think I would propose a kernel patch otherwise?
> >
> > You could mmap the script file with MAP_PRIVATE. This is the *actual*
> > protection the kernel uses against overwriting binaries (yes, ETXTBSY is
> > nice but IIRC there are ways to get around it anyway).
>
> Wait, really? MAP_PRIVATE prevents writes to the mapping from
> affecting the file, but I don't think that writes to the file will
> break the MAP_PRIVATE CoW if it's not already broken.
Oh I guess you're right -- that's news to me. And from mmap(2):
> MAP_PRIVATE
> [...] It is unspecified whether changes made to the file after the
> mmap() call are visible in the mapped region.
But then what is the protection mechanism (in the absence of -ETXTBSY)
that stops you from overwriting the live text of a binary by just
writing to it?
I would need to go trawling through my old scripts to find the
reproducer that let you get around -ETXTBSY (I think it involved
executable memfds) but I distinctly remember that even if you overwrote
the binary you would not see the live process's mapped mm change value.
(Ditto for the few kernels when we removed -ETXTBSY.) I found this
surprising, but assumed that it was because of MAP_PRIVATE.
--
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 265 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox