blob: c6184ee60a1415dcdf0c34332d7fbf4dfa3be27e [file] [log] [blame]
Andres Amaya Garciaf2d17922017-10-24 22:47:14 +01001# test_zeroize.gdb
2#
3# This file is part of mbed TLS (https://tls.mbed.org)
4#
5# Copyright (c) 2017, ARM Limited, All Rights Reserved
6#
7# Purpose
8#
9# Run a test using the debugger to check that the mbedtls_zeroize() function in
10# utils.h is not being optimized out by the compiler. To do so, the script
11# loads the test program at programs/test/zeroize.c and sets a breakpoint at
12# the last return statement in the main(). When the breakpoint is hit, the
13# debugger manually checks the contents to be zeroized and checks that it is
14# actually cleared.
15#
Andres Amaya Garcia42defd12018-03-08 21:21:40 +000016# The mbedtls_zeroize() test is debugger driven because there does not seem to
17# 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# "unecessary" 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_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_zeroize() does not have an observable behavior. However, inserting a
28# test after a call to mbedtls_zeroize() to check whether the block of
29# memory was correctly zeroed would force the compiler to not eliminate the
30# mbedtls_zeroize() call. If this does not occur, then the compiler potentially
31# has a bug.
32#
Andres Amaya Garciaf2d17922017-10-24 22:47:14 +010033# Note: This test requires that the test program is compiled with -g3.
Andres Amaya Garcia42defd12018-03-08 21:21:40 +000034#
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.
Andres Amaya Garciaf2d17922017-10-24 22:47:14 +010042
Andres Amaya Garciaddebc492017-10-24 22:16:34 +010043set confirm off
44file ./programs/test/zeroize
Andres Amaya Garcia42defd12018-03-08 21:21:40 +000045break zeroize.c:99
Andres Amaya Garciaddebc492017-10-24 22:16:34 +010046
47set args ./programs/test/zeroize.c
48run
49
50set $i = 0
51set $len = sizeof(buf)
52set $buf = buf
53
Andres Amaya Garciaddebc492017-10-24 22:16:34 +010054while $i < $len
55 if $buf[$i++] != 0
56 echo The buffer at was not zeroized\n
57 quit 1
58 end
59end
60
61echo The buffer was correctly zeroized\n
Andres Amaya Garcia806f4032017-11-01 10:03:36 +000062
63continue
64
65if $_exitcode != 0
66 echo The program did not terminate correctly\n
67 quit 1
68end
69
Andres Amaya Garciaddebc492017-10-24 22:16:34 +010070quit 0