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