Make crypt and crypt_gensalt use thread-local output buffers.

[besser82]

This change makes crypt and crypt_gensalt as thread-safe as they can be without changing their interfaces. Solaris already made this change, and it’s being discussed by glibc (with suggestion that it should be pushed upstream to the C
and POSIX standards committees): https://sourceware.org/ml/libc-alpha/2018-10/msg00437.html

Portable programs should still use the r-variants, though, because this is not a guaranteed feature that is portable to other implementations of these functions. Also it doesn’t help threads to not clobber their corresponding output buffer on a second call from within the same thread.

The way I've implemented this mimicks the implementation from Solaris.

I've also taken into account some problems with -fno-plt code and thread-local storage on PPC64-architectures. See: https://sourceware.org/PR32387

---

This also fixes #62.

[solardiz]

I didn't review the m4 stuff.

Overall, I am not sure this is worth the complexity and reduced portability, but I don't mind (once the issues I pointed out are addressed - especially what looks like a trivial yet major bug).

[solardiz]

Now this calls crypt_r with uninitialized stack data in nr_crypt_ctx - a bug? IIRC, at least the initialized field should be set to 0.

Also, we probably incur some performance penalty by having this struct recreated each time, but perhaps only for descrypt?

[besser82]

Now this calls crypt_r with uninitialized stack data in nr_crypt_ctx - a bug? IIRC, at least the initialized field should be set to 0.

Fixed by initializing the whole struct with explicit_bzero.

Also, we probably incur some performance penalty by having this struct recreated each time, but perhaps only for descrypt?

Well, the performance penalty is meassurable, but not noticeable: This change adds on average about 220 milliseconds of computing time for 1 Million invocations; so in a range of 200 - 300 nanoseconds per call. As those numbers are measured on an Intel Celeron 4205U with Fedora Workstation 41, the real life time penalty on affordable faster hardware, like a Ryzen 5 2400G, are expected be lower.

[solardiz]

Fixed by initializing the whole struct with explicit_bzero.

Feels like mild misuse of explicit_bzero, but that's not necessarily bad. If we want to use it not only to initialize, but also to wipe any sensitive data that might have been left from a previous call, then perhaps we also want to do it for the output buffer before the strcpy_or_abort. And then maybe move the explicit_bzero of the data struct to after the strcpy_or_abort and introduce simple initialization (just memset)?

[besser82]

strcpy_or_abort already zeroizes the left over space after the copied string.

The cleanup of struct crypt_data is also already done by do_crypt (called from inside crypt_r) after the computation has been finished.

I've used explicit_bzero here intentionally to ensure the just stack-allocated struct crypt_data is really initialized properly before use.

[besser82]

Feels like mild misuse of explicit_bzero, but that's not necessarily bad.

Changed to memset for initialization.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.16%. Comparing base (fe5b8b8) to head (beec01e).

Additional details and impacted files

@@             Coverage Diff             @@
##           develop     #201      +/-   ##
===========================================
+ Coverage    90.15%   90.16%   +0.01%     
===========================================
  Files           32       32              
  Lines         3626     3631       +5     
  Branches       689      690       +1     
===========================================
+ Hits          3269     3274       +5     
  Misses         226      226              
  Partials       131      131              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[zackw]

@besser82 I should have time to look at this early next week, but not before that.