linux-kernel - [PATCH 0/4 v3] exec: inherit HWCAPs from the parent process

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260209190605.1564597-1-avagin@google.com>
Date: Mon,  9 Feb 2026 19:06:01 +0000
From: Andrei Vagin <avagin@...gle.com>
To: Kees Cook <kees@...nel.org>, Andrew Morton <akpm@...ux-foundation.org>
Cc: Cyrill Gorcunov <gorcunov@...il.com>, Mike Rapoport <rppt@...nel.org>, 
	Alexander Mikhalitsyn <alexander@...alicyn.com>, linux-kernel@...r.kernel.org, 
	linux-fsdevel@...r.kernel.org, linux-mm@...ck.org, criu@...ts.linux.dev, 
	Chen Ridong <chenridong@...wei.com>, Christian Brauner <brauner@...nel.org>, 
	David Hildenbrand <david@...nel.org>, Eric Biederman <ebiederm@...ssion.com>, 
	Lorenzo Stoakes <lorenzo.stoakes@...cle.com>, Michal Koutny <mkoutny@...e.com>
Subject: [PATCH 0/4 v3] exec: inherit HWCAPs from the parent process

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().

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

Cc: Andrew Morton <akpm@...ux-foundation.org>
Cc: Chen Ridong <chenridong@...wei.com>
Cc: Christian Brauner <brauner@...nel.org>
Cc: David Hildenbrand <david@...nel.org>
Cc: Eric Biederman <ebiederm@...ssion.com>
Cc: Kees Cook <kees@...nel.org>
Cc: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: Michal Koutny <mkoutny@...e.com>
Cc: Cyrill Gorcunov <gorcunov@...il.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