This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 1/9] Add vectorized getenv for glibc use


On 05/28/2013 06:49 PM, Roland McGrath wrote:
>> I think this can go in as long as Roland has no objections. Roland has
>> expressed some concerns with using environment variables to expose glibc
>> tunables to users. If I understand correctly I think Roland's concerns
>> were around performance, and control (user vs. system admin). I'll
>> let Roland speak for himself though.
> 
> I had expected that any sensible implementation would look at the
> environment only once per program invocation, so performance was never
> my chief concern.  What concerns me is the complexity of the system
> and the subtle security implications of obeying new environment
> variables.  

Those concerns are always present.

How is this different than any other change we make?

For example right now the DT_BIND_NOW flag in the executable is ignored
if LD_AUDIT loads an auditing library. Should it be? That violates
the executables request to have all symbols bound immediately, and
that has security implications.

This kind of security versus feature question is *always* present
in every decision we make, this one is no different.

It *feels* different because the user sets them right now in the
immediate present without recompiling.

How is this different from the interaction of all the APIs we have
in glibc right now? Static linking? Dynamic linking? Dynamic loading
from a static executable? Forking with threads? 

Even if it was an API, eventually a developer will set use it in source
code and we'll have the same security implications we had with env
vars.

It does not absolve us of reviewing the code to make sure it is robust
and well isolated from the rest of the system.

We've been reviewing this code since December 2012 when Andi first
posted the core parts of it.

> I explained this before in the context of Siddhesh's proposal for an
> environment variable affecting pthread stack size.  For that case, we
> are starting with an API to change the default from inside the program
> and this is sufficient for now and can be built on to prototype future
> possibilities.

The point of the elision patch set is to enable transparent support for
lock elision without the need to recompile your program with a new API.

If we require that users recompile their programs and make a special
API call to enable elision, then we've lost a significant benefit of 
the work.

(1) Alternative: Enable elision at build time.

The alternative is to make this a build time flag, you build glibc with
lock elision enabled or not depending on what your distribution wants.

The problem with that is that there may be some applications that
are not-conforming to POSIX at which point the elision patch *may*
break those applications. Every practical distribution will then
add in an environment variable to control elision. Why? Rebuilding
3rd party applications to disable elision is not feasible.

We are in the same situation. While one might consider upstream a secure
and safe glibc, the downstream is left to face practical problems alone
and without any help from the stewards of the project.

Thus unconditionally enabling Elision at build time is not a
practical alternative.

(2) Alternative: Use a pseudo HWCAP for Elision enabled libs.

We could add a pseudo HWCAP for Elision enabled libraries, build glibc
with elision enabled, and ship two sets of libraries, one with elision,
one without.

This doubles QA at the distro level, requiring testing two glibc packages.
It takes a pseudo HWCAP bit away, they are a limited resource.

We presently have no way to override pseudo HWCAP bits since LD_HWCAP_MASK
doesn't override pseudo HWCAP bits. Not to mention that LD_HWCAP_MASK
lacks the flexibility of individual GLIBC_* env vars.

Thus using a pseudo HWCAP for elision libs costs a bit in the mask
when it isn't needed, doubles QA, increases build times, and is really
no different with LD_HWCAP_MASK to disable elision.

Thus this is also not a good solution for distros.

----

What other solutions are there that we might try?

Adding the ability to tune the library with environment variables
appears to have the consequence of "potential future security
issues."

This is the same consequence to *any* change we have in the library.

We must always be vigilant and do our code review, test appropriately,
and fix bugs reported promptly.

> Those concerns remain about all new environment variables and I
> certainly don't think we should be introducing any new magic
> environment variables at this point in the cycle.  

This isn't new. We've been talking about environment variables 
since Andi posted the first patch set in December 2012.

The only change has been their name, and the ongoing discussion
surrounding the use of environment variables to tune library
behaviour.

> Perhaps in the long
> run environment variables will in some fashion be part of the
> interface for tunables.  But we need to have a thorough contemplation
> of the whole area of tunables before we add anything to any part of
> the libc interface.  Special new magic interpretation of user-fungible
> bits like the environment is among the most dangerous approaches and
> we must be extremely circumspect.

What experience are you drawing upon to call this the 
"most dangerous approach"?

I don't mean to call into question your relevant experience, but
I'd like to know if this has been tried before and has lead to
utter failure.

At present all I can tell is that you don't like the idea, because
your use of language like "magic" implies an opaque and unexplained
interface. The interface is nothing like that, we document exactly
how it behaves and what it does. Similarly for the env var that
would have controlled the default thread stack size.

I'll start a distinct thread to talk about this though since we're
at an impasse for what to do about env vars that tune the library
runtime behaviour.

> If there is in future some need to look at more environment variables,
> then this implementation of doing that efficiently seems fine enough.

Agreed.

Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]