Better handling of Valgrind false-positive

[jeronstone]

BSL/src/crypto/CryptoInterface.c

Lines 552 to 554 in 4a9fc76

	#if defined(HAVE_VALGRIND)
	VALGRIND_MAKE_MEM_DEFINED(*tag, BSL_CRYPTO_AESGCM_AUTH_TAG_LEN);
	#endif /* defined(HAVE_VALGRIND) */

If there's a way, figure out how to get Valgrind to ignore the false-positive "uninitialized buffer" after calling into OpenSSL - without modifying source as done currently. Issue currently only happening with CLang

[paulfloyd]

I doubt that its a false positive.

More likely the cause is deliberate and harmless use of UB. Quite often str* mem* and crypto functions use simd/crypto opcodes deliberately read memory up to the the multiple of the allocation granularity (typically 16 bytes). For instance if you malloc a 100 byte buffer, libc will give you 112 bytes. Valgrind will still record that you asked for 100 bytes. If you then use come simd/crypto opcodes that deliberately read as far as 112 bytes then memcheck will likely complain about those 12 bytes read beyond the end of the valid memory. Memcheck is already being generous in treating those extra bytes as addressable (but uninitialised).

To be certain you will need to debug down to the machine code level. Even then, there is not a lot you can do if this is in libssl or similar.