This is the mail archive of the libc-help@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: Forcing BIND_NOW for a symbol



On 27/04/2016 03:53, Florian Weimer wrote:
> On 04/26/2016 04:13 PM, Adhemerval Zanella wrote:
>>
>>
>> On 25/04/2016 18:45, Florian Weimer wrote:
>>> On 04/25/2016 10:45 PM, Carlos O'Donell wrote:
>>>> On Mon, Apr 25, 2016 at 5:32 AM, Florian Weimer <fweimer@redhat.com> wrote:
>>>>> Could we look at the âVersion needsâ section (.gnu.version_r) and perhaps
>>>>> use a special symbol version for getrandom?
>>>>
>>>> Such a special symbol would mark getrandom as needing early resolution?
>>>
>>> We already scan .gnu.version_r, so we can quickly detect special cases at very little extra cost.  It's somewhat ugly because it's not a generic mechanism like IFUNC (but then, the IFUNC experience suggests it's better to gather internal users first before providing a generic interface).
>>>
>>> Florian
>>
>> If I understood your problem correctly, why instead of using IFUNC+BIND_NOW
>> you provide the getrandom to check by itself if ENOSYS is returned and
>> then call either the alternative the getrandom or return the error to the
>> user?
> 
> The problem I'm trying to solve is to support emulation even in chrooted processes.  If the process calls chroot and chroot does not contain a suitable /dev/urandom and /dev/random, emulation fails.
> 
> I do not want to open these files just in case the process may need them later.
> 

Right I did not take in consideration the fallback implementation may
fail where it should not.  However I do see that if a process calls the
fallback implementation and it fails due lack of file descriptors,
moving it earlier on ifunc resolution won't help much since it will
fail later (probably in previous open operation before the fallback
call).

The another issue you raised, calling after chroot environment, is the
trickiest and it might require non-optimal solution (a pseudo-random
number generator or just returning an error). This is definitively a 
good solution I give you that...

I am just bike-shedding here because I am kind sceptical that providing
a BIND_NOW for a simbol (and all the required logic in linker and libc)
justifies for the specific issue in question.


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