You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
mmilata opened this issue
Nov 27, 2024
· 1 comment
Labels
ciContinuous Integration (CI) relatedcodeCode improvementscryptoStand-alone cryptography library used by both Trezor Core and the Trezor Legacy firmwareR&DResearch and development team related
With GCC 14 crypto/tests/test_check under valgrind fails with a bunch of errors like this one:
==35484== Conditional jump or move depends on uninitialised value(s)
==35484== at 0x475122: ge25519_cmove_stride4b (ed25519-donna-impl-base.c:420)
==35484== by 0x475122: ge25519_move_conditional_pniels_array (ed25519-donna-impl-base.c:436)
==35484== by 0x475122: ge25519_scalarmult (ed25519-donna-impl-base.c:489)
==35484== by 0x476652: ed25519_sign_ext (ed25519.c:121)
==35484== by 0x4767C2: ed25519_sign (ed25519.c:151)
==35484== by 0x416276: test_ed25519_fn (test_check.c:7821)
==35484== by 0x4864530: srunner_run_tagged (in /nix/store/qfqvxjl9fvssn2ps4mh4r5lmfjkxkss6-check-0.15.2/lib/libcheck.so.0.0.0)
==35484== by 0x40122B: main (test_check.c:11828)
I assume we don't really care about constant-time signing on x86_64 and we can live with GCC 12 for some more time (probably a good idea to use same version as arm-gcc-embedded which is currently 12). Mostly wanted to document this problem for future reference. Might be a good idea to look at the STM32 ARM machine code too.
mmilata
added
crypto
Stand-alone cryptography library used by both Trezor Core and the Trezor Legacy firmware
ci
Continuous Integration (CI) related
R&D
Research and development team related
labels
Nov 27, 2024
ciContinuous Integration (CI) relatedcodeCode improvementscryptoStand-alone cryptography library used by both Trezor Core and the Trezor Legacy firmwareR&DResearch and development team related
With GCC 14
crypto/tests/test_check
under valgrind fails with a bunch of errors like this one:The value is not actually uninitialised, it's a result of a trick we use to check if control flow doesn't depend on the secret key value. Indeed GCC 12 compiles the
ge25519_cmove_stride4b
to usecmovne
while GCC 14 emitsje
: https://gist.github.com/mmilata/bcacaee840abff5a2ad3e81e838002e7I assume we don't really care about constant-time signing on
x86_64
and we can live with GCC 12 for some more time (probably a good idea to use same version as arm-gcc-embedded which is currently 12). Mostly wanted to document this problem for future reference. Might be a good idea to look at the STM32 ARM machine code too.See also: #4146
The text was updated successfully, but these errors were encountered: