Forcing BIND_NOW for a symbol

Carlos O'Donell carlos@redhat.com
Mon Nov 2 22:14:00 GMT 2015


On 11/02/2015 11:26 AM, Florian Weimer wrote:
> On 11/02/2015 05:17 PM, Carlos O'Donell wrote:
>> On 11/02/2015 11:14 AM, Florian Weimer wrote:
>>>>> I think it's needed for a high-quality implementation of getrandom with
>>>>> an emulation that cannot fail.
>>>>
>>>> Exactly what failure modes are you considering?
>>>
>>> First call to getrandom after chroot, or in a rarely-executed error
>>> handler.  (The latter is not as obscure at it sounds, sometimes
>>> randomness is recommended as a way to obfuscate the case of a
>>> cryptography-related failure.)
>>
>> I still don't understand the use case.
>>
>> Could you please expand on this a bit?
> 
> Most programmers who call functions like getrandom do not check the
> result for errors.  Therefore, the kernel added a system call that will
> not fail[*].  If we expose it directly, this does not fly because
> programmers would have to check for ENOSYS.
> 
> So in order to provide it, we need an emulation, but which cannot fail
> either.  The emulation needs to open /dev/urandom.  This could fail due
> to lack of file descriptors, or after a chroot/namespace operation.
> Therefore, we should open the descriptor early (and relocate it beyond
> the 1024 limit).
> 
> I do not want to open /dev/urandom at the start of every process, only
> for those processes that reference getrandom, and the kernel does not
> provide support for it.  I want to use the IFUNC mechanism to detect
> that.  But unless BIND_NOW is active, this will be too late.
> 
> There are some other system call wrappers where we might want to gather
> such information (such as execve).
> 
> [*] Some caveats apply, like EFAULT.  Details are a bit messy, but we
> can hide them in the glibc wrapper.

Perfectly understood. Thanks.

An "Early IFUNC", interesting idea. It has some problems, but we can
discuss this later in detail. For example having all the dependent things
the resolver needs setup early also?

Cheers,
Carlos.
 



More information about the Libc-help mailing list