Bug 26075 - Static TLS usage in audit modules should affect static TLS reservation
Summary: Static TLS usage in audit modules should affect static TLS reservation
Status: RESOLVED WORKSFORME
Alias: None
Product: glibc
Classification: Unclassified
Component: dynamic-link (show other bugs)
Version: unspecified
: P2 minor
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-06-03 11:40 UTC by Florian Weimer
Modified: 2020-06-03 13:42 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Florian Weimer 2020-06-03 11:40:59 UTC
TLS usage from audit modules is not taken into account for sizing the static TLS area. As a result, too much TLS usage from audit modules causes all programs to fail to load. This also happens for static TLS usage in glibc itself, so it cannot be fully worked around by using dynamic TLS in audit modules.

(Due to the early TCB reservation necessary to run audit code, the static TLS reservation is also needed for loading the main program, I think, but this bug is not about that.)
Comment 1 Florian Weimer 2020-06-03 13:42:42 UTC
It turns out that elf/dl-tls.c attempts to account for this already, it's just that the limit has not been updated in a while:

/* Amount of excess space to allocate in the static TLS area
   to allow dynamic loading of modules defining IE-model TLS data.  */
#define TLS_STATIC_SURPLUS     64 + DL_NNS * 100

There cannot be more than DL_NNS - 1 audit modules, so if the magic constant 100 reflects implementation TLS usage (it currently does not, it is more like 144 bytes),