Bug 1778348 - Kernel TLS and "Unknown error 524" during setsockopt
Summary: Kernel TLS and "Unknown error 524" during setsockopt
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 31
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: ---
Assignee: Kernel Maintainer List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-11-30 04:34 UTC by Jeffrey Walton
Modified: 2019-11-30 13:46 UTC (History)
19 users (show)

Fixed In Version:
Doc Type: ---
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)
ktls.c source code (593 bytes, text/plain)
2019-11-30 04:34 UTC, Jeffrey Walton
no flags Details

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.


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