Updating from *ring* 0.17.8 to 0.17.9

[briansmith]

If you have any questions about the 0.17.9 release, please feel free to ask them in this thread.

ring 0.17.9 was published from commit ecbcdb3
ring 0.17.8 was published from commit fa98b49

$ git diff --stat fa98b490bcbc99a01ff150896ec74c1813242d7f..ecbcdb30203b73842b02f2da175757934c677022
[...]
11731 insertions(+), 11049 deletions(-)
$ git rev-list --count --first-parent fa98b490bcbc99a01ff150896ec74c1813242d7f^..ecbcdb30203b73842b02f2da175757934c677022
426

The diff +11,731 -11,049 may seem scary but when you go through each commit you can see that many of these changes were refactorings that were intended to make it easier to audit the code for panic-freeness and memory-safety.

In several commits, we took an existing file and split it up into multiple files. For example:

commit 497a800 (b/bits)
Author: Brian Smith brian@briansmith.org
Date: Tue Jan 28 19:46:51 2025 -0800

arithmetic: Clarify memory safety of `elem_exp_consttime`.

`elem_exp_consttime` was written weirdly in that it had a bunch of
wrappers functions around assembly functions, `bn_gather5`, etc.,
where the wrapper functions were not marked `unsafe` but also they
didn't themselves enforce safety properties. It kind of made sense
but technically they should have been `unsafe`. And, there were just a
lot of confusing details in how they were written.

Start over with the wrapper functions, and put the new versions of
them in the `x86_64_mont` submodule.

We intentionally avoid adding any masking to `power` arguments, which
would make them completely safe.

To review this properly, one needs to compare how these functions are
documented and used in `crypto/fipsmodule/bn/internal.h` and
`crypto/fipsmodule/bn/exponentiation.c` (note this file was renamed in
recent versions of BoringSSL; use the version that corresponds to the
most recently-merged BoringSSL in *ring*.)

```
git difftool HEAD^1:src/arithmetic/bigint.rs \
                    src/arithmetic/x86_64_mont.rs
```

As you can see here, I try to give a git difftool invocation when a commit moves a significant amount of code from one file to another, and/or when a file is split into multiple files. *ring 0.17.9 has a particularly large number of refactorings of this form. (Future releases will have similar refactorings. I hope there will not be as many, and I hope to break them up into more releases, each with a smaller diff.) So, basically, 0.17.9 is kind of designed to make future releases easier to review.

Accordingly, if you are reviewing the diff from 0.17.8 to 0.17.9, it is best to review them commit-by-commit so you can see these notes designed to help you.

A notable change in 0.17.9 is in the way CPU-feature-based dispatching is done for each algorithm. Like in BoringSSL upstream, the dispatching was moved out of assembly language code. In ring, it was moved to Rust. This change to the dispatching resulted in many little refactorings to the FFI interface between Rust and assembly code. This also let us drop the spin dependency in favor of an atomics-based implementation of one-time initialization for CPU feature detection.

The dedicated x86_64 implementation of Poly1305 was removed as the SSE4.1-based integrated ChaCha20-Poly1305 implementation made it unnecessary.

The merges of BoringSSL to ring look gigantic but 90+% of BoringSSL changes do not result in any ring change, so the diff is relatively small.

Because of the large number of refactorings, it will not be easy to backport any future (security) fixes from future releases to 0.17.8 or earlier. With this in mind, I've tried to make 0.17.9 as backward-compatible as possible, not just in terms of 100% SemVer-compatible API changes, but also in terms of the build system and MSRV. (MSRV is now 1.63.)

[briansmith]

Performance notes:

• When using GCC as the C compiler, X25519 performance should be about 20% better than 0.17.8, due to an added optimization by Google to close the gap in performance between GCC and Clang when compiling that C code.
• AES-GCM performance should be 10-40% better, with bigger improvements for tiny inputs.

Important note regarding future changes: In the future we may source (assembly) code from other sources than BoringSSL and/or we may integrate newer assembly code that uses newer instructions. This will likely have some compatibility impact, e.g. by increasing the binutils version required. This may impact maintainers of ring for older LTS releases. This 0.17.9 release is intended to help you deal with the consequences, if any, of those increased requirements, especially if you support targets with binutils older than the vrsion in Ubuntu 22.04 and/or 24.04 (which is what our CI uses).