Re: [PATCH v2 1/5] elf: Define note name macros

[Dave Martin <Dave.Martin@arm.com>]

Hi all,

On Mon, Jan 06, 2025 at 08:48:05AM -0800, Kees Cook wrote:
> On Sat, Jan 04, 2025 at 11:38:34PM +0900, Akihiko Odaki wrote:
> > elf.h had a comment saying:
> > > Notes used in ET_CORE. Architectures export some of the arch register
> > > sets using the corresponding note types via the PTRACE_GETREGSET and
> > > PTRACE_SETREGSET requests.
> > > The note name for these types is "LINUX", except NT_PRFPREG that is
> > > named "CORE".
> > 
> > However, NT_PRSTATUS is also named "CORE". It is also unclear what
> > "these types" refers to.
> > 
> > To fix these problems, define a name for each note type. The added
> > definitions are macros so the kernel and userspace can directly refer to
> > them.
> 
> While ELF is specified in the Tool Interface Standard[1], the core dump
> format doesn't have an official specification. It does follow a lot of
> agreed rules, though, and the "note name" is intended to help coredump
> consumers distinguish between "common" things ("CORE") and Linux-specific
> things ("LINUX").
> 
> I think this should be explicitly spelled out in the UAPI header,
> even if we have "mistakes" for this mapping.

This seems reasonable.

> I'm not convinced we need these macros, though: everything is "LINUX"
> expect the common types. And the GNU types are "GNU". There are only 7
> types under the "CORE" name. :)

My starting point for suggesting the new macros was that the current
usage seems to be a historical accident; there doesn't seem to be an
underlying logic to it, except that arch-independent core note types
defined by Linux are named "CORE" ... except when they aren't.

Although the number of exceptional cases is small today, this doesn't
make for a robust rule -- nothing really prevents more unintentional
anomalies being added in future, so it seems prone to bitrot.

If the names are arbitrary, having a table rather than trying to
describe a rule seems the best way to avoid confusion.

Documenting these in a regular way may also encourage people to treat
the name as a formal part of the identifier, rather than a sort of
"comment" that nobody is quite sure what to do with (even if [1] makes
it clear).

That said, software does cope with the situation today; it's just a bit
gross.

> 
> For the macros, I'd much prefer NN_CORE, NN_LINUX, and NN_GNU.

What would be the point of these?

#define NN_CORE "CORE" doesn't convey any information at all, though I
suppose it does provide a layer of typo-resistance.

> If you really want to be able to examine the name from the type, then
> yeah, I guess we need something like the macros you have, but I'd much
> prefer also adding a macro like Dave suggested[2], and then replace the
> fill_note() with a macro that can unwrap it:
> 
> 	fill_note(note, NT_SIGINFO, size..., data...);
> 
> The repetition of NN_type, NT_type doesn't feel robust if we have a
> programmatic mapping: only the "type" is needed to determine both, so
> why supply both?
> 
> -Kees
> 
> [1] https://refspecs.linuxfoundation.org/elf/elf.pdf
> [2] https://lore.kernel.org/lkml/Z3vuBTiQvnRvv9DQ@e133380.arm.com/

Although not "robust", it should at least be obvious to the eye of
anyone pasting and repurposing an existing snippet of code that the
"type" is probably supposed to match in a single call.

I suppose we could have a kernel helper function containing a big
switch that gives you the name for each recognised note type though.
At the source code level, that would avoid specifying the "NN_"
arguments explicitly.  But if we still want a canonical way to describe
this mapping in elf.h, the "NN_" macros still serve a purpose.


With a literal string instead, I would expect then when adapting

	fill_note(note, NT_SIGINFO, "CORE", ...)

to

	fill_note(note, NT_WIZZFOO, ???, ...)

it's not clear what ??? should be.  I think people have tended to shrug
and just leave it unchanged -- so, it depends on which bit of code was
randomly chosen to serve as a template.  I could be guessing wrongly
about that, but if that's how the name gets chosen for new notes then
it doesn't feel ideal.

Cheers
---Dave