Re: Disabling the new AF_ALG by default (linux kernel crypto hashing)

[Pádraig Brady]

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