Description of problem: When using [1], specifically my test application in test/ I see that with the kernel 4.2 provided for Fedora, the kernel/user space interface for AEAD ciphers does not work. Specifically, when binding to the socket, the name "aead" is not found. It should work out of the box considering that CONFIG_CRYPTO_USER_API_AEAD=y is compiled. Note, when compiling an upstream kernel myself (I am using Herbert Xu's cryptodev-2.6 tree) with CONFIG_CRYPTO_USER_API_AEAD=y I can access the AEAD ciphers. [1] http://www.chronox.de/libkcapi.html Version-Release number of selected component (if applicable): 4.2.3-300.fc23.x86_64 How reproducible: always by using the test application referenced in the directory above: For example: ./kcapi -x 2 -e -c "gcm(aes)" -p 89154d0d4129d322e4487bafaa4f6b46 -k c0ece3e63198af382b5603331cc23fa8 -i 7e489b83622e7228314d878d -a afcd7202d621e06ca53b70c2bdff7fb2 -l 16 should return f4a3eacfbdadd3b1a17117b1d67ffc1f1e21efbbc6d83724a8c296e3bb8cda0c But in fact it fails -- when using strace, it is visible that it fails with bind(). It looks like that the AEAD interface is not registered. Steps to Reproduce: 1. load my source code and unpack 2. cd test/ 3. make 4. invoke command listed above Actual results: error Expected results: f4a3eacfbdadd3b1a17117b1d67ffc1f1e21efbbc6d83724a8c296e3bb8cda0c
Please attach the full config of the upstream kernel you built. Also, please provide the output of dmesg and lsmod from a fresh boot of the Fedora kernel, and again after you unsuccessfully run your test.
Created attachment 1085351 [details] current cryptodev-2.6 tree kernel config
Just as a side note: I checked the System.map and found the symbols implementing the code there: ffffffff81361c30 t aead_poll ffffffff81361cc0 t aead_put_sgl ffffffff81361d40 t aead_recvmsg ffffffff813621f0 t aead_setauthsize ffffffff81362200 t aead_sock_destruct ffffffff813622a0 t aead_accept_parent ffffffff81362420 t aead_setkey ffffffff81362430 t aead_release ffffffff81362450 t aead_bind ffffffff81362470 t aead_data_wakeup.part.6 ffffffff813624e0 t aead_sendpage ffffffff813626f0 t aead_sendmsg Furthermore, the error code is ENOENT which seems to be returned by alg_bind when the requested type is not found. The type can only be found if it is registered. The registering is performed in algif_aead_init (which is also in System.map). Now I am wondering whether the register function is not called?
Created attachment 1085361 [details] dmesg pre test
Created attachment 1085362 [details] lsmod pre test
Created attachment 1085363 [details] dmesg post test
Created attachment 1085364 [details] lsmod post test
Thank you for providing the information. It appears that while the AEAD algorithm is indeed upstream in the 4.2 kernel, it is disabled for userspace use intentionally with: commit 3e90950d36f19e5477becd5acb02e9b8d8c8956f crypto: algif_aead - Temporarily disable all AEAD algorithms As the AEAD conversion is still ongoing, we do not yet wish to export legacy AEAD implementations to user-space, as their calling convention will change. This patch actually disables all AEAD algorithms because some of them (e.g., cryptd) will need to be modified to propagate this flag. Subsequent patches will reenable them on an individual basis. Signed-off-by: Herbert Xu <herbert.org.au> The crypto tree you tested is newer than the 4.2 kernel and contains: commit 5e4b8c1fcc70016f43926203ae1820c3b380d5cd crypto: aead - Remove CRYPTO_ALG_AEAD_NEW flag This patch removes the CRYPTO_ALG_AEAD_NEW flag now that everyone has been converted. Signed-off-by: Herbert Xu <herbert.org.au> which enables it for userspace again. You will need to wait for the 4.3 kernel to use this in userspace.