[Top][All Lists]

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

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

From: Bruno Haible
Subject: Re: [PATCH 0/4] Use AF_ALG in checksum utilities
Date: Mon, 23 Apr 2018 19:18:35 +0200
User-agent: KMail/5.1.3 (Linux/4.4.0-119-generic; KDE/5.18.0; x86_64; ; )

Hi Matteo,

> >   * <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?
> >
> 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.

Good. And the drawbacks of the kernel approach:
  - The system call overhead is probably negligible.
  - Is there some kernel lock that would prevent simultaneous execution of
    crypto primitives by different threads or processes?

> >   * 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)

Good. Thanks for having explained it. I agree, then, trying the socket(AF_ALG)
call is the proper way of detection.


reply via email to

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