Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
runtime: buildmode=c-shared libraries on Linux all reuse AT_RANDOM bits from aux vector #16017
Please answer these questions before submitting your issue. Thanks!
go version devel +f3689d1 Wed Jun 8 20:35:53 2016 +0000 linux/amd64
If any number of go libraries built in buildmode=c-shared are loaded into the same program they will all seed their random number generator using the same 16 bytes from the initial processes AT_RANDOM entry in the auxiliary vector.
Shared libraries seeding themselves with different values either by calling the host libc's rand() when loaded from a C shared library or by reading from /dev/urandom explicitly.
glibc's dlopen() passes a pointer to the hosting process' argc which is propagated through to the src/runtime argument parsing routine which identifies the AT_RANDOM tagged data in the auxv section and populates startupRandomData bytes here:
which is then seeded into the runtime's random number generator (mixed in with a call to nanotime() which will very likely but not always differ from library to library).
In practice this means multiple shared libraries in the same address space will have less initial randomness than might be expected. This should not cause problems in properly written applications but may be surprising.
I don't see how this could cause a problem. These random numbers are only used by the runtime, they are not provided to the application.
The application might see them indirectly, via map iterator order, scheduling decisions, etc. But if anyone is depending on these things being different/independent across shared libraries, they are depending on implementation details not promised by Go.
changed the title
Buildmode=c-shared libraries on Linux all reuse AT_RANDOM bits from aux vector
Jun 9, 2016
By that reasoning, why seed the runtime with random bits from the auxv in any case? The runtime would initialize faster if it did not copy these bytes out of the auxv and seed its PRNG with it.
I agree this shouldn't break any correct program or cause any obvious issues, but it may cause subtle issues. For example a program using many shared libraries could behave more poorly than expected due to the runtimes in each shared library having correlated rather than independent initial random state. This appears to be an artifact of the way the code is structured rather than a deliberate choice so seems worth examining in more detail.
The AT_RANDOM data is only used to seed the hash function for maps. We do that to make the hash function unpredictable, which helps prevent hash flooding attacks. That works equally well if one or twelve shared libraries use the same seed. As far as I can see, there's no issue here.