fs/binfmt_elf.c | 8 +- fs/binfmt_elf_fdpic.c | 14 ++- fs/exec.c | 64 ++++++++++++ fs/proc/base.c | 12 ++- include/linux/auxvec.h | 2 +- include/linux/binfmts.h | 11 ++ include/linux/mm_types.h | 2 + kernel/fork.c | 8 ++ kernel/sys.c | 30 +++--- tools/testing/selftests/exec/.gitignore | 1 + tools/testing/selftests/exec/Makefile | 1 + tools/testing/selftests/exec/hwcap_inherit.c | 104 +++++++++++++++++++ 12 files changed, 231 insertions(+), 26 deletions(-) create mode 100644 tools/testing/selftests/exec/hwcap_inherit.c
This patch series introduces a mechanism to inherit hardware capabilities (AT_HWCAP, AT_HWCAP2, etc.) from a parent process when they have been modified via prctl. To support C/R operations (snapshots, live migration) in heterogeneous clusters, we must ensure that processes utilize CPU features available on all potential target nodes. To solve this, we need to advertise a common feature set across the cluster. Initially, a cgroup-based approach was considered, but it was decided that inheriting HWCAPs from a parent process that has set its own auxiliary vector via prctl is a simpler and more flexible solution. This implementation adds a new mm flag MMF_USER_HWCAP, which is set when the auxiliary vector is modified via prctl(PR_SET_MM_AUXV). When execve() is called, if the current process has MMF_USER_HWCAP set, the HWCAP values are extracted from the current auxiliary vector and inherited by the new process. The first patch fixes AUXV size calculation for ELF_HWCAP3 and ELF_HWCAP4 in binfmt_elf_fdpic and updates AT_VECTOR_SIZE_BASE. The second patch implements the core inheritance logic in execve(). The third patch adds a selftest to verify that HWCAPs are correctly inherited across execve(). v4: minor fixes based on feedback from the previous version. v3: synchronize saved_auxv access with arg_lock v1: https://lkml.org/lkml/2025/12/5/65 v2: https://lkml.org/lkml/2026/1/8/219 v3: https://lkml.org/lkml/2026/2/9/1233 Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Chen Ridong <chenridong@huawei.com> Cc: Christian Brauner <brauner@kernel.org> Cc: David Hildenbrand <david@kernel.org> Cc: Eric Biederman <ebiederm@xmission.com> Cc: Kees Cook <kees@kernel.org> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Cc: Michal Koutny <mkoutny@suse.com> Cc: Cyrill Gorcunov <gorcunov@gmail.com> Andrei Vagin (3): binfmt_elf_fdpic: fix AUXV size calculation for ELF_HWCAP3 and ELF_HWCAP4 exec: inherit HWCAPs from the parent process mm: synchronize saved_auxv access with arg_lock selftests/exec: add test for HWCAP inheritance fs/binfmt_elf.c | 8 +- fs/binfmt_elf_fdpic.c | 14 ++- fs/exec.c | 64 ++++++++++++ fs/proc/base.c | 12 ++- include/linux/auxvec.h | 2 +- include/linux/binfmts.h | 11 ++ include/linux/mm_types.h | 2 + kernel/fork.c | 8 ++ kernel/sys.c | 30 +++--- tools/testing/selftests/exec/.gitignore | 1 + tools/testing/selftests/exec/Makefile | 1 + tools/testing/selftests/exec/hwcap_inherit.c | 104 +++++++++++++++++++ 12 files changed, 231 insertions(+), 26 deletions(-) create mode 100644 tools/testing/selftests/exec/hwcap_inherit.c -- 2.52.0.351.gbe84eed79e-goog
On Tue, Feb 17, 2026 at 10:01 AM Andrei Vagin <avagin@google.com> wrote: > > This patch series introduces a mechanism to inherit hardware capabilities > (AT_HWCAP, AT_HWCAP2, etc.) from a parent process when they have been > modified via prctl. > > To support C/R operations (snapshots, live migration) in heterogeneous > clusters, we must ensure that processes utilize CPU features available > on all potential target nodes. To solve this, we need to advertise a > common feature set across the cluster. > > Initially, a cgroup-based approach was considered, but it was decided > that inheriting HWCAPs from a parent process that has set its own > auxiliary vector via prctl is a simpler and more flexible solution. > > This implementation adds a new mm flag MMF_USER_HWCAP, which is set when the > auxiliary vector is modified via prctl(PR_SET_MM_AUXV). When execve() is > called, if the current process has MMF_USER_HWCAP set, the HWCAP values are > extracted from the current auxiliary vector and inherited by the new process. > > The first patch fixes AUXV size calculation for ELF_HWCAP3 and ELF_HWCAP4 > in binfmt_elf_fdpic and updates AT_VECTOR_SIZE_BASE. > > The second patch implements the core inheritance logic in execve(). > > The third patch adds a selftest to verify that HWCAPs are correctly > inherited across execve(). > > v4: minor fixes based on feedback from the previous version. Kees, I think it is ready to be merged. Let me know if you have any other comments/concerns/questions. Thanks, Andrei
On Mon, Feb 23, 2026 at 10:29:00AM -0800, Andrei Vagin wrote: > On Tue, Feb 17, 2026 at 10:01 AM Andrei Vagin <avagin@google.com> wrote: > > > > This patch series introduces a mechanism to inherit hardware capabilities > > (AT_HWCAP, AT_HWCAP2, etc.) from a parent process when they have been > > modified via prctl. > > > > To support C/R operations (snapshots, live migration) in heterogeneous > > clusters, we must ensure that processes utilize CPU features available > > on all potential target nodes. To solve this, we need to advertise a > > common feature set across the cluster. > > > > Initially, a cgroup-based approach was considered, but it was decided > > that inheriting HWCAPs from a parent process that has set its own > > auxiliary vector via prctl is a simpler and more flexible solution. > > > > This implementation adds a new mm flag MMF_USER_HWCAP, which is set when the > > auxiliary vector is modified via prctl(PR_SET_MM_AUXV). When execve() is > > called, if the current process has MMF_USER_HWCAP set, the HWCAP values are > > extracted from the current auxiliary vector and inherited by the new process. > > > > The first patch fixes AUXV size calculation for ELF_HWCAP3 and ELF_HWCAP4 > > in binfmt_elf_fdpic and updates AT_VECTOR_SIZE_BASE. > > > > The second patch implements the core inheritance logic in execve(). > > > > The third patch adds a selftest to verify that HWCAPs are correctly > > inherited across execve(). > > > > v4: minor fixes based on feedback from the previous version. > > Kees, > > I think it is ready to be merged. Let me know if you have any other > comments/concerns/questions. Yeah, I think it's looking good. I'll land this in for-next/execve after rc2 (a week from now). Thanks! -- Kees Cook
On Mon, Feb 23, 2026 at 2:29 PM Kees Cook <kees@kernel.org> wrote: > > On Mon, Feb 23, 2026 at 10:29:00AM -0800, Andrei Vagin wrote: > > On Tue, Feb 17, 2026 at 10:01 AM Andrei Vagin <avagin@google.com> wrote: > > > > > > This patch series introduces a mechanism to inherit hardware capabilities > > > (AT_HWCAP, AT_HWCAP2, etc.) from a parent process when they have been > > > modified via prctl. > > > > > > To support C/R operations (snapshots, live migration) in heterogeneous > > > clusters, we must ensure that processes utilize CPU features available > > > on all potential target nodes. To solve this, we need to advertise a > > > common feature set across the cluster. > > > > > > Initially, a cgroup-based approach was considered, but it was decided > > > that inheriting HWCAPs from a parent process that has set its own > > > auxiliary vector via prctl is a simpler and more flexible solution. > > > > > > This implementation adds a new mm flag MMF_USER_HWCAP, which is set when the > > > auxiliary vector is modified via prctl(PR_SET_MM_AUXV). When execve() is > > > called, if the current process has MMF_USER_HWCAP set, the HWCAP values are > > > extracted from the current auxiliary vector and inherited by the new process. > > > > > > The first patch fixes AUXV size calculation for ELF_HWCAP3 and ELF_HWCAP4 > > > in binfmt_elf_fdpic and updates AT_VECTOR_SIZE_BASE. > > > > > > The second patch implements the core inheritance logic in execve(). > > > > > > The third patch adds a selftest to verify that HWCAPs are correctly > > > inherited across execve(). > > > > > > v4: minor fixes based on feedback from the previous version. > > > > Kees, > > > > I think it is ready to be merged. Let me know if you have any other > > comments/concerns/questions. > > Yeah, I think it's looking good. I'll land this in for-next/execve after > rc2 (a week from now). Hi Kees, just a friendly ping in case this slipped off your radar. Thanks, Andrei
© 2016 - 2026 Red Hat, Inc.