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
