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)
Thu, May 2, 9:05 PM
Unknown Object (File)
Thu, May 2, 5:29 PM
Unknown Object (File)
Thu, May 2, 3:05 PM
Unknown Object (File)
Thu, May 2, 2:21 PM
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
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 25665
Build 24258: 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.