linux-kernel - Re: [PATCH 2/3] 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-prev] [day] [month] [year] [list]

Message-ID: <CAEWA0a5yShzk-AHvHKCXb3RM_KEY0aKHkvuRcref-46_1pWoqA@mail.gmail.com>
Date: Tue, 20 Jan 2026 21:24:51 -0800
From: Andrei Vagin <avagin@...gle.com>
To: Michal Koutný <mkoutny@...e.com>
Cc: Kees Cook <kees@...nel.org>, linux-kernel@...r.kernel.org, 
	linux-fsdevel@...r.kernel.org, linux-mm@...ck.org, criu@...ts.linux.dev, 
	Andrew Morton <akpm@...ux-foundation.org>, 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>, 
	Cyrill Gorcunov <gorcunov@...il.com>
Subject: Re: [PATCH 2/3] exec: inherit HWCAPs from the parent process

On Wed, Jan 14, 2026 at 1:25 PM Michal Koutný <mkoutny@...e.com> wrote:
>
> On Mon, Jan 12, 2026 at 02:18:18PM -0800, Andrei Vagin <avagin@...gle.com> wrote:
> > It is true for all existing arch-es. I can't imagine why we would want to
> > define ELF_HWCAP{n+1} without having ELF_HWCAP{n}. If you think we need
> > to handle this case, I can address it in the next version.
> >
> > It is just a small optimization to stop iterating after handling all
> > entries. The code will work correctly even when HWCAP n+1 exists but n
> > doesn't.
>
> Indeed (I accidentally ignored the AT_VECTOR_SIZE condition), it turns
> out no big deal then.
> I like that it's not needlessly searched (and copied altogether).
>
> > The inherit_hwcap function is only called if MMF_USER_HWCAP is set (auxv was
> > modified via prctl). However, even if mm->saved_auxv hasn't been
> > modified, it still contains valid values.
>
> Hm, bprm_mm_init/mm_alloc/mm_init would tranfser the flag from
> current, I'm still unclear whether it is necessary here. (It should make
> no harm though.)

It is just another optimization. Without this flag, we would need to
parse mm->saved_auxv even when it hasn't been changed.

>
> saved_auxv validity seems OK then.
>
> One more thing came up to my mind -- synchronization between prctl'ing
> and exec'ing threads (I see de_thread() is relatively late after
> bprm__mm_init()).


Currently, it is a user responsibility to synchronize these calls.
The comment in prctl_set_mm_map states:
  Note this update of @saved_auxv is lockless thus
  if someone reads this member in procfs while we're
  updating -- it may get partly updated results. It's
  known and acceptable trade off: we leave it as is to
  not introduce additional locks here making the kernel
  more complex.

Without synchronization between threads calling prctl() and execve(), a
new process could be executed with inconsistent HWCAPs. However, this
would not trigger any issues within the kernel. If we decide to
synchronize access to saved_auxv, we can use mm->arg_lock for that
purpose.

Thanks,
Andrei