A single program that invokes getrandom() repeatedly should end up
with the same stream of bytes, regardless of how it chunks up the
reading from the entropy source.
This test already passses. I'm including it because it seems
like a useful confirmation.
This is an attempt at an implementation to address #301.
Some things worth noting:
- I am not particularly confident in my reverse of the variadic C
ABI. While the code appears to work for me on x86_64, I could
imagine some variations between platforms that I'm not
understanding.
- This works to intercept the invocation of syscall as seen in
test/syscalltest.sh, as long as it was compiled with -DFAKE_RANDOM
- defining -DINTERCEPT_SYSCALL on non-Linux platforms should result
in a compile-time error.
- This does *not* work to intercept the syscall sent by `openssl
rand`, for some reason I don't yet understand. Perhaps openssl has
some platform-specific syscall mechanism that doesn't route them
through libc's syscall() shim?
In some configurations, GNU make might treat librandom.so as an
ephemeral/intermediate build artifact and destroy it before
randomtest.sh is run. This ensures the shared object is present when
needed.
Previously, we had failed to test code with getrandom() against
LD_PRELOAD when FAKERANDOM_SEED was unset.
We also want to try calling getrandom twice in a single process to
make sure that works OK.
In trying to test the experimental getrandom features, I found a few
minor problems. These changes should make it easier to test.
After building, the developer can now just do:
make -C test randomtest
This will do a basic verfication that the feature works as expected.
I haven't tried to integrate this with the overall "make test". To do
that right, it should condition the test on the definition of
FAKE_RANDOM.
On Ubuntu 20.04 using gcc 9.3, make test fails due to a deprecated
function (ftime) warning in combination with -Werror in timetest.c.
Since the warning is from a test testing that the deprecated function
can be replaced using LD_PRELOAD, I think it's reasonable to just
silence the warning in that case.
pthread_cond_timedwait takes an absolute time as an argument, which
the function directly passes on to the kernel via the futex
syscall. In an application this absolute time argument is calculated
via the fake times provided by libfaketime. Since the kernel has no
knowledge of the fake time, pthread_cond_timedwait must be redefined
such that it converts the fake time back to real time before passing
it on.
Since SmartOS is close to SunOS, it's possible that these changes make
libfaketime build and run on other SunOS-like platforms.
These changes were tested on MacOS X and Ubuntu 12.04, and no regression
appeared during testing.
--exclude-monotonic prevents faketime from overriding
the clock with id CLOCK_MONOTONIC when using clock_gettime.
Add DONT_FAKE_MONOTONIC env variable to libfaketime that
has the same effect.
Add functional test for DONT_FAKE_MONOTONIC support.
