On 24/06/18 04:41, Assaf Gordon wrote: > Hello all, > > As I was writing this long email, I just noticed Pádraig sent a patch to > the gnulib mailing list disables AF_ALG by default. > So there's no need for me to implore you anymore to disable it :) > However, since I've already compiled this information, might as well > share it for future use. > > ========================================== > > First, > On a pcc64le running CentOS 7 with kernel 3.10, > there is some problem with the fallback logic. > > $ uname -a > Linux gcc2-power8.osuosl.org 3.10.0-693.11.6.el7.ppc64le #1 \ > SMP Thu Jan 4 18:15:24 GMT 2018 ppc64le ppc64le ppc64le GNU/Linux > > $ seq 10000000 | ./src/sha1sum > ./src/sha1sum: -: Illegal seek
Right if we're processing pipes and the kernel supports AF_ALG but errors during processing, then we don't currently support graceful fallback. This is possibly triggered by this kernel bug: https://patchwork.kernel.org/patch/8124631/ > Second, > Using AF_ALG introduces a new set on unexpected syscalls (network > related syscalls, for a utility that ostensiblty does not touch the > network). > Normally this is not a problem, but under some systemd or containers > setup this could lead to unexpected problems. Interesting. This might also require changes to system SELinux setup for example, to enable support. > Third, > On a more theoretical level, > > Boris Brezillon gave a presentation on kernel crypto engine on October > 2017: > http://events17.linuxfoundation.org/sites/events/files/slides/brezillon-crypto-framework_0.pdf > > There he writes: > > Performance with multiple threads is problematic (slides 22-24); > > "Think twice before using a hardware crypto engine from userspace > I Do the test before taking a decision" (slide 25); > > Kernel Crypto API with suitable hardware generate lots of interrupt > and prevent the system from running smoothly (slide 32); > > Load balancing (multiple access to the crypto engine) might be a bottle > neck (slide 33); Yes performance wise it's not currently appropriate to enable by default IMHO. > Fourth, > If we do go ahead with enabling this by default, we should prominently > announce it, not only in the NEWS but perhaps in the announcement email > itself. More specifically, we should make sure downstream distributions > know that using only "--with-openssl" does not avoid kernel crypto usage > (not sure if everyone checks the updated "./configure --help" message). > > Also, > With AF_ALG there is now intricate interplay between compile time and > runtime features. > If one compiles with kernel-crypto usage (knowingly or unknowingly), > it is still dependant on the runtime kernel being used when the binary > is executed. > This becomes very relevant when docker containers binaries are being > build/compiled on one machine, but run under many different kernels. > Perhaps it would be useful to add in the "sha1sum --version" a line > about which compilation options were used (openssl/AF_ALG/gnulib), > and in case of AF_ALG even test in runtime whether the kernel supports > it or not. > Otherwise, error reporting from users will be hard to use. > Currently knowing if AF_ALG was compiled or not requires "strace" > (or perhaps "nm sha1sum | grep alg" if the binary was not stripped). I also notice that openssl has an (out of tree at present) interface to AF_ALG, so one can enable it without changing coreutils, and for all libcrypto using binaries on the system. Given all of the above, I'm thinking AF_ALG in gnulib will only be used in specialized setups. If this does change to being a default then I agree we'll need improved information to aid debugging. thanks! Pádraig
