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

[Zack Weinberg <zackw at panix dot com>]

On Wed, Dec 7, 2016 at 6:18 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 12/06/2016 07:42 PM, Zack Weinberg wrote:
>> 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 [...]
>
> I see your point, but with the original patch with mangling, you had to
> interpose __libc_getrandom and getrandom.  With the current patch (if we
> remove mangling), you still have to interpose getrandom and getentropy. If
> we add arc4random, you will have to interpose that as well.  And so on.

So I guess the hypothetical software I'm thinking of comes from the
BSD universe and already knows about getrandom, getentropy,
arc4random, and all the other public RNG APIs (OpenBSD now implements
everything from rand() on up with an auto-seeded CSPRNG) but not the
__libc_* names.  As you say, though, some porting work is going to be
required regardless, and finding out about the additional symbols is
not that much of a speedbump.

>> 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).
>
> I already explained why we cannot fix this in the linker.  We need to put
> *something* in the header, too.  At that point, we can just use name
> mangling, which is supported by the toolchain, today.

Let's push this part of the conversation back into the other thread -
I'll respond to your last message there later today.

>> 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.
>
> If we put this in soon (without mangling), I can probably finish a test mass
> rebuild of Fedora before the 2.25 release.  This should give us some data.

That sounds like a plan to me.  Once the patch lands, I can try to
find someone who can do a Debian archive rebuild too.

zw