A while ago I wrote

> I'm considering adding more tests depending on valgrind, so
> then it would be nice to include valgrind in the image.

A first working version of this is now implemented. There are only a few
such tests so far: sc-cnd-memcpy-test, sc-gcm-test, sc-memeql-test,
sc-pkcs1-sec-decrypt-test, and sc-rsa-sec-decrypt-test. Adding test will
be a good way to both verify that, e.g., curve25519 is side-channel
silent, and get a bit more confidence for documenting which Nettle
functions are supposed to be side-channel silent.

To walk through how this works, the new tests are script wrappers
running the non-sc version of the test, e.g., sc-gcm-test looks like

  #! /bin/sh
  
  srcdir=`dirname $0`
  . "${srcdir}/sc-valgrind.sh"
  
  with_valgrind ./gcm-test

In turn, with_valgrind is simple shell function defined like

  with_valgrind () {
      type valgrind >/dev/null 2>&1 || exit 77
      NETTLE_TEST_SIDE_CHANNEL=1 valgrind -q --exit-on-first-error=yes 
--error-exitcode=1 "$@"
  }

The environment variable NETTLE_TEST_SIDE_CHANNEL is checked by the
main function shared by all test programs,

  if (getenv("NETTLE_TEST_SIDE_CHANNEL"))
    {
  #if HAVE_VALGRIND_MEMCHECK_H
      if (RUNNING_ON_VALGRIND)
        test_side_channel = 1;
      else
  #endif
        SKIP();
    }

The actual test code, in this case, gcm-test.c, calls utility functions
mark_bytes_undefined and mark_bytes_defined, which are usually no-ops,
but when valgrind is available, active, and NETTLE_TEST_SIDE_CHANNEL was
set, they use VALGRIND_MAKE_MEM_UNDEFINED and VALGRIND_MAKE_MEM_DEFINED.
In this case, it's the internal ghash functions that are tested in this
way, not the higher level gcm functions.

The tests are running in the gitlab ci for x86_64. I think it should be
easy to enable also for 32-bit x86 builds (I just need to figure out if
apt-get install libc6-dbg:i386 is the right way to get valgrind to work
for 32-bit executables).

I would like to have valgrind tests in the ci also for other archs that
are supported by valgrind. Maybe that requires native builds (on real
hardware, or qemu system emulation), maybe it would be possible to do
something like

  qemu-aarch64 /usr/aarch64-linux-gnu/bin/valgrind ./foo-test

where foo-test is a cross-compiled arm64 executable? Other options?

Regards,
/Niels

-- 
Niels Möller. PGP key CB4962D070D77D7FCB8BA36271D8F1FF368C6677.
Internet email is subject to wholesale government surveillance.

_______________________________________________
nettle-bugs mailing list -- nettle-bugs@lists.lysator.liu.se
To unsubscribe send an email to nettle-bugs-le...@lists.lysator.liu.se

Reply via email to