Re: [PATCH v9] Add getentropy, getrandom, <sys/random.h> [BZ #17252]

[Zack Weinberg <zackw at panix dot com>]

On 12/06/2016 12:11 PM, Zack Weinberg wrote:
> 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.

I should probably explain why I think the mangled names may be an
actively *bad* idea; I wouldn't be making so much of a fuss over it
otherwise.

The most direct reason is that it interferes with code that seeks
*intentionally* to interpose symbols.  There are good reasons to
intercept calls to the system RNG: for instance, a test harness might
want to sub in a broken implementation to confirm that the error
handling works, another kind of test harness might want to fix the
random seed for reproducibility, and if we ever need to stop using the
kernel's RNG in a hurry, LD_PRELOAD will be the fastest way to go about
it.  There *probably* isn't any existing code *for Linux* that
intentionally interposes functions that currently don't exist in glibc,
but there could be such code for one of the BSDs and maybe someone is
just waiting for us to pick up getentropy/getrandom before they port it.

A more abstract reason is that, as discussed elsewhere, I think the
problem (to the extent I do understand it) would be better addressed
with an across-the-board change to linker semantics, and if we're going
to do that, it doesn't make sense to put in stopgaps that we will then
be stuck with forever (even if just as compatibility aliases).

Having said that, if someone does do an archive rebuild and finds a
concrete case where existing code _will_ generate a bad unintentional
interposition of either getentropy or getrandom, then the security
implications would swing me in favor of going ahead and doing the
REDIRECTs, since it is the only solution we've got at the moment and we
do want these functions in 2.25.  I'll accept any executable or
_dynamic_ library that winds up defining either getentropy or getrandom
as a public symbol with either an incompatible function signature or
incompatible primary semantics.  I'm not going to insist on there being
a known situation where that would actually cause some second module to
get the wrong definition, since it would be basically impossible to
prove that that _couldn't_ happen.

(The getdns case doesn't convince me because the symbol isn't exported
and it appears to be a _compatible_ definition.)

zw