Re: af_alg benchmarks and performance

[Assaf Gordon]

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.


regards,
 - assaf