Re: Can la_symbind's flags parameter be modified outside of the function scope?

["Carlos O'Donell" <carlos at redhat dot com>]

On 05/28/2015 06:57 PM, Ben Woodard wrote:
> la_symbind and la_pltenter both get a flags pointer to a bitmask that
> contains two flags: LA_SYMB_NOPLTENTER and LA_SYMB_NOPLTEXIT. In
> theory either la_symbind or la_pltenter could stash the flags pointer
> in a variable out of scope of those functions to be modified based
> upon some other trigger. Right now changing these flags in that
> variable wonât work as expected because whether the PLT auditing
> functions are invoked is calculate and stored in cache after the
> return of symbind and pltenter. I would like to formalize this
> behavior and explicitly state that changing the variable pointed to
> by flags outside of the scope of symbind and pltenter cannot be used
> to re-enable PLT auditing functions.
> 
> Why this matters: If all the auditing libraries set both
> LA_SYMB_NOPLTENTER and LA_SYMB_NOPLTEXIT, and since there is no way
> to re-enable PLT auditing functions for that function, we can
> finalize the symbol in the GOT which will improve performance
> considerably.
> 
> On the other hand, if we decide that you can modify the bitmask
> pointed to by flags outside of the scope of the symbind and pltenter,
> then we need to remove the cache we use to determine whether to call
> any PLT auditing function for any audit library and we would also
> like to add a new feature which would allow us to choose to finalize
> a symbol in the GOT when we have no further interest in auditing it
> from this library. We have already implemented this feature but we be
> think that by explicitly specifying the semantic that the variable
> pointed to by flags cannot be modified outside of the scope of the
> symbind and pltenter functions we can implement it as an optimization
> without changing the interface to the audit library.
> 
> Since modifying the bitmask pointed to by flags outside of the scope
> of those functions would not trigger a recalculation of the cached
> value determining whether we should invoke any PLT auditing function
> for any library, we do not think that we would be breaking any
> existing behavior.
> 
> Carlos agrees with the logic of not allowing modification of the
> variable pointed to by the flags parameter but he asked me to run it
> past the broader community to make sure that is the consensus before
> I document and define the behavior.

Agree completely.

On top of it this change is an QoI change that has no ABI or API
impact at the moment. Therefore if we found it to be problematic
we could back it out immediately and so could the distributions.

I'm happy to see this change go in, and I think it would need less
review than changing the API.

As Roland commented on the last discussion, I'm curious to hear if
he has any opinion on this optimization. Roland?

Cheers,
Carlos.