2017-10-24 23:47:14 +02:00
|
|
|
# test_zeroize.gdb
|
|
|
|
#
|
|
|
|
# This file is part of mbed TLS (https://tls.mbed.org)
|
|
|
|
#
|
|
|
|
# Copyright (c) 2017, ARM Limited, All Rights Reserved
|
|
|
|
#
|
|
|
|
# Purpose
|
|
|
|
#
|
|
|
|
# Run a test using the debugger to check that the mbedtls_zeroize() function in
|
|
|
|
# utils.h is not being optimized out by the compiler. To do so, the script
|
|
|
|
# loads the test program at programs/test/zeroize.c and sets a breakpoint at
|
|
|
|
# the last return statement in the main(). When the breakpoint is hit, the
|
|
|
|
# debugger manually checks the contents to be zeroized and checks that it is
|
|
|
|
# actually cleared.
|
|
|
|
#
|
2018-03-08 22:21:40 +01:00
|
|
|
# The mbedtls_zeroize() test is debugger driven because there does not seem to
|
|
|
|
# be a mechanism to reliably check whether the zeroize calls are being
|
|
|
|
# eliminated by compiler optimizations from within the compiled program. The
|
|
|
|
# problem is that a compiler would typically remove what it considers to be
|
|
|
|
# "unecessary" assignments as part of redundant code elimination. To identify
|
|
|
|
# such code, the compilar will create some form dependency graph between
|
|
|
|
# reads and writes to variables (among other situations). It will then use this
|
|
|
|
# data structure to remove redundant code that does not have an impact on the
|
|
|
|
# program's observable behavior. In the case of mbedtls_zeroize(), an
|
|
|
|
# intelligent compiler could determine that this function clears a block of
|
|
|
|
# memory that is not accessed later in the program, so removing the call to
|
|
|
|
# mbedtls_zeroize() does not have an observable behavior. However, inserting a
|
|
|
|
# test after a call to mbedtls_zeroize() to check whether the block of
|
|
|
|
# memory was correctly zeroed would force the compiler to not eliminate the
|
|
|
|
# mbedtls_zeroize() call. If this does not occur, then the compiler potentially
|
|
|
|
# has a bug.
|
|
|
|
#
|
2017-10-24 23:47:14 +02:00
|
|
|
# Note: This test requires that the test program is compiled with -g3.
|
2018-03-08 22:21:40 +01:00
|
|
|
#
|
|
|
|
# WARNING: There does not seem to be a mechanism in GDB scripts to set a
|
|
|
|
# breakpoint at the end of a function (probably because there are a lot of
|
|
|
|
# complications as function can have multiple exit points, etc). Therefore, it
|
|
|
|
# was necessary to hard-code the line number of the breakpoint in the zeroize.c
|
|
|
|
# test app. The assumption is that zeroize.c is a simple test app that does not
|
|
|
|
# change often (as opposed to the actual library code), so the breakpoint line
|
|
|
|
# number does not need to be updated often.
|
2017-10-24 23:47:14 +02:00
|
|
|
|
2017-10-24 23:16:34 +02:00
|
|
|
set confirm off
|
|
|
|
file ./programs/test/zeroize
|
2018-03-08 22:21:40 +01:00
|
|
|
break zeroize.c:99
|
2017-10-24 23:16:34 +02:00
|
|
|
|
|
|
|
set args ./programs/test/zeroize.c
|
|
|
|
run
|
|
|
|
|
|
|
|
set $i = 0
|
|
|
|
set $len = sizeof(buf)
|
|
|
|
set $buf = buf
|
|
|
|
|
|
|
|
while $i < $len
|
|
|
|
if $buf[$i++] != 0
|
|
|
|
echo The buffer at was not zeroized\n
|
|
|
|
quit 1
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
echo The buffer was correctly zeroized\n
|
2017-11-01 11:03:36 +01:00
|
|
|
|
|
|
|
continue
|
|
|
|
|
|
|
|
if $_exitcode != 0
|
|
|
|
echo The program did not terminate correctly\n
|
|
|
|
quit 1
|
|
|
|
end
|
|
|
|
|
2017-10-24 23:16:34 +02:00
|
|
|
quit 0
|