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

[Assaf Gordon]

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

Strace shows:
====
  fadvise64(0, 0, 0, POSIX_FADV_SEQUENTIAL) = -1 ESPIPE (Illegal seek)
  socket(AF_ALG, SOCK_SEQPACKET|SOCK_CLOEXEC, 0) = 3
  bind(3, {sa_family=AF_ALG, sa_data="hash\0\0\0\0\0\0\0\0\0\0"}, 88) = 0
  accept4(3, NULL, NULL, SOCK_CLOEXEC)    = 4
  close(3)                                = 0
  lseek(0, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
  fstat(0, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
  mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
0) = 0x3fff96f50000
  read(0, "1\n2\n3\n4\n5\n6\n7\n8\n9\n10\n11\n12\n13\n14"..., 32768) = 
32768
  send(4, "1\n2\n3\n4\n5\n6\n7\n8\n9\n10\n11\n12\n13\n14"..., 32768, 
MSG_MORE) = -1 ENOKEY (Required key not available)
  lseek(0, -32768, SEEK_CUR)              = -1 ESPIPE (Illegal seek)
  close(4)                                = 0
  write(2, "./src/sha1sum: ", 15)         = 15
  write(2, "-", 1)                        = 1
======

This is reproducible on the gcc compile farm on
  gcc112.fsffrance.org:/home/agn/cu-crypto/cu-kernel-hw/



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.

For example, using the following contrived systemd service which 
prohibits network related syscalls:
=====
  [Unit]
  Description=Coreutils hashing test
  After=network.target

  [Service]
  Type=simple
  User=gordon
  WorkingDirectory=/home/gordon
  ExecStart=/path/to/sha1sum /etc/passswd
  Restart=on-failure # or always, on-abort, etc
  StandardOutput=syslog
  SystemCallFilter=~@network-io
====

Because of "SystemCallFilter" prohibiting network related calls,
the sha1sum program will be killed by the kernel with "Bad system call".
strace will show:
   [...]
   socket(AF_ALG, SOCK_SEQPACKET|SOCK_CLOEXEC, 0) = ?
   +++ killed by SIGSYS +++



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);




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).



=============

Thanks for reading so far,
 - assaf