bug-gnulib
[Top][All Lists]
Advanced

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

Re: [PATCH 0/4] Use AF_ALG in checksum utilities


From: Matteo Croce
Subject: Re: [PATCH 0/4] Use AF_ALG in checksum utilities
Date: Mon, 23 Apr 2018 18:08:25 +0200

On Mon, Apr 23, 2018 at 3:54 PM, Bruno Haible <address@hidden> 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



reply via email to

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