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 v9] Add getentropy, getrandom, <sys/random.h> [BZ #17252]


On 12/06/2016 09:03 AM, Florian Weimer wrote:
> On 12/06/2016 02:41 PM, Zack Weinberg wrote:
>>
>> My only other remaining concern is the name mangling, and unfortunately
>> we really do have to resolve that before this can be committed, because
>> we'll be stuck with whatever decision we make here forever.
>>
>> I still don't really understand what problems you are trying to solve by
>> mangling names, I still think that ad-hoc addition of mangled names with
>> forcible redirection in the headers is unlikely to be the *correct* fix
>> to whatever the problems actually are, and most importantly of all, I
>> still don't understand why you are convinced *these particular symbols*
>> need "interposition protection".
> 
> They are special because interposition of a function which does
> something else will not always cause observable behavior differences. If
> an application redefines fread so that nothing is actually read from the
> stream, then this is pretty obvious.  If getrandom or getentropy stop
> overwriting their argument buffers, then that's not going to cause
> immediate breakage.

I'll accept this as a reason why getrandom and getentropy may need some
kind of special treatment that we don't necessarily apply to other new
symbols.

>> A concrete example of a real program or combination of programs, that
>> will break if we don't do this, would be really helpful to me.  Not a
>> demo, please, something that already exists in the wild.
> 
> Here's an example, I think:
> 
> <http://sources.debian.net/src/getdns/1.1.0~a2-1/src/compat/getentropy_linux.c/?hl=107#L107>

It appears to me that this is not an example of a "real program or
combination of programs that _will break_ if we don't do this" because:

* It defines getentropy() with the same signature and substantially the
same semantics as libc is going to.

* Its configure script does, in fact, check for getentropy before adding
getentropy_linux.c to the build.

* It's a library, and it has a version script, so even if it does define
getentropy internally, programs built normally will not see that
definition.  (I remind you that I don't care about static linkage.)

zw


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