On Fri, Mar 20, 2026 at 11:19 AM Kees Cook <kees@kernel.org> wrote:
>
> On Fri, Mar 20, 2026 at 10:15:26AM +0100, Marek Szyprowski wrote:
> > Hi,
> >
> > On 17.02.2026 19:01, Andrei Vagin wrote:
> > > 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.
> > >
> > > This patch adds a new mm flag MMF_USER_HWCAP, which is set when the
> > > auxiliary vector is modified via prctl(PR_SET_MM, 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 stored
> > > in the linux_binprm structure. These values are then used to populate
> > > the auxiliary vector of the new process, effectively inheriting the
> > > hardware capabilities.
> > >
> > > The inherited HWCAPs are masked with the hardware capabilities supported
> > > by the current kernel to ensure that we don't report more features than
> > > actually supported. This is important to avoid unexpected behavior,
> > > especially for processes with additional privileges.
> > >
> > > Reviewed-by: Cyrill Gorcunov <gorcunov@gmail.com>
> > > Reviewed-by: Alexander Mikhalitsyn <aleksandr.mikhalitsyn@futurfusion.io>
> > > Signed-off-by: Andrei Vagin <avagin@google.com>
> >
> > This patch landed in yesterday's linux-next as commit ac8c259ce0d5
> > ("exec: inherit HWCAPs from the parent process"). In my tests I found
> > that it causes regression on my Khadas VIM3L board, which is based
> > on Amlogic Meson SM1 (S905D3) SoC
> > (arch/arm64/boot/dts/amlogic/meson-sm1-khadas-vim3l.dts). Running init
> > process fails after this patch:
> >
> > Freeing unused kernel memory: 13696K
> > Run /sbin/init as init process
> > Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000004
> > CPU: 1 UID: 0 PID: 1 Comm: init Not tainted 7.0.0-rc4-next-20260319
> > #12369 PREEMPT
> > Hardware name: Khadas VIM3L (DT)
> >
> > What is probably important here, this board (for some internal,
> > historical reasons) uses armv7l rootfs, but other boards used in my
> > tests, based on different SoCs, also use such rootfs and boot fine with
> > yesterday's linux-next. Reverting ac8c259ce0d5 commit (together with
> > 0ea77bbf3b98 due to dependencies) on top of next-20260319 fixes this issue.
>
> Thanks for the report! I've dropped these patches from -next for now.
> Andrei can you investigate what is needed to fix this?