Am Mittwoch, 26. Oktober 2016, 22:05:28 CEST schrieb Jeffrey Walton: Hi Jeffrey, > > The Linux kernel exports a network interface of type AF_ALG to allow user > > space to utilize the kernel crypto API. libkcapi uses this network > > interface and exports an easy to use API so that a developer does not > > need to consider the low-level network interface handling. > > > > The library does not implement any low level cipher algorithms. All > > consumer requests are sent to the kernel for processing. Results from the > > kernel crypto API are returned to the consumer via the library API. > > > > The kernel interface and therefore this library can be used by > > unprivileged > > processes. > > > > The library code archive also provides a drop-in replacement for the > > command line tools of sha*sum, fipscheck/fipshmac and sha512hmac. > > > > The source code and the documentation is available at [1]. > > That looks awesome Stephan. > > How can user code reliably detect when the API is available? Are there The detection is done through the various _init calls such as kcapi_cipher_init. They will return an error if AF_ALG is not available. According to the documentation these calls return: * @return 0 upon success; ENOENT - algorithm not available; * -EOPNOTSUPP - AF_ALG family not available; * -EINVAL - accept syscall failed * -ENOMEM - cipher handle cannot be allocated Technically, the bind operation will fail if the respective AF_ALG interface is not available. > any preprocessor macros to guard code paths in userland? What are the There are no special guards. If AF_ALG is available, all user space processes can use it. > preprocessor macros we can use to guard it? I am not entirely sure I understand the question. > > Jeff Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
