[PATCH v6 4/4] Add system-wide tunables: Filters

[DJ Delorie]

Yury Khrustalev <yury.khrustalev@arm.com> writes:
>>   $glibc.only-for.unsecure-binaries=1
>>   @glibc.only-for.secure-binaries=1
>
> We probably need a bit information about /etc/tunables.conf in the
> manual.

Agreed.  Writing up all the documentation is the next task on my list,
but I'm trying to avoid this patch rotting for a couple more years while
waiting for every little feature to be haggled over, reviewed, and
committed.  This patch set is step 1 ;-)

>> -  __tunables_init (__environ);
>> +  __tunables_init (__environ, argv);
>
> Nit: For some deeply intrinsic reason I prefer argv to go first.

I won't put in argc even if you ask ;-)

>> +tst-tunconf1-ENV = GLIBC_TUNABLES=glibc.malloc.tcache_count=5
>
> If I add glibc.malloc.tcache_max=42 to this line, the test fails.
> It looks like the environment variable overrides tunables.conf,
> is this intentional?

Yes!  At this point, all the security implementation is missing (aside
from AT_SECURE, because that was easy).  The "problem" with the security
model I chose is that each tunable needs some inherent logic about
what's "more secure".  For numeric values, is a bigger one more secure,
or a smaller one?  What about hwcaps?  Is adding a hwcap more secure, or
removing one?  Does it depend on which hwcap?

I put the syntax in because it affects the file format and I didn't want
to have to change that later.  I might end up skipping the "more secure"
implementation and just do the "override or not" options, but even the,
what does "do not override" mean for hwcaps?  Is it per-cap or the whole
string?

Either way, it (like the docs and man pages) was intentionally left as a
"next step".

>> +	  /* Apply selected filter, if any.  */
>> +	  switch (tec->flags & TUNCONF_FLAG_FILTER) {
>> +	  case TUNCONF_FILTER_PERPROC:
>> +	    /* Perform one-time calculations that aren't needed if we
>> +	       don't use this filter.  */
>> +	    if (prog_name_len == -1)
>> +	      {
>> +		ssize_t n = readlink ("/proc/self/exe",
>> +				      exebuf, sizeof (exebuf) - 1);
>
> Do we have to do this inside the for loop?

We only do it once, and only if the tunable has that filter.  I assume
most systems will not even have a tunables.conf, much less a per-program
filter, so I didn't want to do file I/O if not needed.