From owner-svn-src-projects@freebsd.org Mon Mar 2 22:40:15 2020 Return-Path: Delivered-To: svn-src-projects@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E7AE125C9FC for ; Mon, 2 Mar 2020 22:40:15 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660067.outbound.protection.outlook.com [40.107.66.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48WZpl4fVlz4NjH; Mon, 2 Mar 2020 22:40:15 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SBqoM6/NJdciGpuHxcLqd29IHOwwxXSLdPYcjvj9iUP7PM2tjyfwK/lx1yjDyyPXGxGcxp62Z6eQCkL5m7MmgaR446EYEIWjcYkRP95FHl/8hyJRfomuRyJy+KZp5sZsUEBlpdzTNZZTRUkBgQrzPbMN5TSwVGmd470vLiEGuX5iklr23HsDIQEpIkmKeZyE8/1qZ/vH9bP9/HoRumXYgd9y21DZHJuu0V771Zv08os3BQfff6Z6z6Bj9fRBruA63qUhJu3O3KOGbnWbW7qefAFfZ/76E3AFSTwKCTjsbMXVqUuLEiUQG1HbBEqgZBRSIEhTaAcfH599rGfr7qBzVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BWukORKliU/ZKcCxK1C19vVTpqo7VZCx4Q7mTwVTSO0=; b=nWxSBZYMg5dHNDwiJha2UQoJTUvKKlpBLj8s0XBBRvMa114jqh3mP+Zy+oZBAz1G9RWTiiLNWrgDM+UnF+DzcwVGJB1+kPpFc7rqdUZ8pde6PYyqhhfxNdMPosBS9mjJyOJrk6+FoDATkHB4TF+f5KYYL9w/BCtU3nkOgnAKmW4asm93n3WmmX3P2nig5WqjGGuciBKpbHrfkqa47CysuRiaxgmKwW/8zWsG4mP4h6RfGUMIk/drfdjaLU7gxMNYuKjN6HoPw6Kjr9LWmAETwrNoGEDN5w9uNbge3Aq1g7VduH57VvTDEAvSvH/SPkZheUGr1eml/ZnwACKzmkbCXQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none Received: from YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM (10.255.46.82) by YTBPR01MB4029.CANPRD01.PROD.OUTLOOK.COM (10.255.12.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.15; Mon, 2 Mar 2020 22:40:13 +0000 Received: from YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM ([fe80::a50d:6237:4074:f9c4]) by YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM ([fe80::a50d:6237:4074:f9c4%6]) with mapi id 15.20.2772.019; Mon, 2 Mar 2020 22:40:13 +0000 From: Rick Macklem To: John Baldwin , Rick Macklem , "src-committers@freebsd.org" , "svn-src-projects@freebsd.org" Subject: Re: svn commit: r358053 - projects/nfs-over-tls/sys/fs/nfsclient Thread-Topic: svn commit: r358053 - projects/nfs-over-tls/sys/fs/nfsclient Thread-Index: AQHV7dDxwBYPOhnzy0GhC4ymRJHhbqgxm+kugAP6L4CAAFK4dg== Date: Mon, 2 Mar 2020 22:40:13 +0000 Message-ID: References: <202002172110.01HLAXZY003012@repo.freebsd.org> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ff3bc689-6817-4b7f-5329-08d7befaac46 x-ms-traffictypediagnostic: YTBPR01MB4029: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 033054F29A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(39860400002)(136003)(376002)(366004)(189003)(199004)(7696005)(86362001)(478600001)(450100002)(6506007)(71200400001)(53546011)(5660300002)(966005)(2906002)(316002)(786003)(66446008)(66556008)(64756008)(66476007)(110136005)(66946007)(186003)(8676002)(26005)(81156014)(33656002)(52536014)(9686003)(55016002)(8936002)(81166006)(76116006)(91956017); DIR:OUT; SFP:1101; SCL:1; SRVR:YTBPR01MB4029; H:YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: H+tEk1E9zPyet1C11C37g6/M9oyDwFWc+9lOG3k3e73+gDYh/A6RUpaqQROXLeHETaWTobtDJP7CvPxGd8BkU5DJECo45gxuxVi8AsLXxBq+tYlo4n1hQwtGlqFcoJeAZipJDc4SJUS1jlnlJQ6DIIZmlTBJ+D31p+BW1uzHVAEXgaHEpY8QP6F7r01DBBFAtAxKmcCbUhwrVqPwblHAdo2ZpPywgdJP11Z+opkBQZacjmJxfaq0ipxYH4ykuZS9usV0pnQ8xGpNnTgaU/WgE2r06KR08EbQCqPiDWQZAjPDyG6htxXAMGUo686yPAag9EESj+4BnkTkPADylHRcSpe/x1LWV5kwWlxQHc12SqNUvDjNGU0quhv20+xSN0z3LDm2IQeNC4MZx7X/IY0WOtz0rFetEw30IUO+2TizTWF+M0CErrflhC66M5V4hCuyuyaE7zGLGF49L4jUuH0QGUS5FPoaTfEZpG1PJhwnnuyztzFy0HtEa2OFN3CiTk8C98fjHPwVuaUtDsCEovFb1A== x-ms-exchange-antispam-messagedata: +VX3v/BcNVwkBt6+CfEHaMFD42Oyx4omXOhAqGn3mbObKqjCzreGyXKzqJu3dDIQGkTnj1xNaZG3nldOqhQs34F7zCb29Xuof5RJntP1eQOaJM/xxpFx6eVvx7AzRKvhz1gvj4/Lr6k1qKO0FvPlBw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: ff3bc689-6817-4b7f-5329-08d7befaac46 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Mar 2020 22:40:13.6376 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: RUN4FekEdQob0lMjARRnK1OfFqC97BBWOOTKZPRwDG49IoV2tw7712kkDUZz7rt+gnepftxvtuJ+GttdefhroQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTBPR01MB4029 X-Rspamd-Queue-Id: 48WZpl4fVlz4NjH X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-5.89 / 15.00]; NEURAL_HAM_MEDIUM(-0.89)[-0.889,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: svn-src-projects@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the src " projects" tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2020 22:40:16 -0000 John Baldwin wrote:=0A= >On 2/28/20 8:57 PM, Rick Macklem wrote:=0A= >> John Baldwin wrote:=0A= >>> On 2/17/20 1:10 PM, Rick Macklem wrote:=0A= >>>> Author: rmacklem=0A= >>>> Date: Mon Feb 17 21:10:32 2020=0A= >>>> New Revision: 358053=0A= >>>> URL: https://svnweb.freebsd.org/changeset/base/358053=0A= >>>>=0A= >>>> Log:=0A= >>>> Update nfs_clrpcops.c to handle ext_pgs mbufs, including the additio= nal=0A= >>>> argument to nfscl_reqstart() to tell it if it should build ext_pgs m= bufs.=0A= >>>>=0A= >>>> This completes most of the conversion to support of ext_pgs mbufs, b= ut=0A= >>>> there are still a couple of areas to fix.=0A= >>>> 1 - The code that the MDS uses to do a proxy to a DS for a pNFS serv= er.=0A= >>>> 2 - The krpc code on the receive side. (The NFS code now handles the= =0A= >>>> ext_pgs mbufs, but they are being created by copying the regular= mbuf=0A= >>>> list when the NFS code gets it from the krpc.) The krpc still ne= eds=0A= >>>> to be fixed so it can handle a list of ext_pgs mbufs handed to i= t=0A= >>>> by soreceive().=0A= >>>=0A= >>> Note that the current KTLS RX support I've worked on is a bit different= in that=0A= >>> it doesn't use ext_pgs mbufs. Instead the socket buffer contains a lis= t of=0A= >>> records (OpenSSL uses recvmsg()) where there is a control mbuf with the= TLS=0A= >>> header followed by a chain of normal mbufs with the data. As such, you= will=0A= >>> only have to construct ext_pgs mbufs for the send side. Receive will s= till=0A= >>> be getting regular mbufs. For receive you probably want to check the T= LS=0A= >>> record type and do something (not sure?) with any non-application-data = records,=0A= >>> but otherwise just treat the payload of application-data records the sa= me as=0A= >>> you do for the non-TLS case.=0A= >> Ok. I've already done the receive side code changes to handle ext_pgs mb= ufs=0A= >> in the krpc/nfs code, so if it becomes easier/more efficient to put the = receive=0A= >> data in ext_pgs mbufs, that can be handled. (Someday there may be net=0A= >> interfaces that perform better using ext_pgs mbufs?)=0A= >>=0A= >> Any non-data records that need to be handled by OpenSSL in userspace can= =0A= >> be passed up/handled by the daemons, similar to SSL_connect()/SSL_accept= ().=0A= >>=0A= >> Thanks for the info John, rick=0A= >=0A= >Ok. After sending this, I do think it is likely that for NICs able to do = TLS=0A= >RX without TOE, TLS records may indeed arrive as ext_pgs mbufs, but by the= time=0A= >you would get them out of the socket buffer the TLS headers and trailers w= ould=0A= >be stripped and they would just be unmapped mbufs holding the TLS record p= ayload.=0A= >The TLS header would still be in a control message in the socket buffer.= =0A= Should be fine for the code I've written, so long as the pages are anonymou= s.=0A= (If not, the code will need to know a way to allocate a page.)=0A= For example, I have a function similar to m_split(), but it doesn't try to = duplicate=0A= a hdr mbuf and handles anonymous ext_pgs mbufs. When the split is in the=0A= middle of a page, it allocates a new mbuf with a new page for the first par= tial=0A= page and moves the rest of the pages to it.=0A= (Actually, all of the functions like m_split() could be generalized to hand= le=0A= ext_pgs mbufs if there was an "allocate page" function for them and if mbu= fs=0A= with an m_len =3D=3D 0 were allowed in the chain.)=0A= =0A= >I started testing my KTLS RX software branch Friday btw (panicked right aw= ay=0A= >of course, but it's hopefully not too far away). For now I'm only focused= on=0A= >TLS 1.0-1.2, but will get to 1.3 eventually. I suspect for 1.3 that early= data=0A= >will still be handled in userland and just as for KTLS TX, KTLS RX will on= ly=0A= >be used with the second set of keys.=0A= John, I didn't think you ever wrote code that crashed;-)=0A= Sounds good. Let me know when you have patch(es) to test.=0A= =0A= Have fun with it, rick=0A= =0A= --=0A= John Baldwin=0A=