[Top][All Lists]

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

Re: af_alg benchmarks and performance

From: Assaf Gordon
Subject: Re: af_alg benchmarks and performance
Date: Wed, 9 May 2018 09:56:40 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0

Hello Matteo and all,

Let me emphasize that I'm not against this feature, but I just think it
should be disabled by default, and enabled explicitly with a "configure"
flag when downstream users want it and deemed it worthwhile.

On 09/05/18 02:57 AM, Matteo Croce wrote:
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

IIUC, an ongoing effort to relicense OpenSSL to Apache2 is nearly
complete [1][2][3].

[1] https://www.openssl.org/blog/blog/2017/03/22/license/
[2] https://www.openssl.org/blog/blog/2018/03/01/last-license/
[3] https://license.openssl.org/trying-to-find

- 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

OpenWRT and many similar embedded systems don't use GNU coreutils by
default, instead they use Busybox [1].
It also seems like the installed libopenssl code takes ~600KB on OpenWRT
[2],  and that sounds like something that will be common (otherwise, no
SSL/HTTPS support in the embedded device).

So if a system builder wants GNU coreutils sha*sum programs with Linux
Crypto API support - that's a customized build that fits well with
explicitly enabling a flag in "./configure".

[1] https://openwrt.org/packages/index/base-system
[2] https://openwrt.org/packages/pkgdata/libopenssl

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
# grep 'sha256$' -m1 -A9 /proc/crypto

# modinfo crypto_safexcel
description:    Support for SafeXcel cryptographic engine EIP197

This is an interesting real-world case:
While the driver has support for sha1/sha224/sha256 and using the HW
might be very fast, it does not support sha512.

So if CryptoAPI is enabled, sha512 won't be faster then the
OpenSSL/SSSE3/AVX implementations.

This echoes back to Bruno's suggestion of runtime parsing of
/proc/crypto - which adds more complexity.

Other devices like PC Engines ALIX have a similar HW and it's already
supported by the kernel.

Yes, and they also commonly use dedicated distributions (e.g. https://www.pcengines.ch/alix.htm ) - if they know they are working on a
device with HW crypto - then they can explicitly build programs with
support for it.

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]

Similarly, most distributions have customized "cloud" images, sometimes
even customized per each cloud provider (e.g. AWS, Azure, GCP). [1][2]
If a certain provider has HW crypto (and it is common enough on their
VMs), it can be enabled as needed.

[1] https://wiki.debian.org/Cloud/SystemsComparison
[2] https://wiki.centos.org/Cloud/AWS

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.

My own concern is not about bad performance (obviously crypto api is
faster than the C code and comparable to OpenSSL optimized code).

My concern is about fundamental changes (e.g. kernel-mode vs user-mode,
new and untested code, rapidly changing code) that are enabled by
default, and will affect all gnulib projects and all their users,
without them knowing.

For example if this change is endorsed by Redhat, and enabled by default
just for sha*sum in the next major version release, it will provide lots
of supporting evidence that it works well, and might be enabled globally
by default.

 - assaf

reply via email to

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