Re: RFC: system-wide default tunables

[DJ Delorie <dj@redhat.com>]

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.

> 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.

>>>> * 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.

> 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.

>>>> * 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.

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.