Re: RFC: system-wide default tunables

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

On 06/10/23 11:44, Adhemerval Zanella Netto wrote:
> 
> 
> 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. 

Another possible feature that comes from the tunable discussion is whether 
make sense to add a per-process tunables.  The aarch64 MTE for instance is an
example, it is disabled by default because of performance implications; so
the admin might just enable it on some really security sensitive processes.