Re: [ANNOUNCE] libkcapi v0.12.0 released
Am Donnerstag, 27. Oktober 2016, 18:53:45 CEST schrieb Jeffrey Walton: Hi Jeffrey, > >> preprocessor macros we can use to guard it? > > > > I am not entirely sure I understand the question. > > See, for example, > https://github.com/openssl/openssl/blob/master/engines/afalg/e_afalg.c > > The versions are kind of arbitrary because there's no easy way to tell > when the gear is available. If I recall from researching things, there > were two components needed for afalg, and they were supposedly > available back to later 2.x kernels. > > Things should "just work" for 3.x and 4.x kernels. But if "too early" > a kernel is encountered, then users experience the spectrum from > compile problems to unexplained runtime errors. I see. There are guards around zerocopy. AF_ALG appeared with 2.6.38 / 3.0 which already had zerocopy. I will try a 3.0 kernel with my current lib to see whether it works out of the box and apply fixes and guards if it does not. But I am not sure whether I should guard anything for 2.x kernels where we know that some folks simply backported the AF_ALG interface. Thanks a lot for the reminder. Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] libkcapi v0.12.0 released
>> > 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. ... >> 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. See, for example, https://github.com/openssl/openssl/blob/master/engines/afalg/e_afalg.c The versions are kind of arbitrary because there's no easy way to tell when the gear is available. If I recall from researching things, there were two components needed for afalg, and they were supposedly available back to later 2.x kernels. Things should "just work" for 3.x and 4.x kernels. But if "too early" a kernel is encountered, then users experience the spectrum from compile problems to unexplained runtime errors. Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] libkcapi v0.12.0 released
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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] libkcapi v0.12.0 released
> 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 any preprocessor macros to guard code paths in userland? What are the preprocessor macros we can use to guard it? Jeff -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[ANNOUNCE] libkcapi v0.12.0 released
Hi, 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]. [1] http://www.chronox.de/libkcapi.html Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
