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
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
The Glibc folks were pinged about the error string for 524 at https://sourceware.org/ml/libc-help/2019-11/msg00017.html.
*********** 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.
*********** 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.
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days