4a496a36fb ct: Use volatile "trick" in all fe/scalar cmov implementations (Tim Ruffing)
Pull request description:
Apparently clang 15 is able to compile our cmov code into a branch, at least for fe_cmov and fe_storage_cmov. This commit makes the condition volatile in all cmov implementations (except ge but that one only calls into the fe impls).
This is just a quick fix. We should still look into other methods, e.g., asm and #457. We should also consider not caring about constant-time in scalar_low_impl.h
We should also consider testing on very new compilers in nightly CI, see https://github.com/bitcoin-core/secp256k1/pull/864#issuecomment-769211867
ACKs for top commit:
jonasnick:
ACK 4a496a36fb
Tree-SHA512: a6010f9d752e45f01f88b804a9b27e77caf5ddf133ddcbc4235b94698bda41c9276bf588c93710e538250d1a96844bcec198ec5459e675f166ceaaa42da921d5
Apparently clang 15 is able to compile our cmov code into a branch,
at least for fe_cmov and fe_storage_cmov. This commit makes the
condition volatile in all cmov implementations (except ge but that
one only calls into the fe impls).
This is just a quick fix. We should still look into other methods,
e.g., asm and #457. We should also consider not caring about
constant-time in scalar_low_impl.h
We should also consider testing on very new compilers in nightly CI,
see https://github.com/bitcoin-core/secp256k1/pull/864#issuecomment-769211867
5bb03c2911 Replace `SECP256K1_ECMULT_TABLE_VERIFY` macro by a function (Hennadii Stepanov)
4429a8c218 Suppress `-Wunused-parameter` when building for coverage analysis (Hennadii Stepanov)
Pull request description:
ACKs for top commit:
real-or-random:
utACK 5bb03c2911
jonasnick:
ACK 5bb03c2911
Tree-SHA512: 19a395434ecefea201a03fc45b3f0b88f1520908926ac1207bbc6570034b1141b49c3c98e66819dcd9069dfdd28c7c6fbe957f13fb6bd178fd57ce65bfbb8fbd
3e43041be6 No need to subtract 1 before doing a right shift (roconnor-blockstream)
Pull request description:
ACKs for top commit:
real-or-random:
utACK 3e43041be6
jonasnick:
ACK 3e43041be6
Tree-SHA512: bcecda11eae3fb845bef7af88c6171bedcd933872d08a9849c0a250cb6c9e982a88bd45e8a8364a4a348f8be413fc91ee04cf8fa78adae44e584e3ad7ec544cf
fd2a408647 Set ARM ASM symbol visibility to `hidden` (Hennadii Stepanov)
Pull request description:
Solves one item in #1181.
To test on arm-32bit hardware, run:
```
$ ./autogen.sh && ./configure --enable-experimental --with-asm=arm && make
```
On master branch (427bc3cdcf):
```
$ nm -D .libs/libsecp256k1.so | grep secp256k1_fe
0000e2bc T secp256k1_fe_mul_inner
0000e8dc T secp256k1_fe_sqr_inner
```
With this PR:
```
$ nm -D .libs/libsecp256k1.so | grep secp256k1_fe | wc -l
0
```
For reference, see https://sourceware.org/binutils/docs/as/Hidden.html.
ACKs for top commit:
theuni:
ACK fd2a408647.
sipa:
ACK fd2a408647
Tree-SHA512: abf8ad332631672c036844f69c5599917c49e12c4402bf9066f93a692d3007b1914bd3eea8f83f0141c1b09d5c88ebc5e6c8bfbb5444b7b3471749f7b901ca59
4ebd82852d Apply Checks only in VERIFY mode. (roconnor-blockstream)
Pull request description:
This is already done in `field_5x52_impl.h`.
ACKs for top commit:
sipa:
ACK 4ebd82852d
jonasnick:
ACK 4ebd82852d
Tree-SHA512: c24211e5219907e41e2c5792255734bd50ca5866a4863abbb3ec174ed92d1792dd10563a94c08e8fecd6cdf776a9c49ca87e8f9806a023d9081ecc0d55ae3e66
96dd062511 build: bump CMake minimum requirement to 3.13 (Cory Fields)
Pull request description:
As requested here: https://github.com/bitcoin-core/secp256k1/pull/1230#issuecomment-1464730218 . Ping @hebasto
Among other things this allows us to link against object libraries.
3.13 has been mentioned several times as a good overlap between newish features and widespread Linux availability.
ACKs for top commit:
hebasto:
ACK 96dd062511
real-or-random:
utACK 96dd062511
Tree-SHA512: 6c744809aa393b48ef10b3d46c6630370c388a8d375116bfad65c6c907e69c36ed71c1579b9d5c3aa976f70b1cd70e837c1a0226910a43539435125115b32568
8e79c7ed11 build: Ensure no optimization when building for coverage analysis (Hennadii Stepanov)
Pull request description:
#944 introduced a regression when building for coverage analysis. The `-O2` flag from the default Autoconf's `CFLAGS` overrides the coverage-specific `-O0` one, which makes coverage analysis results [less reliable](https://gcc.gnu.org/onlinedocs/gcc/Gcov-and-Optimization.html).
This PR restores the pre-#944 behaviour.
In contrast to an alternative smaller diff:
```diff
--- a/configure.ac
+++ b/configure.ac
@@ -240,7 +240,7 @@ fi
if test x"$enable_coverage" = x"yes"; then
SECP_CONFIG_DEFINES="$SECP_CONFIG_DEFINES -DCOVERAGE=1"
- SECP_CFLAGS="-O0 --coverage $SECP_CFLAGS"
+ CFLAGS="$CFLAGS -O0 --coverage "
LDFLAGS="--coverage $LDFLAGS"
else
# Most likely the CFLAGS already contain -O2 because that is autoconf's default.
```
this PR ensures that the user always has the last word.
FWIW, Bitcoin Core uses a similar [approach](460e394625/configure.ac (L879-L884)).
ACKs for top commit:
jonasnick:
tested ACK 8e79c7ed11
real-or-random:
utACK 8e79c7ed11
Tree-SHA512: f04b55921d397bd7c003ec0283101d3908f3fb507789c855e1b6d5abd150e7d6281d5eeb8fefbb7d6a55b3c6f29a19324f570eee009794f8fa9bca956229e7ce
28e63f7ea7 release cleanup: bump version after 0.3.0 (Jonas Nick)
Pull request description:
Based on #1223. Should be merged only after tagging the release.
ACKs for top commit:
sipa:
ACK 28e63f7ea7
real-or-random:
ACK 28e63f7ea7
Tree-SHA512: d219f836c9258af52389f62c167adb79a0f83f520ede514e286e84f0540d35234322e67d582409c332662db17114da1681419d5d400ed88ad2be66a0f6a06089
756b61d451 readme: Use correct build type in CMake/Windows build instructions (Tim Ruffing)
Pull request description:
ACKs for top commit:
hebasto:
ACK 756b61d451, it is correct to provide the "RelWithDebInfo" configuration in multi-config setup, as the same build type is the default in single-config setups.
Tree-SHA512: e98a1519fdae4a29c7e06ecd0e68083acaf0f4fc14dfcd12282b89468052bb7c6c2fc7517c8526c9f7555a822a64b2f7c3f1ecc70d17e37a11d831d213f1daef
5d8f53e312 Remove redudent checks. (Russell O'Connor)
Pull request description:
These abs checks are implied by the subsequent line, and with the subsequent line written as it is, no underflow is possible with signed integers.
Follows up on https://github.com/bitcoin-core/secp256k1/pull/1218.
ACKs for top commit:
sipa:
utACK 5d8f53e312
real-or-random:
ACK 5d8f53e312
Tree-SHA512: ddd6758638fe634866fdaf900224372e2e51cb81ef4d024f169fbc39fff38ef1b29e90e0732877e8910158b82bc428ee9c3a4031882c2850b22ad87cc63ee305
2ef1c9b387 Update overflow check (Russell O'Connor)
Pull request description:
One does not simply check for integer overlow.
ACKs for top commit:
sipa:
ACK 2ef1c9b387
real-or-random:
ACK 2ef1c9b387
Tree-SHA512: 61238b7b59b3840aa04c4c3ff768789eba95d8d9cbd16507b86bae585fe8d077ac1ac234f9d8aea7fa342c7278a30d2d888df3a93d7ab24730e73b682b11a7fe
ce3cfc78a6 doc: Describe Jacobi calculation in safegcd_implementation.md (Elliott Jin)
6be01036c8 Add secp256k1_fe_is_square_var function (Pieter Wuille)
1de2a01c2b Native jacobi symbol algorithm (Pieter Wuille)
04c6c1b181 Make secp256k1_modinv64_det_check_pow2 support abs val (Pieter Wuille)
5fffb2c7af Make secp256k1_i128_check_pow2 support -(2^n) (Pieter Wuille)
Pull request description:
This introduces variants of the vartime divsteps-based GCD algorithm used for modular inverses to compute Jacobi symbols. Changes compared to the normal vartime divsteps:
* Only positive matrices are used, guaranteeing that f and g remain positive.
* An additional jac variable is updated to track sign changes during matrix computation.
* There is (so far) no proof that this algorithm terminates within reasonable amount of time for every input, but experimentally it appears to almost always need less than 900 iterations. To account for that, only a bounded number of iterations is performed (1500), after which failure is returned. The field logic then falls back to using square roots to determining the result.
* The algorithm converges to f=g=gcd(f0,g0) rather than g=0. To keep this test simple, the end condition is f=1, which won't be reached if started with g=0. That case is dealt with specially.
This code is currently unused, except for tests. I don't aim for it to be merged until there is a need for it, but this demonstrates its feasibility.
In terms of performance:
```
field_inverse: min 1.76us / avg 1.76us / max 1.78us
field_inverse_var: min 0.991us / avg 0.993us / max 0.996us
field_jacobi_var: min 1.31us / avg 1.31us / max 1.31us
field_sqrt: min 4.36us / avg 4.37us / max 4.40us
```
while with the older (f24e122d13) libgmp based Jacobi code on the same system:
```
num_jacobi: min 1.53us / avg 1.54us / max 1.55us
```
ACKs for top commit:
jonasnick:
ACK ce3cfc78a6
real-or-random:
reACK ce3cfc78a6 diff and writeup is good and I tested every commit
Tree-SHA512: 8a6204a7a108d8802d942a54faca39917f90ea5923130683bbd870f9025f4ec8ef256ffa1d939a793f0b32d4cdfcdcd1d3f8ae5ed74a0193be7ad98362ce027e
The implementation calls the secp256k1_modinvNN_jacobi_var code, falling back
to computing a square root in the (extremely rare) case it failed converge.
