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
