Some ASan failures go undetected in all.sh #303

New issue

Closed

opened 2019-10-21 06:18:23 -05:00 by gilles-peskine-arm · 2 comments

gilles-peskine-arm commented

2019-10-21 06:18:23 -05:00

(Migrated from github.com)

Description

We use the following idiom in several components of all.sh:

make CFLAGS='-fsanitize=address …' LDFLAGS='-fsanitize=address …'
make test

If the tests pass functionally but ASan detects a memory leak, make test succeeds. We can see a message like “SUMMARY: AddressSanitizer: 544 byte(s) leaked in 83 allocation(s).” in the logs, but only if we go and look for it.

The reason is that run-test-suites.pl considers a test suite as passing if it displays the string PASSED. An Asan failure at the end of the program, such as a memory leak, is not counted as a failure.

This affects both Mbed Crypto and Mbed TLS.

Builds using CMake (e.g. cmake -D CMAKE_BUILD_TYPE=Asan) are not affected because they use CMake's ctest utility rather than run-test-suites.pl.

The affected components are:

test_m32_o0, test_m32_o1 and test_m32_everest in both Mbed Crypto and Mbed TLS.
test_malloc_0_null, test_se_default and test_se_full in Mbed Crypto.

Current status: one memory leak has gone undetected in mbed-crypto/development, none in mbedtls/development. The leak is in test_suite_psa_crypto_se_driver_hal (in test code, not in product code), detected in the components that enable SE support (test_se_default and test_se_full). Example log: https://jenkins-internal.mbed.com/job/mbedtls-psa-release-new/587/execution/node/1066/log/

Issue request type

[ ] Question
[ ] Enhancement
[x] Bug

### Description We use the following idiom in several components of `all.sh`: ``` make CFLAGS='-fsanitize=address …' LDFLAGS='-fsanitize=address …' make test ``` If the tests pass functionally but ASan detects a memory leak, `make test` succeeds. We can see a message like “SUMMARY: AddressSanitizer: 544 byte(s) leaked in 83 allocation(s).” in the logs, but only if we go and look for it. The reason is that `run-test-suites.pl` considers a test suite as passing if it displays the string `PASSED`. An Asan failure at the end of the program, such as a memory leak, is not counted as a failure. This affects both Mbed Crypto and Mbed TLS. Builds using CMake (e.g. `cmake -D CMAKE_BUILD_TYPE=Asan`) are not affected because they use CMake's `ctest` utility rather than `run-test-suites.pl`. The affected components are: * `test_m32_o0`, `test_m32_o1` and `test_m32_everest` in both Mbed Crypto and Mbed TLS. * `test_malloc_0_null`, `test_se_default` and `test_se_full` in Mbed Crypto. Current status: one memory leak has gone undetected in `mbed-crypto/development`, none in `mbedtls/development`. The leak is in `test_suite_psa_crypto_se_driver_hal` (in test code, not in product code), detected in the components that enable SE support (`test_se_default` and `test_se_full`). Example log: https://jenkins-internal.mbed.com/job/mbedtls-psa-release-new/587/execution/node/1066/log/ ### Issue request type [ ] Question [ ] Enhancement [x] Bug

gilles-peskine-arm commented

2019-10-21 08:28:01 -05:00

(Migrated from github.com)

Based on the GCC documentation:

-fsanitize=address requires gcc ≥4.8
-fsanitize=undefined requires gcc ≥4.9
-fno-sanitize-recover=all requires gcc ≥5.1

Do we still care about older versions?

Based on the GCC documentation: * `-fsanitize=address` requires gcc ≥4.8 * `-fsanitize=undefined` requires gcc ≥4.9 * `-fno-sanitize-recover=all` requires gcc ≥5.1 [Do we still care about older versions?](https://github.com/ARMmbed/mbedtls/issues/2896)

ciarmcom commented

2019-10-22 07:14:58 -05:00

(Migrated from github.com)