third_party/mbedtls/repo/tests/scripts/test_zeroize.gdb

   1 # test_zeroize.gdb
   2 #
   3 # This file is part of Mbed TLS (https://tls.mbed.org)
   4 #
   5 # Copyright (c) 2018, Arm Limited, All Rights Reserved
   6 #
   7 # Purpose
   8 #
   9 # Run a test using the debugger to check that the mbedtls_platform_zeroize()
  10 # function in platform_util.h is not being optimized out by the compiler. To do
  11 # so, the script loads the test program at programs/test/zeroize.c and sets a
  12 # breakpoint at the last return statement in main(). When the breakpoint is
  13 # hit, the debugger manually checks the contents to be zeroized and checks that
  14 # it is actually cleared.
  15 #
  16 # The mbedtls_platform_zeroize() test is debugger driven because there does not
  17 # seem to be a mechanism to reliably check whether the zeroize calls are being
  18 # eliminated by compiler optimizations from within the compiled program. The
  19 # problem is that a compiler would typically remove what it considers to be
  20 # "unnecessary" assignments as part of redundant code elimination. To identify
  21 # such code, the compilar will create some form dependency graph between
  22 # reads and writes to variables (among other situations). It will then use this
  23 # data structure to remove redundant code that does not have an impact on the
  24 # program's observable behavior. In the case of mbedtls_platform_zeroize(), an
  25 # intelligent compiler could determine that this function clears a block of
  26 # memory that is not accessed later in the program, so removing the call to
  27 # mbedtls_platform_zeroize() does not have an observable behavior. However,
  28 # inserting a test after a call to mbedtls_platform_zeroize() to check whether
  29 # the block of memory was correctly zeroed would force the compiler to not
  30 # eliminate the mbedtls_platform_zeroize() call. If this does not occur, then
  31 # the compiler potentially has a bug.
  32 #
  33 # Note: This test requires that the test program is compiled with -g3.
  34 #
  35 # WARNING: There does not seem to be a mechanism in GDB scripts to set a
  36 # breakpoint at the end of a function (probably because there are a lot of
  37 # complications as function can have multiple exit points, etc). Therefore, it
  38 # was necessary to hard-code the line number of the breakpoint in the zeroize.c
  39 # test app. The assumption is that zeroize.c is a simple test app that does not
  40 # change often (as opposed to the actual library code), so the breakpoint line
  41 # number does not need to be updated often.
  42
  43 set confirm off
  44
  45 file ./programs/test/zeroize
  46 break zeroize.c:100
  47
  48 set args ./programs/test/zeroize.c
  49 run
  50
  51 set $i = 0
  52 set $len = sizeof(buf)
  53 set $buf = buf
  54
  55 while $i < $len
  56     if $buf[$i++] != 0
  57         echo The buffer at was not zeroized\n
  58         quit 1
  59     end
  60 end
  61
  62 echo The buffer was correctly zeroized\n
  63
  64 continue
  65
  66 if $_exitcode != 0
  67     echo The program did not terminate correctly\n
  68     quit 1
  69 end
  70
  71 quit 0