elf_aux_info(3): expose all auxv entries

[mhorne]

Summary

elf_aux_info(3) is a convenient wrapper for userspace access to the ELF
auxiliary vector. However, only a subset of the entries are exposed
through this interface. Update it to include all of the currently
defined entries other than AT_NOTELF.

Note that some of these entries (such as AT_UID, AT_GID, etc) are
only exported for the Linux ABI, and are marked as such.

PR: 234523

[mhorne]

lib/libc/gen/auxv.c

127

Are there any guarantees on execpath being null-terminated? I assumed so here but if that's not the case we could instead require a buflen of PATH_MAX or expose an AT_EXECPATHLEN entry.

[mhorne]

Update after applying the buflen patch later in the series.

[kib]

What is the reason for the change ?

AT_UID/AT_EUID etc, as well as AT_EXECFD are never pushed by kernel for FreeBSD ABI images.
I cannot imagine a reason why anything except rtld during startup, would look at AT_STACKPROT.

[mhorne]

In D21154#459615, @kib wrote:

What is the reason for the change ?

@jbeich's PR requests AT_EXECPATH specifically, but the issue reported is that only a subset of the entries are exposed.

AT_UID/AT_EUID etc, as well as AT_EXECFD are never pushed by kernel for FreeBSD ABI images.
I cannot imagine a reason why anything except rtld during startup, would look at AT_STACKPROT.

I made no assumptions on which entries would be useful to the user and chose to include them all, but I could cut that list down if desired. I believe the intent when making this function public was to offer a counterpart to glibc's getauxval(3), which exposes a complete (but different) set of auxv entries.

[kib]

In D21154#459620, @mhorne wrote:

In D21154#459615, @kib wrote:

What is the reason for the change ?

@jbeich's PR requests AT_EXECPATH specifically, but the issue reported is that only a subset of the entries are exposed.

AT_UID/AT_EUID etc, as well as AT_EXECFD are never pushed by kernel for FreeBSD ABI images.
I cannot imagine a reason why anything except rtld during startup, would look at AT_STACKPROT.

I made no assumptions on which entries would be useful to the user and chose to include them all, but I could cut that list down if desired. I believe the intent when making this function public was to offer a counterpart to glibc's getauxval(3), which exposes a complete (but different) set of auxv entries.

Well, for start we should not try to handle entries which our auxv does not contain at all. After that, entries which are only useful for rtld at boot also do not make sense, as e.g. stackprot which only reports information valid at startup.

[bcr]

Two small things in the man page, easy to fix. Let textproc/igor run over it and maybe "mandoc -Tlint" to be one the safe side.

lib/libc/gen/auxv.3

72

You need to make a line-break after a sentence stop.

76

Another line break after the sentence stop is needed here.