[botan-devel] version 1.10 and Valgrind
lloyd at randombit.net
Thu Jan 28 08:42:12 EST 2016
The change in 1.11.26 shouldn't have any relation to the issue you're
seeing. In 1.11 there is support for checking that certain operations
really do run in const time (that is, without branches or indexes
which depend on secret values); in versions before 1.11.26 this
required a specially patched version of valgrind. But this feature is
not even included in 1.10, isn't compiled in by default in 1.11, and
anyway shouldn't cause any problems like the one you're seeing here.
My best guess, given that this is occuring during the reseed step, is
that RDRAND is not being handled by valgrind. From these bug reports
this seems to be the case; valgrind 3.11's emulated CPU advertises
RDRAND support but does not implement it, causing a crash when the
application tries to execute it. The KDE bug contains a patch to
valgrind which clears the RDRAND bit, which was reported as fixing the
problem for others and is already committed to valgrind trunk.
Apparently Valgrind 3.10 also works without issue.
If you're not running on a CPU which supports RDRAND then my
guess goes completely out the window.
You can also work around this by building a new libbotan adding the
configure.py flag `--disable-modules=rdrand`. There is not currently
any way of disabling an entropy source at the application level
without a rebuild (this is probably a bug...)
On Thu, Jan 28, 2016 at 10:06:09AM +0100, Yuri Schaeffer wrote:
> Our software uses SoftHSM which in turn links against libbotan. When I
> try to run it in Valgrind, Valgrind will keep spewing this message as
> fast as it can. Making debugging with this tool impossible for me.
> ==23139== valgrind: Unrecognised instruction at address 0xb1628b2.
> ==23139== at 0xB1628B2: ??? (in /usr/lib/libbotan-1.10.so.1.10)
> ==23139== by 0xB2538AB: Botan::HMAC_RNG::reseed(unsigned long) (in
More information about the botan-devel