Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crypto++ needs to support a fixed target #1252

Open
HFTrader opened this issue Dec 8, 2023 · 2 comments
Open

Crypto++ needs to support a fixed target #1252

HFTrader opened this issue Dec 8, 2023 · 2 comments

Comments

@HFTrader
Copy link

HFTrader commented Dec 8, 2023

In the current form, Crypto++ will compile the library with optimal settings for the current build machine.

However in many cases (as mine) we need to compile a generic version of the library such that the resulting binary can be redistributed.

If Crypto++ is build on a high end machine and then shipped to a client with old hardware, it is very likely that the application will crash with an instruction unknown.

It would be very useful if a target (-march=target) platform could be defined somewhere that would define all instruction sets supported. In this case all hardware tests should be ignored.

@noloader
Copy link
Collaborator

noloader commented Dec 8, 2023

Crypto++ will compile the library with optimal settings for the current build machine... If Crypto++ is build on a high end machine and then shipped to a client with old hardware, it is very likely that the application will crash with an instruction unknown.

That's not true.

Please run cyrptest.exe v on the problematic host, and post back the results.

Also state how you built the library. In particular, we need to know which CPPFLAGS and CXXFLAGS you used to build the library.

@noloader noloader changed the title Cryptopp needs to support a fixed target Crypto++ needs to support a fixed target Dec 8, 2023
@HFTrader
Copy link
Author

HFTrader commented Dec 9, 2023

If I just run make with no CPPFLAGS or CXXFLAGS on an AMD Threadripper 3960X, it compiles most files with default settings (no arch) but those are issued:

g++ -DNDEBUG -g2 -O3 -fPIC -pthread -pipe -msse4.1 -c blake2b_simd.cpp
g++ -DNDEBUG -g2 -O3 -fPIC -pthread -pipe -msse4.1 -c blake2s_simd.cpp
g++ -DNDEBUG -g2 -O3 -fPIC -pthread -pipe -mavx2 -c chacha_avx.cpp
g++ -DNDEBUG -g2 -O3 -fPIC -pthread -pipe -msse2 -c chacha_simd.cpp
g++ -DNDEBUG -g2 -O3 -fPIC -pthread -pipe -mssse3 -c cham_simd.cpp
g++ -DNDEBUG -g2 -O3 -fPIC -pthread -pipe -msse4.2 -c crc_simd.cpp
g++ -DNDEBUG -g2 -O3 -fPIC -pthread -pipe -msse2 -c donna_sse.cpp
g++ -DNDEBUG -g2 -O3 -fPIC -pthread -pipe -mssse3 -mpclmul -c gcm_simd.cpp
g++ -DNDEBUG -g2 -O3 -fPIC -pthread -pipe -mpclmul -c gf2n_simd.cpp
g++ -DNDEBUG -g2 -O3 -fPIC -pthread -pipe -mssse3 -c keccak_simd.cpp
g++ -DNDEBUG -g2 -O3 -fPIC -pthread -pipe -mssse3 -c lea_simd.cpp
g++ -DNDEBUG -g2 -O3 -fPIC -pthread -pipe -mavx2 -c lsh256_avx.cpp
g++ -DNDEBUG -g2 -O3 -fPIC -pthread -pipe -mssse3 -c lsh256_sse.cpp
g++ -DNDEBUG -g2 -O3 -fPIC -pthread -pipe -mavx2 -c lsh512_avx.cpp
g++ -DNDEBUG -g2 -O3 -fPIC -pthread -pipe -mssse3 -c lsh512_sse.cpp
g++ -DNDEBUG -g2 -O3 -fPIC -pthread -pipe -msse4.1 -maes -c rijndael_simd.cpp
g++ -DNDEBUG -g2 -O3 -fPIC -pthread -pipe -msse4.2 -msha -c sha_simd.cpp
g++ -DNDEBUG -g2 -O3 -fPIC -pthread -pipe -msse4.2 -msha -c shacal2_simd.cpp
g++ -DNDEBUG -g2 -O3 -fPIC -pthread -pipe -mssse3 -c simon128_simd.cpp
g++ -DNDEBUG -g2 -O3 -fPIC -pthread -pipe -mssse3 -maes -c sm4_simd.cpp
g++ -DNDEBUG -g2 -O3 -fPIC -pthread -pipe -mssse3 -c speck128_simd.cpp
g++ -DNDEBUG -g2 -O3 -fPIC -pthread -pipe -msse2 -c sse_simd.cpp

Isn't compiling with -mavx2 going to generate assembly instructions that can blow up on an old Core2 Intel processor?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants