On Wed, May 9, 2018 at 9:29 AM, Paul Eggert <egg...@cs.ucla.edu> wrote: >> Fortunately other non deprecated algos like sha256 are way >> faster. > > > Faster than when --with-openssl is used? Can you show me how to benchmark > that? >
Faster than the C code. The performance of af_alg and openssl are comparable, they can range from slighty faster, to slighty slower depending on the CPU: arm64 $ time ./sha256sum-afalg ubuntu-18.04-desktop-amd64.iso a55353d837cbf7bc006cf49eeff05ae5044e757498e30643a9199b9a25bc9a34 ubuntu-18.04-desktop-amd64.iso real 0m2.305s user 0m0.000s sys 0m2.305s $ time ./sha256sum-libcrypto ubuntu-18.04-desktop-amd64.iso a55353d837cbf7bc006cf49eeff05ae5044e757498e30643a9199b9a25bc9a34 ubuntu-18.04-desktop-amd64.iso real 0m2.454s user 0m1.993s sys 0m0.461s x86_64 $ time ./sha256sum-afalg ubuntu-18.04-desktop-amd64.iso a55353d837cbf7bc006cf49eeff05ae5044e757498e30643a9199b9a25bc9a34 ubuntu-18.04-desktop-amd64.iso real 0m3,706s user 0m0,000s sys 0m3,704s $ time ./sha256sum-libcrypto ubuntu-18.04-desktop-amd64.iso a55353d837cbf7bc006cf49eeff05ae5044e757498e30643a9199b9a25bc9a34 ubuntu-18.04-desktop-amd64.iso real 0m3,404s user 0m3,273s sys 0m0,119s All this kernel support was not meant to replace openssl, it's more likely an alternative. There are already two cases I care about when this can be used while openssl can't - Debian doesn't links coreutils against libssl for legal issues - In embedded devices like the ones supported by OpenWrt, having 2 MB of libcrypto is not acceptable, expecially when the kernel has the code already > After reading Assaf's comments I confess that I'm not getting the point of > the recent changes. As I understand it, the hardware support in question is > typically available to user-mode code so why go to the kernel at all? And > even if there are magic features not available outside the kernel, why not > let the OpenSSL library worry about the tradeoffs involved in user vs kernel > mode rather than reinvent its wheel? It's a real pain to ship data off to > the kernel with all the overheads and other hassles involved, and I don't > see why it's a good idea for Gnulib to get involved. > > At this point I am leaning towards reverting these changes. If we keep them, > the default should be to disable this new feature; plus, several bugs (at > least one of which I introduced; sorry!) need to be fixed. I'm not sure it's > worth the maintenance effort to keep this stuff in, at least if it's > coreutils we're talking about. What do you mean for HW support? If you are referring to instructions like Intel SSSE3/AVX, they are available for userspace too. But for real HW support, like dedicated chips, you can't access them directly from the HW. As example, here there is an arm64 board[1] which have an HW crypto engine from SafeNet. Looking in /proc/crypto reveals that the algos are using it # grep 'sha1$' -m1 -A9 /proc/crypto driver : safexcel-hmac-sha1 module : crypto_safexcel priority : 300 refcnt : 1 selftest : passed internal : no type : ahash async : yes blocksize : 64 digestsize : 20 # grep 'sha256$' -m1 -A9 /proc/crypto driver : safexcel-hmac-sha256 module : crypto_safexcel priority : 300 refcnt : 1 selftest : passed internal : no type : ahash async : yes blocksize : 64 digestsize : 32 # modinfo crypto_safexcel filename: /lib/modules/4.14.22/kernel/drivers/crypto/inside-secure/crypto_safexcel.ko license: GPL v2 description: Support for SafeXcel cryptographic engine EIP197 Other devices like PC Engines ALIX have a similar HW and it's already supported by the kernel. Also, on cloud installations, where servers are VMs running under an hypervisor, there could be an HW crypto in the hypervisor itself shared between the guests, and the kernel has already a virtio crypto driver to access transparently the HW of the host[2] So if you concern is about bad performances in common use cases, you can disable it by default and package maintainers or firmware developers can enable it as needed. [1] http://macchiatobin.net/product/macchiatobin-double-shot/ [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/crypto/virtio -- Matteo Croce per aspera ad upstream
