Re: RFC: system-wide default tunables

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

On 06/10/23 17:25, DJ Delorie wrote:
> Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> writes:
>> The hwcap-related are still used for library selection, the original
>> intention of the ld.so.cache.  What I am afraid is ld.so.cache start to
>> being an umbrella for different and unrelated settings.
> 
> The alternative is to add an /etc/tunables.cache which would correspond
> to /etc/tunables.conf and/or /etc/tunables.conf.d/*
> 
> On most systems (no files) that would add one unsuccessful stat() call.

We can use 'access' to check for file existent first and then read the whole
file, as we do for /etc/ld.so.preload.  It should slight faster than stat.  

> 
>> It is not improper action that I worried, but security and performance
>> implications.  For instance, the malloc tunables change performance depending
>> of the workload; a system-wide tunable might not the best option for all
>> programs.
> 
> Yup.  That would be a bad choice, but not an *invalid* choice.  The more
> likely use of these tunables would be to alter the hwcaps logic to
> better match the hardware, or to enforce a "common minimum" hardware
> level for migratable programs.  Or something else I can't imagine just
> yet ;-)
> 
>> But I am assuming that system-wide has preference
>> over user-defined, which does not seems the case for your proposal.
> 
> Since these are tunables and not, say, security settings, it seemed to
> make sense that a system-wide setting would be "new default" relative to
> the environment variable.  An environment variable can be set for a
> specific program; a system-wide setting cannot.
> 
>> I think what is not clear is if the idea is to mimic the 'security_level'
>> of tunable (which I intend to remove), in a way that we might have tunable
>> that might overridden and/or disabled by the process (through the envvar).
> 
> I thought of that - being able to have flags for tunables that control
> those overrides et al - but decided against it.  These are tunables, not
> security settings, and are more "advisory" than "mandatory", and I
> couldn't think of a legitimate reason to stop a program from having a
> program-specific tuning.

But we already have opt-in security features with glibc.cpu.x86_ibt,
glibc.cpu.x86_shstk, and glibc.mem.tagging.  At least the x86 ones,
the default is set by an ELF property (assuming --enable-cet), but
memory tagging is complete opt-in.

That's why I think we either need to add some security context on
system-wide tunables; where the tunable can not be override by user;
or move the opt-in security tunable to a different mechanism.

> 
>>>>> * 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, 
>>>
>>> Unless it differs between applications.  Or if the cache were generated
>>> with one version of glibc and the application runs with a different
>>> version.
>>
>> But in this case, and invalid/unknown value should be ignored if the program
>> is using a different glibc version.
> 
> The case I was referring to would be if the *range* changed between
> versions.  Same tunable name, different min/max.
> 
> I don't think it would matter much to test the wrong range, but the app
> still needs to range check at runtime anyway.

Yes, I wasn't say otherwise.  The range check should always be done at
runtime as well.

> 
>> Setting an invalid/unknown tunable still make little sense to me, it
>> means that it will always be ignored by some target if you are running
>> different glibc with different tunable setting support.  And I don't
>> see why we should not make it explicit for the administrator.
>>
>> Maybe the best way is to make the range/key check as default and add an
>> option to force to set invalid values.
> 
> I'm OK with warnings.
> 
> On a system with multiple installed versions of glibc (no, don't ask me
> how ;) there might not be one common set of checks that works.
> 
>>> That enum might change from version to version.  We're already seeing
>>> enum-related issues with RHEL upgrades.
>>
>> Yes, Carlos has brought the awk sorting problem.  I think this is fixable
>> (maybe porting the tunables generation to python, run the sysdeps search
>> in a predictable way, set enum value based on tunable ordering) and we can
>> add test to check if tunable enum changes over releases.
>>
>> I still think this is simpler than data structure your are proposing, and 
>> with less performance issues.  But I don't have a strong preference.
> 
> If we store the enums, and *also* store the tunable name, we could use
> the enum for lookup but also strcmp to validate that it's the correct
> one.

Sounds reasonable.

> 
>>>>> * 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?
>>>
>>> The variable overrides the cache.
>>
>> Right.  Do we allow security opt-in option as well? I am asking because
>> in this case, it is expected that the system-wide should not be overridden.
> 
> If a tunable needs to be ignored for security reasons, I would assume
> the system-wide default would be left alone but the environment variable
> would be ignored.  I do not expect a case where a system-wide tunable
> should become "sticky" and block the environment variable in a
> non-security context.

Yes, I would expect that once the administrator sets a opt-in security
features; it should not be able to be disable by user tunables.

> 
> This assumes that a correct tunable setting is required for
> secure/proper operation; if this is not the case, the program is at
> fault ;-) because it's not just "tuning" at that point.
> 
>>> Er, isn't that the environment variable?
>>>
>>
>> It is a easier way to configure per-process tunable, it avoid messing with FS 
>> that either are mounted RO or do not allow adding wrappers to setup GLIBC_TUNABLES.
>>
>> Also, my idea is to just remove the tunable setting for setuid/setguid; so 
>> per-process is a way to setup specific rules for security sensitive processes
>> (assuming that we will support non-overriden security tunables).
> 
> So /etc/tunables.conf would have something like this?
> 
> [/bin/bash]
> glibc.malloc.max_arenas=1
> 
> This is the type of complexity I wanted to avoid.
> 
> We could, in theory, add an ELF section for embedding tunables into an
> executable image, but that's outside my scope.
> 

This was only an idea, but I take this might be added only if we do have a
requirement for that.

>> The alternative is to add an /etc/tunables.cache which would correspond
>> to etc/tunables.conf and/or /etc/tunables.conf.d*
> 
> This adds the question: if we have a separate cache file, do we need a
> separate program to generate it?
> 

I think it would make sense, since ldconfig is really described as 'configure
dynamic linker run-time bindings'.