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: <sp5yxpqi62ymfhjysggmuvxxcwsxtz5kthu64h6kr2poymesbd@3tjqlq7z372p>
Date: Wed, 14 Jan 2026 22:25:11 +0100
From: Michal Koutný <mkoutny@...e.com>
To: Andrei Vagin <avagin@...gle.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>
Subject: Re: [PATCH 2/3] exec: inherit HWCAPs from the parent process

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

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

Thanks,
Michal