libgcrypt itself supports many various configure options: --enable-ciphers=ciphers select the symmetric ciphers to include --enable-pubkey-ciphers=ciphers select the public-key ciphers to include --enable-digests=digests select the message digests to include --enable-kfds=kdfs select the KDFs to include --enable-random=name select which random number generator to use --disable-dev-random disable the use of dev random --enable-random-daemon Build and support the experimental gcryptrnd --disable-asm Disable MPI assembler modules --enable-m-guard Enable memory guard facility --enable-large-data-tests Enable the real long ruinning large data tests --enable-hmac-binary-check Enable library integrity check --disable-jent-support Disable support for the Jitter entropy collector --disable-padlock-support Disable support for the PadLock Engine of VIA processors --disable-aesni-support Disable support for the Intel AES-NI instructions --disable-shaext-support Disable support for the Intel SHAEXT instructions --disable-pclmul-support Disable support for the Intel PCLMUL instructions --disable-sse41-support Disable support for the Intel SSE4.1 instructions --disable-drng-support Disable support for the Intel DRNG (RDRAND instruction) --disable-avx-support Disable support for the Intel AVX instructions --disable-avx2-support Disable support for the Intel AVX2 instructions --disable-neon-support Disable support for the ARM NEON instructions --disable-arm-crypto-support Disable support for the ARMv8 Crypto Extension instructions Probably at least some of these should be available as USE flags. In particular, I would like to disable the Jitter entropy collector since it requires compiling with -O0.
(In reply to Luke-Jr from comment #0) > libgcrypt itself supports many various configure options: > > --enable-ciphers=ciphers > select the symmetric ciphers to include > --enable-pubkey-ciphers=ciphers > select the public-key ciphers to include > --enable-digests=digests > select the message digests to include > --enable-kfds=kdfs select the KDFs to include > --enable-random=name select which random number generator to use > --disable-dev-random disable the use of dev random > --enable-random-daemon Build and support the experimental gcryptrnd > --disable-asm Disable MPI assembler modules > --enable-m-guard Enable memory guard facility > --enable-large-data-tests > Enable the real long ruinning large data tests > --enable-hmac-binary-check > Enable library integrity check > --disable-jent-support Disable support for the Jitter entropy collector > --disable-padlock-support > Disable support for the PadLock Engine of VIA > processors > --disable-aesni-support Disable support for the Intel AES-NI instructions > --disable-shaext-support > Disable support for the Intel SHAEXT instructions > --disable-pclmul-support > Disable support for the Intel PCLMUL instructions > --disable-sse41-support Disable support for the Intel SSE4.1 instructions > --disable-drng-support Disable support for the Intel DRNG (RDRAND > instruction) > --disable-avx-support Disable support for the Intel AVX instructions > --disable-avx2-support Disable support for the Intel AVX2 instructions > --disable-neon-support Disable support for the ARM NEON instructions > --disable-arm-crypto-support > Disable support for the ARMv8 Crypto Extension > instructions > > Probably at least some of these should be available as USE flags. I don't see much value in that in general, but feel free to point out specific ones you'd like. > > In particular, I would like to disable the Jitter entropy collector since it > requires compiling with -O0. And that is a problem because?... for gcc the pragma handles setting this. I have proposed a way it can be done for clang in bug 629410 comment 2, but in the mean time it should be simple enough with to override it with a a package.env for those it bothers, and certainly nothing that requires a use flag.
I have disabled -O0 in my GCC since I was unable to confirm Spectre mitigations can be made effective with less than -O1. I am trying to take an "excessive precautions" approach rather than risk a false sense of security. The upstream jitter RNG advises that building with optimisations may harm the entropy of the RNG, thereby compromising system security. So disabling O-flag munging may not be a safe solution. http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html#subsec:Intended-Method-of-Use
(In reply to Luke-Jr from comment #2) > I have disabled -O0 in my GCC since I was unable to confirm Spectre > mitigations can be made effective with less than -O1. I am trying to take an > "excessive precautions" approach rather than risk a false sense of security. > > The upstream jitter RNG advises that building with optimisations may harm > the entropy of the RNG, thereby compromising system security. So disabling > O-flag munging may not be a safe solution. > > http://www.chronox.de/jent/doc/CPU-Jitter-NPTRNG.html#subsec:Intended-Method- > of-Use o-flag munging doesn't affect the pragma requirement to build using -O0 , so that is separate matter from the security aspects. In any case, if you don't want it to build with -O0 take it up with upstream. I dont' see sufficient cause to add a use flag for such a behavior.
It's not safe to build jitter RNG without -O0. My solution is to not build the jitter RNG at all. Upstream already supports that (--disable-jent-support). It just needs a USE flag in Gentoo.
(In reply to Luke-Jr from comment #4) > It's not safe to build jitter RNG without -O0. > > My solution is to not build the jitter RNG at all. Upstream already supports > that (--disable-jent-support). It just needs a USE flag in Gentoo. I suggest making the necessary adjustments in an overlay, I don't see this as a useful use flag to add in general.
