On Mon, Apr 23, 2018 at 3:54 PM, Bruno Haible <br...@clisp.org> wrote:
> Hi Matteo,
>
>> > Marvell Armada 8040 - MACCHIATOBin Dual shot:
>> >
>> > $ dd if=/dev/zero bs=1G count=10 |time -p sha1sum
>> > a0b6e2ca4e28360a929943e8eb966f703a69dc44 2g.bin
>> >
>> > real 0m49.390s
>> > user 0m46.852s
>> > sys 0m2.076s
>> > $ dd if=/dev/zero bs=1G count=10 |time -p ./sha1sum-afalg
>> > a0b6e2ca4e28360a929943e8eb966f703a69dc44 2g.bin
>> >
>> > real 0m15.104s
>> > user 0m0.052s
>> > sys 0m15.008s
>
> These are exciting speed improvements!
>
>> Linux kernel cryptographic API via the AF_ALG address family.
>
> Can you briefly explain:
>
> * <https://en.wikipedia.org/wiki/Crypto_API_(Linux)> says that on x86
> platforms the same functions can be done through CPU instructions. Are
> these
> instructions privileged? If not, then what are - for this frequent case of
> Intel CPUs - the advantages and tradeoffs of user-space vs. kernel-space
> use of this crypto instructions?
>
Hi Bruno,
the istructions run unpriviledged. The advantage of the kernel-space
crypto is that if an HW crypto engine is available, the kernel will
use it.
Another advantage is that for file smaller than 2G it can be done via
a single sendfile() call, instead of reading blocks of 32 kb as usual.
And, as a third advantage, less runtime dependencies, the binary
doesn't depend on libcrypto, libz, libdl and libpthread. Some
distribution like Debian avoid linking on libcrypto for licensing
reason, so af_alg is the only way to get faster code than the builtin
one.
> * What is the best way to detect that the Linux kernel support for this API
> is present? Is it that the socket(AF_ALG) call fails? Or is there some
> hint
> in the /proc/cpu or /proc/sys file system?
>
af_alg can be loaded at runtime as linux module when used the first
time, you can see it in the syslog:
[ 9.358098] NET: Registered protocol family 38
so looking in /proc or /sys is not good because it will report no
support after a fresh boot.
Calling socket(AF_ALG) if there is no support, even with module load,
will just report -EAFNOSUPPORT so it's safe to assume this:
socket(AF_ALG, SOCK_SEQPACKET, 0) = -1 EAFNOSUPPORT (Address
family not supported by protocol)
> A few hints regarding the gnulib coding style:
>
> * As you already noticed, we need to avoid build failures and runtime
> failures
> on platforms where this is not supported.
>
I will take care of this.
> * We don't use github, but this mailing list, for discussion and code
> reviews,
> as github is a proprietary and somewhat closed environment.
>
I use Github only as backup, mailing list is obviously preferred.
> * In the module description, section 'Include', you should not list all
> include
> files but only those that the user is supposed to include. In this case,
> I think, the af_alg business is invisible to the caller of the 4 modules.
>
Didn't know it, will fix it.
> * In an include file, such as lib/af_alg.h, we include only the minimum of
> header files that are required for parsing it. In this case, I think it
> would only be <stdio.h>. The other header files can be included in the .c
> files, with the appropriate #if conditions.
>
> * The 'Hey Emacs!' section is only needed in files that contains non-ASCII
> characters.
>
Sorry, I just copied it from sha1.h :)
> * Put '} else {' on 3 separate lines.
> * Use 'size_t', not 'int', for variables that denote the length of a memory
> segment.
>
Makes sense, will do.
> Bruno
>
Regards,
--
Matteo Croce
per aspera ad upstream
