Re: [RFC] Prevent tailcall optimizations of libdl functions

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

On 01/25/2017 10:52 AM, Szabolcs Nagy wrote:
> On 25/01/17 15:43, Florian Weimer wrote:
>> On 01/25/2017 04:41 PM, Szabolcs Nagy wrote:
>>> On 25/01/17 15:40, Florian Weimer wrote:
>>>> On 01/25/2017 04:38 PM, Szabolcs Nagy wrote:
>>>>> On 25/01/17 15:32, Yuri Gribov wrote:
>>>>>> FWIW it sounds like GCC attribute would be the most natural solution
>>>>>> (and probably also useful in other contexts). I'll try to cook a patch
>>>>>> for GCC if there are no objections.
>>>>>
>>>>> note that even if dlsym is marked notailcall, with
>>>>>
>>>>> p = dlsym;
>>>>> ...
>>>>> return p();
>>>>>
>>>>> if the type of p does not carry the attributes of
>>>>> dlsym then this can be a tailcall.
>>>>
>>>> Yes, but dlsym would still see the address of the function containing the dlsym call, which is what we need to
>>>> determine the relevant object.
>>>
>>> how?
>>
>> At worst, the return address points to the code which jumps to the address p.  This code is still in the object
>> which calls dlsym.
>>
> 
> i don't immediately see why.
> 
> i'd assume if we want f(RTLD_NEXT, sym) work
> for a function pointer f pointing to dlsym
> then it would need to prevent tco just like
> dlsym to have a return address in the right dso.
> 
> (e.g. g() in dso1 calls h() in dso2 which
> calls f that is dlsym, whether h tailcalls
> f or not seem to matter)
 
Even a single failure here could mean breaking the isolation
guarantees given by dlmopen, and that's a very serious problem.
In the case of dlmopen it's critical we know the caller to
identify the new symbol namespace to for the lookup.
So there isn't an easy way to remove glibc's requirement on
knowing the DSO the call came from.

I see libc_nonshared.a and __dso_handle as a fix of last resort.

In summary:

* Add the gcc attribute, and markup dlsym...

_and_

* Add the wrapper macro to further inhibit tco.

I don't see any downside to doing both at the same time.

I'll ask Florian in another email why he cautions against the wrapper.

-- 
Cheers,
Carlos.