Page MenuHomeFreeBSD

elf_aux_info(3): accept a "big enough" buffer
Needs ReviewPublic

Authored by mhorne on Aug 4 2019, 12:00 AM.
Tags
None
Referenced Files
Unknown Object (File)
Dec 20 2023, 3:02 AM
Unknown Object (File)
Nov 29 2023, 1:02 AM
Unknown Object (File)
Sep 11 2023, 4:56 AM
Unknown Object (File)
Sep 4 2023, 11:54 PM
Unknown Object (File)
Aug 27 2023, 2:30 PM
Unknown Object (File)
Aug 15 2023, 12:14 AM
Unknown Object (File)
Jun 28 2023, 6:45 PM
Unknown Object (File)
Jun 9 2023, 9:03 PM
Subscribers
None

Details

Reviewers
kib
markj
ian
Summary

In some cases, elf_aux_info(3)'s buflen parameter is checked to be
exactly the size of the entry's underlying type. This can be difficult
to use since the sizes required vary per-entry and are not documented.

Fix this by accepting big enough buffers for all entries.

Note that the entries AT_CANARY and AT_PAGESIZES originally accepted a
buffer smaller than or equal to their length, since there was no way for
a user to know the amount of valid data returned. However, now it is
acceptable to copy to a larger buffer since the user can query
AT_CANARYLEN and AT_PAGESIZESLEN.

Diff Detail

Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 25675
Build 24267: arc lint + arc unit

Event Timeline

No, canary only accepted shorter buffer on intent.

The issue is that caller has no means to know how many bytes are valid in the result, unless it specified exactly the returned amount of data.

In D21152#459578, @kib wrote:

No, canary only accepted shorter buffer on intent.

The issue is that caller has no means to know how many bytes are valid in the result, unless it specified exactly the returned amount of data.

Ahh okay that makes sense. In that case I will update this patch to come after the one that exposes AT_CANARYLEN and AT_PAGESIZESLEN.

Update after applying this patch later in the series.