Bug 1273811 - AF_ALG: AEAD kernel/user interface unusable
AF_ALG: AEAD kernel/user interface unusable
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
23
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-10-21 05:53 EDT by Stephan Mueller
Modified: 2015-10-27 12:04 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-10-27 12:04:59 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
current cryptodev-2.6 tree kernel config (99.36 KB, text/plain)
2015-10-21 20:11 EDT, Stephan Mueller
no flags Details
dmesg pre test (70.20 KB, text/plain)
2015-10-21 20:29 EDT, Stephan Mueller
no flags Details
lsmod pre test (5.75 KB, text/plain)
2015-10-21 20:30 EDT, Stephan Mueller
no flags Details
dmesg post test (70.20 KB, text/plain)
2015-10-21 20:30 EDT, Stephan Mueller
no flags Details
lsmod post test (5.78 KB, text/plain)
2015-10-21 20:31 EDT, Stephan Mueller
no flags Details

  None (edit)
Description Stephan Mueller 2015-10-21 05:53:05 EDT
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
Comment 1 Josh Boyer 2015-10-21 08:23:07 EDT
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.
Comment 2 Stephan Mueller 2015-10-21 20:11 EDT
Created attachment 1085351 [details]
current cryptodev-2.6 tree kernel config
Comment 3 Stephan Mueller 2015-10-21 20:18:33 EDT
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?
Comment 4 Stephan Mueller 2015-10-21 20:29 EDT
Created attachment 1085361 [details]
dmesg pre test
Comment 5 Stephan Mueller 2015-10-21 20:30 EDT
Created attachment 1085362 [details]
lsmod pre test
Comment 6 Stephan Mueller 2015-10-21 20:30 EDT
Created attachment 1085363 [details]
dmesg post test
Comment 7 Stephan Mueller 2015-10-21 20:31 EDT
Created attachment 1085364 [details]
lsmod post test
Comment 8 Josh Boyer 2015-10-27 12:04:41 EDT
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@gondor.apana.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@gondor.apana.org.au>

which enables it for userspace again.

You will need to wait for the 4.3 kernel to use this in userspace.

Note You need to log in before you can comment on or make changes to this bug.