Received: by 2002:a25:d7c1:0:0:0:0:0 with SMTP id o184csp3479479ybg; Fri, 25 Oct 2019 04:53:23 -0700 (PDT) X-Google-Smtp-Source: APXvYqyK54Tjyj+pRG3CIHmYaJ5qDHVGdMDD2f/yXqr0wkpxPHYiAJIuSNfL5FufA2LQ8GViVYKR X-Received: by 2002:a50:ee95:: with SMTP id f21mr2394357edr.18.1572004403422; Fri, 25 Oct 2019 04:53:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1572004403; cv=none; d=google.com; s=arc-20160816; b=xrrp80LtIjubNrvcaPp4cYudt3jixZ7xE4PNU4AZytcl9pFrqlngMO44L5Y6/UH8sI Rbvc46cETy7/kpqAsOvcnqR6knYCx1LLRUl9tFnHiqJ0AIGJdAgChucRmqOMXRSrre2S x+McmCNIya8GB9xkjbmpaLRAfWaZ5QPWD/5nIAtppFlVCILfaJcHCD17OuchNzXdZ/MN 2dBMcZAL81AtnvCQRqT3riGXW9m3q+ExStQ0UOn+T1ITDJVONlSgAOFLPizuDkS/rgwV ap+3dpV06Vl14K/LB7iyozcee5s4GEQ+Fh7QDd9Neq1x97hx3IcNSSlDXNIJfjskfNgJ Yosg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version:dkim-signature; bh=MfLNZPiOOv0GyPmKyaIc0LUP61FSFodSyddnqOidMms=; b=k4lQMAZC759ZXNvz4wTYh5ygbcANl6ceLj1O7lXWi+w8WP67ZgvyZJh5OZpYCEc6nv 5QMaz9OC4mmGYT0a+ScPpK022M+g88R7XG0jTCszAKuGZmYDgc9a5DlCa0Fk5uOGnDFY YYCKUP7VZ5hbjVDlAxgDztVqXdQmpgqohICS+aYhoGnko+Ye57NeToqJ3qNa9BBRM/Gx +Lb/+GzNf/FuG901R32lO3ti1Wh5cBNZHxvW5BUYbCwPdtHnaa3oY2Ve0HEDzuGY3ycz 7MD+wZtRJ15zPraWzE0rrvnvw5+Fam7jCUNuRkblu2F69do9MU7ulSZerJ8e+D2uwB9B pYyw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2019-08-05 header.b=Nk1BRXvk; spf=pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id jz12si1010720ejb.193.2019.10.25.04.52.59; Fri, 25 Oct 2019 04:53:23 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2019-08-05 header.b=Nk1BRXvk; spf=pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2393607AbfJXNgT (ORCPT + 99 others); Thu, 24 Oct 2019 09:36:19 -0400 Received: from userp2120.oracle.com ([156.151.31.85]:43362 "EHLO userp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2388255AbfJXNgT (ORCPT ); Thu, 24 Oct 2019 09:36:19 -0400 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x9ODYGGR124201; Thu, 24 Oct 2019 13:36:02 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=corp-2019-08-05; bh=MfLNZPiOOv0GyPmKyaIc0LUP61FSFodSyddnqOidMms=; b=Nk1BRXvkb2/KI9E3J5HsRIEKnm7HC0sWA2ATueJ6rSUs7Y1bZPo0rZL6d+xLTJ/9gLKF rA98TtjoOhjKTH4w6HJVRpAGLZ2EiyUGMWDdYTKgtZf7FNZ5LcRgGvFb1z9EegDdBF4i 7zEb5vLsNlIri/UARvNYxiCrB5AVNmmX7QtmfKcF0UCMf/lRK7L5CVdy+bAvvlICxNNq 1ipCvmpib0ZPKFwHS3pAElFrMUXBhBoz4Bl7kEb3zpS2QTrDIwrWLgODjWqSMl1fHfuO Zu0rlYQ5kgyRirTCU/LrNAdjhwSblxjojCkRhdg43Un55Z/zhyt7W2a4bfoypdPLGx0L qg== Received: from aserp3020.oracle.com (aserp3020.oracle.com [141.146.126.70]) by userp2120.oracle.com with ESMTP id 2vqu4r3gvw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 24 Oct 2019 13:36:01 +0000 Received: from pps.filterd (aserp3020.oracle.com [127.0.0.1]) by aserp3020.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x9ODX5OC097976; Thu, 24 Oct 2019 13:36:01 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserp3020.oracle.com with ESMTP id 2vu0fpa7vq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 24 Oct 2019 13:36:00 +0000 Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x9ODZxLn006060; Thu, 24 Oct 2019 13:35:59 GMT Received: from anon-dhcp-153.1015granger.net (/68.61.232.219) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 24 Oct 2019 06:35:59 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: [PATCH v1 2/2] SUNRPC: Fix svcauth_gss_proxy_init() From: Chuck Lever In-Reply-To: <20191024133416.2148.96218.stgit@klimt.1015granger.net> Date: Thu, 24 Oct 2019 09:35:58 -0400 Cc: Bruce Fields , Linux NFS Mailing List , Simo Sorce Content-Transfer-Encoding: quoted-printable Message-Id: <1DD83F8D-10A7-4273-A53F-3AB858EBE2D1@oracle.com> References: <20191024133410.2148.3456.stgit@klimt.1015granger.net> <20191024133416.2148.96218.stgit@klimt.1015granger.net> To: Chuck Lever X-Mailer: Apple Mail (2.3445.104.11) X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9419 signatures=668684 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=2 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910240131 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9419 signatures=668684 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=2 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910240131 Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org Whoops, was going to Cc: Simo on this one... > On Oct 24, 2019, at 9:34 AM, Chuck Lever = wrote: >=20 > gss_read_proxy_verf() assumes things about the XDR buffer containing > the RPC Call that are not true for buffers generated by > svc_rdma_recv(). >=20 > RDMA's buffers look more like what the upper layer generates for > sending: head is a kmalloc'd buffer; it does not point to a page > whose contents are contiguous with the first page in the buffers' > page array. The result is that ACCEPT_SEC_CONTEXT via RPC/RDMA has > stopped working on Linux NFS servers that use gssproxy. >=20 > This does not affect clients that use only TCP to send their > ACCEPT_SEC_CONTEXT operation (that's all Linux clients). Other > clients, like Solaris NFS clients, send ACCEPT_SEC_CONTEXT on the > same transport as they send all other NFS operations. Such clients > can send ACCEPT_SEC_CONTEXT via RPC/RDMA. >=20 > I thought I had found every direct reference in the server RPC code > to the rqstp->rq_pages field. >=20 > Bug found at the 2019 Westford NFS bake-a-thon. >=20 > Fixes: 3316f0631139 ("svcrdma: Persistently allocate and DMA- ... ") > Signed-off-by: Chuck Lever > Tested-by: Bill Baker > --- > net/sunrpc/auth_gss/svcauth_gss.c | 84 = ++++++++++++++++++++++++++++--------- > 1 file changed, 63 insertions(+), 21 deletions(-) >=20 > diff --git a/net/sunrpc/auth_gss/svcauth_gss.c = b/net/sunrpc/auth_gss/svcauth_gss.c > index f130990..c62d1f1 100644 > --- a/net/sunrpc/auth_gss/svcauth_gss.c > +++ b/net/sunrpc/auth_gss/svcauth_gss.c > @@ -1078,24 +1078,32 @@ struct gss_svc_data { > return 0; > } >=20 > -/* Ok this is really heavily depending on a set of semantics in > - * how rqstp is set up by svc_recv and pages laid down by the > - * server when reading a request. We are basically guaranteed that > - * the token lays all down linearly across a set of pages, starting > - * at iov_base in rq_arg.head[0] which happens to be the first of a > - * set of pages stored in rq_pages[]. > - * rq_arg.head[0].iov_base will provide us the page_base to pass > - * to the upcall. > - */ > -static inline int > -gss_read_proxy_verf(struct svc_rqst *rqstp, > - struct rpc_gss_wire_cred *gc, __be32 *authp, > - struct xdr_netobj *in_handle, > - struct gssp_in_token *in_token) > +static void gss_free_in_token_pages(struct gssp_in_token *in_token) > { > - struct kvec *argv =3D &rqstp->rq_arg.head[0]; > u32 inlen; > - int res; > + int i; > + > + i =3D 0; > + inlen =3D in_token->page_len; > + while (inlen) { > + if (in_token->pages[i]) > + put_page(in_token->pages[i]); > + inlen -=3D inlen > PAGE_SIZE ? PAGE_SIZE : inlen; > + } > + > + kfree(in_token->pages); > + in_token->pages =3D NULL; > +} > + > +static int gss_read_proxy_verf(struct svc_rqst *rqstp, > + struct rpc_gss_wire_cred *gc, __be32 = *authp, > + struct xdr_netobj *in_handle, > + struct gssp_in_token *in_token) > +{ > + struct kvec *argv =3D &rqstp->rq_arg.head[0]; > + unsigned int page_base, length; > + int pages, i, res; > + size_t inlen; >=20 > res =3D gss_read_common_verf(gc, argv, authp, in_handle); > if (res) > @@ -1105,10 +1113,36 @@ struct gss_svc_data { > if (inlen > (argv->iov_len + rqstp->rq_arg.page_len)) > return SVC_DENIED; >=20 > - in_token->pages =3D rqstp->rq_pages; > - in_token->page_base =3D (ulong)argv->iov_base & ~PAGE_MASK; > + pages =3D DIV_ROUND_UP(inlen, PAGE_SIZE); > + in_token->pages =3D kcalloc(pages, sizeof(struct page *), = GFP_KERNEL); > + if (!in_token->pages) > + return SVC_DENIED; > + in_token->page_base =3D 0; > in_token->page_len =3D inlen; > + for (i =3D 0; i < pages; i++) { > + in_token->pages[i] =3D alloc_page(GFP_KERNEL); > + if (!in_token->pages[i]) { > + gss_free_in_token_pages(in_token); > + return SVC_DENIED; > + } > + } >=20 > + length =3D min_t(unsigned int, inlen, argv->iov_len); > + memcpy(page_address(in_token->pages[0]), argv->iov_base, = length); > + inlen -=3D length; > + > + i =3D 1; > + page_base =3D rqstp->rq_arg.page_base; > + while (inlen) { > + length =3D min_t(unsigned int, inlen, PAGE_SIZE); > + memcpy(page_address(in_token->pages[i]), > + page_address(rqstp->rq_arg.pages[i]) + page_base, > + length); > + > + inlen -=3D length; > + page_base =3D 0; > + i++; > + } > return 0; > } >=20 > @@ -1282,8 +1316,11 @@ static int svcauth_gss_proxy_init(struct = svc_rqst *rqstp, > break; > case GSS_S_COMPLETE: > status =3D gss_proxy_save_rsc(sn->rsc_cache, &ud, = &handle); > - if (status) > + if (status) { > + pr_info("%s: gss_proxy_save_rsc failed (%d)\n", > + __func__, status); > goto out; > + } > cli_handle.data =3D (u8 *)&handle; > cli_handle.len =3D sizeof(handle); > break; > @@ -1294,15 +1331,20 @@ static int svcauth_gss_proxy_init(struct = svc_rqst *rqstp, >=20 > /* Got an answer to the upcall; use it: */ > if (gss_write_init_verf(sn->rsc_cache, rqstp, > - &cli_handle, &ud.major_status)) > + &cli_handle, &ud.major_status)) { > + pr_info("%s: gss_write_init_verf failed\n", __func__); > goto out; > + } > if (gss_write_resv(resv, PAGE_SIZE, > &cli_handle, &ud.out_token, > - ud.major_status, ud.minor_status)) > + ud.major_status, ud.minor_status)) { > + pr_info("%s: gss_write_resv failed\n", __func__); > goto out; > + } >=20 > ret =3D SVC_COMPLETE; > out: > + gss_free_in_token_pages(&ud.in_token); > gssp_free_upcall_data(&ud); > return ret; > } >=20 -- Chuck Lever