coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Assaf Gordon
Subject: Disabling the new AF_ALG by default (linux kernel crypto hashing)
Date: Sun, 24 Jun 2018 05:41:30 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0

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

















reply via email to

[Prev in Thread] Current Thread [Next in Thread]