1a8e1175bSopenharmony_ci# test_zeroize.gdb
2a8e1175bSopenharmony_ci#
3a8e1175bSopenharmony_ci# Copyright The Mbed TLS Contributors
4a8e1175bSopenharmony_ci# SPDX-License-Identifier: Apache-2.0 OR GPL-2.0-or-later
5a8e1175bSopenharmony_ci#
6a8e1175bSopenharmony_ci# Purpose
7a8e1175bSopenharmony_ci#
8a8e1175bSopenharmony_ci# Run a test using the debugger to check that the mbedtls_platform_zeroize()
9a8e1175bSopenharmony_ci# function in platform_util.h is not being optimized out by the compiler. To do
10a8e1175bSopenharmony_ci# so, the script loads the test program at programs/test/zeroize.c and sets a
11a8e1175bSopenharmony_ci# breakpoint at the last return statement in main(). When the breakpoint is
12a8e1175bSopenharmony_ci# hit, the debugger manually checks the contents to be zeroized and checks that
13a8e1175bSopenharmony_ci# it is actually cleared.
14a8e1175bSopenharmony_ci#
15a8e1175bSopenharmony_ci# The mbedtls_platform_zeroize() test is debugger driven because there does not
16a8e1175bSopenharmony_ci# seem to be a mechanism to reliably check whether the zeroize calls are being
17a8e1175bSopenharmony_ci# eliminated by compiler optimizations from within the compiled program. The
18a8e1175bSopenharmony_ci# problem is that a compiler would typically remove what it considers to be
19a8e1175bSopenharmony_ci# "unnecessary" assignments as part of redundant code elimination. To identify
20a8e1175bSopenharmony_ci# such code, the compilar will create some form dependency graph between
21a8e1175bSopenharmony_ci# reads and writes to variables (among other situations). It will then use this
22a8e1175bSopenharmony_ci# data structure to remove redundant code that does not have an impact on the
23a8e1175bSopenharmony_ci# program's observable behavior. In the case of mbedtls_platform_zeroize(), an
24a8e1175bSopenharmony_ci# intelligent compiler could determine that this function clears a block of
25a8e1175bSopenharmony_ci# memory that is not accessed later in the program, so removing the call to
26a8e1175bSopenharmony_ci# mbedtls_platform_zeroize() does not have an observable behavior. However,
27a8e1175bSopenharmony_ci# inserting a test after a call to mbedtls_platform_zeroize() to check whether
28a8e1175bSopenharmony_ci# the block of memory was correctly zeroed would force the compiler to not
29a8e1175bSopenharmony_ci# eliminate the mbedtls_platform_zeroize() call. If this does not occur, then
30a8e1175bSopenharmony_ci# the compiler potentially has a bug.
31a8e1175bSopenharmony_ci#
32a8e1175bSopenharmony_ci# Note: This test requires that the test program is compiled with -g3.
33a8e1175bSopenharmony_ci
34a8e1175bSopenharmony_ciset confirm off
35a8e1175bSopenharmony_ci
36a8e1175bSopenharmony_cifile ./programs/test/zeroize
37a8e1175bSopenharmony_ci
38a8e1175bSopenharmony_cisearch GDB_BREAK_HERE
39a8e1175bSopenharmony_cibreak $_
40a8e1175bSopenharmony_ci
41a8e1175bSopenharmony_ciset args ./programs/test/zeroize.c
42a8e1175bSopenharmony_cirun
43a8e1175bSopenharmony_ci
44a8e1175bSopenharmony_ciset $i = 0
45a8e1175bSopenharmony_ciset $len = sizeof(buf)
46a8e1175bSopenharmony_ciset $buf = buf
47a8e1175bSopenharmony_ci
48a8e1175bSopenharmony_ciwhile $i < $len
49a8e1175bSopenharmony_ci    if $buf[$i++] != 0
50a8e1175bSopenharmony_ci        echo The buffer at was not zeroized\n
51a8e1175bSopenharmony_ci        quit 1
52a8e1175bSopenharmony_ci    end
53a8e1175bSopenharmony_ciend
54a8e1175bSopenharmony_ci
55a8e1175bSopenharmony_ciecho The buffer was correctly zeroized\n
56a8e1175bSopenharmony_ci
57a8e1175bSopenharmony_cicontinue
58a8e1175bSopenharmony_ci
59a8e1175bSopenharmony_ciif $_exitcode != 0
60a8e1175bSopenharmony_ci    echo The program did not terminate correctly\n
61a8e1175bSopenharmony_ci    quit 1
62a8e1175bSopenharmony_ciend
63a8e1175bSopenharmony_ci
64a8e1175bSopenharmony_ciquit 0
65