Bug 1778348

Summary: Kernel TLS and "Unknown error 524" during setsockopt
Product: [Fedora] Fedora Reporter: Jeffrey Walton <noloader>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED INSUFFICIENT_DATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: unspecified    
Version: 31CC: airlied, bskeggs, hdegoede, ichavero, itamar, jarodwilson, jeremy, jglisse, john.j5live, jonathan, josef, kernel-maint, linville, masami256, mchehab, mjg59, noloader, steved, valdis.kletnieks
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-03-25 22:30:30 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
ktls.c source code none

Description Jeffrey Walton 2019-11-30 04:34:20 UTC 
Created attachment 1640781 [details]
ktls.c source code

I'm working on Fedora 31 x86_64 (fully patched). I'm working through the Kernel TLS example at https://www.kernel.org/doc/html/latest/networking/tls.html#kernel-tls . Fedora 31 kernels provides the KTLS feature:

    $ grep TLS /boot/config-5.3.12-300.fc31.x86_64
    CONFIG_HAVE_COPY_THREAD_TLS=y
    CONFIG_TLS=m
    ...

I performed a modprobe to load the module, and verified ULP was available:

    $ cat /proc/sys/net/ipv4/tcp_available_ulp
    tls

Then, using the sample code from the docs:

    sock = socket(AF_INET, SOCK_STREAM, 0);
    setsockopt(sock, SOL_TCP, TCP_ULP, "tls", sizeof("tls"));

A run of the program results in:

    $ ./ktls
    setsockopt failed, 524, Unknown error 524

It looks like something is a little bit sideways. The documentation may be missing steps, or the kernel module may have an issue. Searching for KTLS and the error message is not providing useful results.

(The error string for 524 should probably be improved. Is that glibc? If so, I can file a bug report.)

====================

$ cat ktls.c
#include <stdio.h>
#include <unistd.h>
#include <errno.h>
#include <string.h>

#include <sys/socket.h>
#include <sys/types.h>

#include <linux/tls.h>
#include <netinet/ip.h>
#include <netinet/tcp.h>

int main() {
    int sock = socket(AF_INET, SOCK_STREAM, 0);
    if (sock == -1)
    {
        printf("socket failed, %d, %s\n", errno, strerror(errno));
        return 1;
    }

    if (setsockopt(sock, SOL_TCP, TCP_ULP, "tls", sizeof("tls")) == -1 )
    {
        printf("setsockopt failed, %d, %s\n", errno, strerror(errno));
        return 1;
    }

    close (sock);
    return 0;
}

====================

$ lsb_release -a
LSB Version:    :core-4.1-amd64:core-4.1-noarch
Distributor ID: Fedora
Description:    Fedora release 31 (Thirty One)
Release:        31
Codename:       ThirtyOne
Comment 1 Valdis Kletnieks 2019-11-30 06:39:08 UTC 
We tracked down why the program returns -ENOTSUPP.  However, there's still a glibc issue.

[~] cat strerr.c
#include <string.h>
#include <stdio.h>

int main(int argc, char **argv)
{
	printf("strerror 524 returns +%s+\n",strerror(524));
}
[~] gcc strerr.c
[~] ./a.out
strerror 524 returns +Unknown error 524+
[~] 

Meanwhile, ENOTSUPP has been in the Linux kernel for basically forever:
 [/usr/src/linux-next] git blame include/linux/errno.h | grep -C 5 524
^1da177e4c3f4 (Linus Torvalds     2005-04-16 15:20:36 -0700 22) 
^1da177e4c3f4 (Linus Torvalds     2005-04-16 15:20:36 -0700 23) /* Defined for the NFSv3 protocol */
^1da177e4c3f4 (Linus Torvalds     2005-04-16 15:20:36 -0700 24) #define EBADHANDLE	521	/* Illegal NFS file handle */
^1da177e4c3f4 (Linus Torvalds     2005-04-16 15:20:36 -0700 25) #define ENOTSYNC	522	/* Update synchronization mismatch */
^1da177e4c3f4 (Linus Torvalds     2005-04-16 15:20:36 -0700 26) #define EBADCOOKIE	523	/* Cookie is stale */
^1da177e4c3f4 (Linus Torvalds     2005-04-16 15:20:36 -0700 27) #define ENOTSUPP	524	/* Operation is not supported */
^1da177e4c3f4 (Linus Torvalds     2005-04-16 15:20:36 -0700 28) #define ETOOSMALL	525	/* Buffer or request is too small */
^1da177e4c3f4 (Linus Torvalds     2005-04-16 15:20:36 -0700 29) #define ESERVERFAULT	526	/* An untranslatable error occurred */

so I'm not sure where the disconnect came from, nor how many *other* kernel-defined return codes aren't in strerror's list
Comment 2 Jeffrey Walton 2019-11-30 13:46:46 UTC 
The Glibc folks were pinged about the error string for 524 at https://sourceware.org/ml/libc-help/2019-11/msg00017.html.
Comment 3 Justin M. Forbes 2020-03-03 16:23:03 UTC 
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There are a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 31 kernel bugs.

Fedora 31 has now been rebased to 5.5.7-200.fc31.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you have moved on to Fedora 32, and are still experiencing this issue, please change the version to Fedora 32.

If you experience different issues, please open a new bug report for those.
Comment 4 Justin M. Forbes 2020-03-25 22:30:30 UTC 
*********** MASS BUG UPDATE **************
This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 3 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.
Comment 5 Red Hat Bugzilla 2023-09-14 05:47:52 UTC 
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days