Date: Sun, 15 May 2022 18:53:39 GMT From: Rick Macklem <rmacklem@FreeBSD.org> To: src-committers@FreeBSD.org, dev-commits-src-all@FreeBSD.org, dev-commits-src-main@FreeBSD.org Subject: git: 0b4f2ab0e913 - main - krpc: Fix NFS-over-TLS for KTLS1.3 Message-ID: <202205151853.24FIrd1F036270@gitrepo.freebsd.org>
next in thread | raw e-mail | index | archive | help
The branch main has been updated by rmacklem: URL: https://cgit.FreeBSD.org/src/commit/?id=0b4f2ab0e91307bd1fa6e884b0fccef9d10d5a2d commit 0b4f2ab0e91307bd1fa6e884b0fccef9d10d5a2d Author: Rick Macklem <rmacklem@FreeBSD.org> AuthorDate: 2022-05-15 18:51:56 +0000 Commit: Rick Macklem <rmacklem@FreeBSD.org> CommitDate: 2022-05-15 18:51:56 +0000 krpc: Fix NFS-over-TLS for KTLS1.3 When NFS-over-TLS uses KTLS1.3, the client can receive post-handshake handshake records. These records can be safely thown away, but are not handled correctly via the rpctls_ct_handlerecord() upcall to the daemon. Commit 373511338d95 changed soreceive_generic() so that it will only return ENXIO for Alert records when MSG_TLSAPPDATA is specified. As such, the post-handshake handshake records will be returned to the krpc. This patch modifies the krpc so that it will throw these records away, which seems sufficient to make NFS-over-TLS work with KTLS1.3. This change has no effect on the use of KTLS1.2, since it does not generate post-handshake handshake records. MFC after: 2 weeks --- sys/rpc/clnt_vc.c | 21 +++++++++------------ sys/rpc/svc_vc.c | 12 ++++++------ 2 files changed, 15 insertions(+), 18 deletions(-) diff --git a/sys/rpc/clnt_vc.c b/sys/rpc/clnt_vc.c index f565de06f4bd..0c415d048141 100644 --- a/sys/rpc/clnt_vc.c +++ b/sys/rpc/clnt_vc.c @@ -944,7 +944,7 @@ clnt_vc_soupcall(struct socket *so, void *arg, int waitflag) { struct ct_data *ct = (struct ct_data *) arg; struct uio uio; - struct mbuf *m, *m2, **ctrlp; + struct mbuf *m, *m2; struct ct_request *cr; int error, rcvflag, foundreq; uint32_t xid_plus_direction[2], header; @@ -992,13 +992,10 @@ clnt_vc_soupcall(struct socket *so, void *arg, int waitflag) m2 = m = NULL; rcvflag = MSG_DONTWAIT | MSG_SOCALLBCK; if (ct->ct_sslrefno != 0 && (ct->ct_rcvstate & - RPCRCVSTATE_NORMAL) != 0) { + RPCRCVSTATE_NORMAL) != 0) rcvflag |= MSG_TLSAPPDATA; - ctrlp = NULL; - } else - ctrlp = &m2; SOCKBUF_UNLOCK(&so->so_rcv); - error = soreceive(so, NULL, &uio, &m, ctrlp, &rcvflag); + error = soreceive(so, NULL, &uio, &m, &m2, &rcvflag); SOCKBUF_LOCK(&so->so_rcv); if (error == EWOULDBLOCK) { @@ -1023,8 +1020,8 @@ clnt_vc_soupcall(struct socket *so, void *arg, int waitflag) } /* - * A return of ENXIO indicates that there is a - * non-application data record at the head of the + * A return of ENXIO indicates that there is an + * alert record at the head of the * socket's receive queue, for TLS connections. * This record needs to be handled in userland * via an SSL_read() call, so do an upcall to the daemon. @@ -1051,10 +1048,10 @@ clnt_vc_soupcall(struct socket *so, void *arg, int waitflag) cmsg->cmsg_len == CMSG_LEN(sizeof(tgr))) { memcpy(&tgr, CMSG_DATA(cmsg), sizeof(tgr)); /* - * This should have been handled by - * setting RPCRCVSTATE_UPCALLNEEDED in - * ct_rcvstate but if not, all we can do - * is toss it away. + * TLS_RLTYPE_ALERT records should be handled + * since soreceive() would have returned + * ENXIO. Just throw any other + * non-TLS_RLTYPE_APP records away. */ if (tgr.tls_type != TLS_RLTYPE_APP) { m_freem(m); diff --git a/sys/rpc/svc_vc.c b/sys/rpc/svc_vc.c index f0e0ee5d4d62..43d14c702d4e 100644 --- a/sys/rpc/svc_vc.c +++ b/sys/rpc/svc_vc.c @@ -804,8 +804,8 @@ tryagain: } /* - * A return of ENXIO indicates that there is a - * non-application data record at the head of the + * A return of ENXIO indicates that there is an + * alert record at the head of the * socket's receive queue, for TLS connections. * This record needs to be handled in userland * via an SSL_read() call, so do an upcall to the daemon. @@ -863,10 +863,10 @@ tryagain: cmsg->cmsg_len == CMSG_LEN(sizeof(tgr))) { memcpy(&tgr, CMSG_DATA(cmsg), sizeof(tgr)); /* - * This should have been handled by - * the rpctls_svc_handlerecord() - * upcall. If not, all we can do is - * toss it away. + * TLS_RLTYPE_ALERT records should be handled + * since soreceive() would have returned + * ENXIO. Just throw any other + * non-TLS_RLTYPE_APP records away. */ if (tgr.tls_type != TLS_RLTYPE_APP) { m_freem(m);
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202205151853.24FIrd1F036270>