[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.
Bruno
- [PATCH 1/4] sha1sum: use AF_ALG when available, (continued)
- [PATCH 4/4] md5sum: use kernel crypto API, Matteo Croce, 2018/04/23
- Re: [PATCH 0/4] Use AF_ALG in checksum utilities, Matteo Croce, 2018/04/23
- Re: [PATCH 0/4] Use AF_ALG in checksum utilities, Matteo Croce, 2018/04/24
- Re: [PATCH 0/4] Use AF_ALG in checksum utilities, Bruno Haible, 2018/04/24
- Re: [PATCH 0/4] Use AF_ALG in checksum utilities, Dmitry V. Levin, 2018/04/24