Re: RFC: system-wide default tunables

[Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>]

On 04/10/23 17:55, DJ Delorie wrote:
> 
> Before I start on actual coding, I'm sharing my thoughts on this
> project to gain consensus...
> 
> Problem: tunables are set by an environment variable, and may be
> limited by security settings, containerization, etc.  Plus users may
> not assume that the env var is pre-set, and just overwrite it.
> 
> Solution: Add a way to specify system-wide defaults for tunables.
> 

The idea sounds ok, but adding on ld.so.cache means it would not work 
for static.  I don't think this is really an issue, static PIE is really
tricky because self-relocation happens after tunable (because tunables 
itself might change ifunc selection); and trying to add support for 
static PIE would require a lot of messy refactoring (all ld.so.cache 
loading would need to be annotated hidden, no external function calling,
even mem* ones; etc.).

> Ideas:
> 
> * Specify some file or files in /etc that contain tunables settings.
>   Follow the ld.so.conf patterns, allow subdirectories, etc.
> 
> * Store tunables info in /etc/ld.so.cache in a new slot at the end,
>   with a new enum for the chunk.  This way older glibc will just
>   ignore it.  Parsing and storing will be done via ldconfig.

It means that we will have to always load the ld.so.cache, not only when
we will actually have to load an ET_DYN .  It should be ok, but runtimes
that usually only link against libc.so (like rust) will have additional
overhead on startup.

We also have DF_1_NODEFLIB to inhibit loader cache search, should we add
another flag to inhibit the global tunables?  It does not make sense to
set per-library, but it still might be useful to set on ET_EXEC.

So I am not fully sure adding the global tunable setting on ld.so.cache is
the correct approach.  However, adding on an external file will add
another open/mmap/close on each program; plus the extra mmap.

> 
> * Values in ld.so.cache will be parsed but not range checked; that's
>   dependent on what the glibc app expects.

Importing the range information on tunable definition is straightforward, 
so I think we should add the range check on ldconfig ld.so.cache setup.
There is no error checking on env var tunable, invalid values are just
ignored without any user feedback.  Since we will do pre-processing,
I think it would be valuable to at least show any possible invalid range,
specially because this is a administration setting.

> 
> * read those, do range checking, and call callbacks at runtime
> 
> * To speed processing, encode a hash for each tunable name, both in
>   glibc's table (which is built at glibc build time) and in
>   /etc/ld.so.cache.  Comparing the hash typically fails but avoids a
>   string compare.  Matching hashes are followed by a string compare to
>   verify.  The hash need not be crypographically secure.

Do we really need this optimization?  Internally, the tunables are already
accessed through a enum, which is essentially a index on tunable_list.
Why can you we use the same enums value on the cache definition keys? 

The string mapping could be accomplished by adding a string list, with
the tunable value being the offset.

> 
> * I'm not going to try to add some "syntax" to specify if a tunable is
>   overridable or not; this is a simple default-only change.

How should we handle the envvar GLIBC_TUNABLEs in the presence of a system-wide
tunable?  Should we ignore the envvar or merge the results? Which one takes 
precedence (I take the system-wide)? Should we add a way to override system-wide 
value (similar to DF_1_NODEFLIB) as a runtime options (either another envvar or 
a extra field in GLIBC_TUNABLE)?

> 
> * Tunables set by these defaults will not be disabled for setuid
>   programs; it's assumed they're a "trusted source".

This seems reasonable, and with this rationale should we add an option
to allow some tunable to be disabled or overriden? I take this is an extra
complexity that we should not pursuit.