Now that all regset definitions declare an explicit note name, warn if
the note name is missing when generating a core dump.  Simplify the
fallback to always guess "LINUX", which is appropriate for all
Linux-specific notes (i.e., all newly added notes, for a long time
now).  The one standard exception (PR_FPREG) will no longer have an
"unexpected" note name overridden, but a warning will still be emitted.

Also warn if the specified note name doesn't match the legacy
pattern -- but don't bother to override the name in this case.  This
warning can be removed in future if new note types emerge that require
a specific note name that is not "LINUX".

No functional change, beyond the extra noise in dmesg and not
overriding an unexpected note name for PR_FPREG any more.

Now that all upstream arches are ported to use USER_REGSET_NOTE_TYPE(),
new regsets created by copy-pasting existing code should end up correct
by construction.

Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Kees Cook <kees@kernel.org>
Cc: Akihiko Odaki <akihiko.odaki@daynix.com>

---

***NOTE***

This patch is included here for completeness, but I expect to repost it
in a future cycle, once the arch patches have gone in.

Un-migrated arches will trigger WARNs with this patch applied, and
arches that don't specify codedump note names will always get
"LINUX" -- since the whole point is to stop guessing the note name in
the core code.

On _unpatched_ arches (only) this is a potential ABI break for the
NT_PRFPREG note (which, for historical reasons, is a "CORE" note even
though it is OS-specific on most or all arches).

Cheers
---Dave
---
 fs/binfmt_elf.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 89063d1d9e9a..92cf005468b5 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1750,8 +1750,13 @@ static int fill_thread_core_info(struct elf_thread_core_info *t,
 		if (is_fpreg)
 			SET_PR_FPVALID(&t->prstatus);
 
-		if (!note_name)
-			note_name = is_fpreg ? NN_PRFPREG : "LINUX";
+		/* There should be a note name, but if not, guess: */
+		if (WARN_ON_ONCE(!note_name))
+			note_name = "LINUX";
+		else
+			/* Warn on non-legacy-compatible names, for now. */
+			WARN_ON_ONCE(strcmp(note_name,
+					    is_fpreg ? "CORE" : "LINUX"));
 
 		__fill_note(&t->notes[note_iter], note_name, note_type,
 			    ret, data);
-- 
2.34.1

On July 1, 2025 6:56:16 AM PDT, Dave Martin <Dave.Martin@arm.com> wrote:
>Un-migrated arches will trigger WARNs with this patch applied, and
>arches that don't specify codedump note names will always get
>"LINUX" -- since the whole point is to stop guessing the note name in
>the core code.
>
>On _unpatched_ arches (only) this is a potential ABI break for the
>NT_PRFPREG note (which, for historical reasons, is a "CORE" note even
>though it is OS-specific on most or all arches).

After all your arch patches, aren't all the archs using the correct values? Is the WARN for new or out-of-tree archs?

-Kees

-- 
Kees Cook

On Sat, Jul 05, 2025 at 08:14:33AM -0700, Kees Cook wrote:
> 
> 
> On July 1, 2025 6:56:16 AM PDT, Dave Martin <Dave.Martin@arm.com> wrote:
> >Un-migrated arches will trigger WARNs with this patch applied, and
> >arches that don't specify codedump note names will always get
> >"LINUX" -- since the whole point is to stop guessing the note name in
> >the core code.
> >
> >On _unpatched_ arches (only) this is a potential ABI break for the
> >NT_PRFPREG note (which, for historical reasons, is a "CORE" note even
> >though it is OS-specific on most or all arches).
> 
> After all your arch patches, aren't all the archs using the correct
> values? Is the WARN for new or out-of-tree archs?
> 
> -Kees

[...]

If there are in-flight series where someone adds a new arch (?) or more
likely adds a new regset to an existing arch, then we might hit this.

In practice, all per-arch regsets apart from NT_PRFPREG use the name
"LINUX", so defaulting to this if the name is not specified will hardly
ever be a problem -- unless there really is a new arch out of tree that
is going to merge imminently.

I'm happy to simplify the check here if people prefer.

Cheers
---Dave