UBSAN & load/store of misaligned address

[karel-m]

trafficstars

UBSAN (UndefinedBehaviorSanitizer) reports the following issues on current release/1.18.0 (all related to LTC_FAST_TYPE):

src/modes/ctr/ctr_encrypt.c:91:60: runtime error: load of misaligned address 0x00000182dadc for type 'LTC_FAST_TYPE' (aka 'unsigned long long'), which requires 8 byte alignment
src/modes/ctr/ctr_encrypt.c:90:66: runtime error: load of misaligned address 0x7ffc08d68901 for type 'LTC_FAST_TYPE' (aka 'unsigned long long'), which requires 8 byte alignment
src/modes/ctr/ctr_encrypt.c:90:13: runtime error: store to misaligned address 0x7ffc08d68901 for type 'LTC_FAST_TYPE' (aka 'unsigned long long'), which requires 8 byte alignment
tests/store_test.c:72:52: runtime error: load of misaligned address 0x7ffc08d68901 for type 'LTC_FAST_TYPE' (aka 'unsigned long long'), which requires 8 byte alignment
tests/store_test.c:72:91: runtime error: load of misaligned address 0x7ffc08d68911 for type 'LTC_FAST_TYPE' (aka 'unsigned long long'), which requires 8 byte alignment
tests/store_test.c:72:9: runtime error: store to misaligned address 0x7ffc08d68931 for type 'LTC_FAST_TYPE' (aka 'unsigned long long'), which requires 8 byte alignment
src/mac/pmac/pmac_process.c:49:50: runtime error: load of misaligned address 0x0000007a9f4c for type 'LTC_FAST_TYPE' (aka 'unsigned long long'), which requires 8 byte alignment
src/mac/omac/omac_process.c:50:17: runtime error: store to misaligned address 0x62100001698c for type 'LTC_FAST_TYPE' (aka 'unsigned long long'), which requires 8 byte alignment
src/mac/xcbc/xcbc_process.c:48:60: runtime error: load of misaligned address 0x0000007ab6cc for type 'LTC_FAST_TYPE' (aka 'unsigned long long'), which requires 8 byte alignment
src/mac/f9/f9_process.c:45:58: runtime error: load of misaligned address 0x0000007a5df4 for type 'LTC_FAST_TYPE' (aka 'unsigned long long'), which requires 8 byte alignment
src/encauth/gcm/gcm_process.c:92:58: runtime error: load of misaligned address 0x000000785834 for type 'LTC_FAST_TYPE' (aka 'unsigned long long'), which requires 8 byte alignment
src/modes/f8/f8_encrypt.c:65:86: runtime error: load of misaligned address 0x7ffc08d63e3c for type 'LTC_FAST_TYPE' (aka 'unsigned long long'), which requires 8 byte alignment
src/modes/f8/f8_encrypt.c:66:55: runtime error: load of misaligned address 0x7ffc08d63ebc for type 'LTC_FAST_TYPE' (aka 'unsigned long long'), which requires 8 byte alignment
src/modes/f8/f8_encrypt.c:66:14: runtime error: store to misaligned address 0x7ffc08d63e3c for type 'LTC_FAST_TYPE' (aka 'unsigned long long'), which requires 8 byte alignment
src/modes/lrw/lrw_process.c:61:15: runtime error: store to misaligned address 0x7ffc08d53f04 for type 'LTC_FAST_TYPE' (aka 'unsigned long long'), which requires 8 byte alignment

This is just FYI, I have no suggestion what to do (I am even in doubts whether we can or should do anything).

Can be reproduced by:

make -f makefile.unix clean
make -f makefile.unix LDFLAGS="-fsanitize=undefined" CC=clang CFLAGS="-g -fsanitize=undefined -DUSE_LTM -DLTM_DESC -I../libtommath" EXTRALIBS=../libtommath/libtommath.a all
UBSAN_OPTIONS=verbosity=1 ./test

[karel-m]

Update: with -DLTC_NO_FAST no UBSAN issues in release/1.18.0

[andreyv]

This is relevant: http://dbp-consulting.com/tutorials/StrictAliasing.html

It explains the problem and lists possible solutions.

[sjaeckel]

Well I doubt there's a fix for this feature which deliberately exists to (ab)use a potential CPU/architecture feature where unaligned accesses are handled as if the access was aligned to get some speed. The easiest fix is defining LTC_NO_FAST if you've a problem with this behavior.

Or do you think any of the solutions on that page could be implemented here to solve this aliasing problem @andreyv @karel-m ?

If not I think we can close this.

[andreyv]

Well, if the intent is to explicitly load unaligned integers, then two possible choices are to either leave it like it is now (in practice this may "work", I see there is a may_alias attribute), or change the macros to do a union or memcpy operation as described in the linked article.

[sjaeckel]

As the target of this optimization is speed, the memcpy approach obviously won't work. IIUC the union approach also involves copying the data and thereby is also useless. I'd say we leave it as it is now. If someone has a problem with the aliasing, he should simply define LTC_NO_FAST.

[rofl0r]

is that documented somewhere ? maybe a paragraph above the commented out option in tomcrypt-config.h should warn about the UB invoked by it.