From owner-svn-src-projects@freebsd.org Tue May 12 14:32:33 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 F40E82F13DB for ; Tue, 12 May 2020 14:32:32 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-to1can01on0612.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe5d::612]) (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 49M0dD0FBMz4KJ8; Tue, 12 May 2020 14:32:31 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VXy5RvJMQF1v9MBREWetldjp7hMs1fOE/vrUU2e8jTiB78z3rIMflyAc0o/qx3yCHvUYCwqzrYpTmGs0nXuIU9yRgkGMMj+XR2RVVn7UgNOqcrn0Uxr3WOW1LIxiVKzr3sztqiXy+QUAGDb+VWmv5oSboMNs1RjYkC2TaBE8Ei/GG+rDTZQ8/Hj/srKYHfplXOaZ8y2KU3JDmRJ5WYxw1OAnJRBgK4nH5WD5e4FWw+juW+LzJAk7M08js2OnFxc4oTF2PXG3FVtt+3k9BVfUVhfHzPiSmk8ofpPtHmGeJWFdDitDQsF2AkAu5pv/JG+BuNb9o3Q86drdveWrmjbE8Q== 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=ZOUJsSOPGByLp1+Kzgm7Uvdkx92a/FN8VsqctnpfVyI=; b=eV/CexJcN9YXSZtTpTqh8SyStrlo7wAGOvdmYrdgkEDMR+ZMG2ChwiCx4zvPRnK4Ul6en47WRv0Js7YT7wZG0PlGBx4MPANr/4zUfZyFqE7cmW1608LQts3LQ0i41ixA1/oJ+dJP2LS+OYPtguHKll0GGYbPYi+jonAsEkizxEYToWnztQ/ljopY9La0qX1/Ss8VpqBfclFD2K7QQ+X0Aq7UEgdZDtvmcDv6Xn51m2OFeX2yWDmpQTo1Vc3gS4KulXTpyTXn62Hm1uItkiKLHsYd8xgAIXx/Eq4eHncXbx77xQcv2ZR0HJgBlJP+o1ZkZqOQvX2pfe3TjPUDxMqPfw== 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZOUJsSOPGByLp1+Kzgm7Uvdkx92a/FN8VsqctnpfVyI=; b=nIRZkH5Pj4r+XtmFDQthBsBNAPjcRELcal4d+80fwHGo78WUxsG9aNtwVyFh3XkqnGVgZ8NUB48mSsEVPu9EXZ4UrSmbteXza969bOztMifvdvSQZQ7ijwZiVqUtKv3Iqv6zqu6sxs6sZYs9k5pUIUY+Og5E4yWJdcuR+7mxW0HQgi2Ex1mLhLHIF57vZDN0Hzc/qA210+QSS+JQWEHjWEj9FN0V1QN9eRKUj+z9mHxJEaEb3rf1FM6HtzoJDpmb553ksKbeQXcTmdpp8lSIQur12mZNoxSeik4ZhNoXM/Kc4PSK+oHtQmwDWBSD1Sn+oH+sSq8XYN3tP1xXkgWmcg== Received: from QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM (52.132.86.26) by QB1PR01MB3427.CANPRD01.PROD.OUTLOOK.COM (52.132.87.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.28; Tue, 12 May 2020 14:32:29 +0000 Received: from QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM ([fe80::dd96:945c:b6ee:ffa2]) by QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM ([fe80::dd96:945c:b6ee:ffa2%6]) with mapi id 15.20.2979.033; Tue, 12 May 2020 14:32:29 +0000 From: Rick Macklem To: Benjamin Kaduk CC: John Baldwin , Rick Macklem , "src-committers@freebsd.org" , "svn-src-projects@freebsd.org" Subject: Re: svn commit: r360859 - projects/nfs-over-tls/sys/rpc Thread-Topic: svn commit: r360859 - projects/nfs-over-tls/sys/rpc Thread-Index: AQHWJ9HZ1BQ89BXo/ki0EXCO1Y+2cKijtTOsgAAIx/+AABDwDYAAF9MAgACaLek= Date: Tue, 12 May 2020 14:32:29 +0000 Message-ID: References: <202005100017.04A0Hd7I058863@repo.freebsd.org> <6739df0b-e621-2ca5-8f92-821822733772@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: 501da98e-a172-4b08-b087-08d7f6814cd7 x-ms-traffictypediagnostic: QB1PR01MB3427: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0401647B7F x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: PU3jXYgQWUpj55+aq0JoYsBhFs9WXnNyrx/qT56GgZ4AOotEcyIIPrmJMo1clyado2dtW0yhdJOvKiYblKl0fGr/PB53eUuyywJBtOR2mi9UqeWijgwYv06M/ivkh22woLIo+ERiak2srTMbb6u9tW/kqkXwcBmrp0wezpquQOlkU0F5p6IM2UPm9k1Ow/uW24zH5vC9E1u3ONrKr3bC2HF7LUpNC5HHeLW8XlwSW0BnbHKp9I2SVncMFTvBFvnuhRVyuJnmNi/CQ4mUREkMSYNe4Ar2DJIFJjEldsC4LzrczFsu2IFkfr6jJ0bixNbdiIbfsQLZI4JvM/8XmsTIwwMCtC3KREUNDTe1CXQKt+5vegIj38UwOTTPmMoRqrTHII45B4RPHYAetj5V4rqnOdymV8RT9GLj9VCv4vKZrpiEc2lFJ2O2YY2dvQs6Uro6aXi2fv/5ZL3Xt0nYcMgMHZT1nFIXr7MZy/KXTCsSVj9EoiILhGZO+t26UOcEZkll28VE8lbwkbnHvGqazJp4xM6IoLxuJAsw0j49rXL3JmF17dnAtFFnu4GVImxXbJmOINRkuU6oYNcqNDwrdQTNEPU6XB92cxoXiMWz2WD77jY= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:QB1PR01MB3649.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(366004)(39860400002)(136003)(396003)(376002)(346002)(33430700001)(786003)(52536014)(86362001)(316002)(33440700001)(66556008)(66446008)(7696005)(66476007)(76116006)(966005)(55016002)(66946007)(64756008)(8676002)(54906003)(186003)(478600001)(71200400001)(2906002)(6506007)(6916009)(8936002)(33656002)(9686003)(5660300002)(4326008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: q1/ODOLA0hIMo97zFny79LtSGM/ctkPnP7sYfvHLGwMHBA/hpaQwr0wueZ0YM25HNA5UBQYG8QmyAcz1E/Z/JO28ds8th1/JjD7cxBAuLsXDrTt5GLx2PoQKHFo8YkDve/mG0MIzR1OkKeBaEd36Wyzp6wUQQuen73z1kQxSSaOJPM7jAGXnEeK0FM3akqQd7zh6r0mC/CRXFMUgPB79dYnK7jEIuH0Os5AvyGYm+nRMsBrrozuDfAYiTtdvgCST/n8AQ2ZV8T3gyIWZQFwHNy5TfcbN3JYrI4XWGQONgkmd12uKSzefdJo8jmW/SX1latiggfz6qZUNVZCbuaA9tmrvhRxNdiUGI+lFgNMY+5SM6mch1xW091Z7Wh4s1aNTywdJtyCdps5delxsuN66qd4T4zxQZDVuGcCaVGI2zgpoH8CHipa/uyGHKe0d1ofzzZ+A8o+WdmRzsZGWgN7Yil913jqdkp3KwX/JD4oVzHWXEZ1EAF3kTgOKJy1s3TsHEena7kuopXnGPn+qLtG4vqJWxARyUtbgYCDQlnQ9GPA= 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: 501da98e-a172-4b08-b087-08d7f6814cd7 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 May 2020 14:32:29.5812 (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: C1xVaJAZEyIupSLqzae1QKxSL7flaDjNKF1NMmrvE+gL4t4Wn3PAuqI6k74YZ3WDqVid9Yy+yxfYt14b2WqjUg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: QB1PR01MB3427 X-Rspamd-Queue-Id: 49M0dD0FBMz4KJ8 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector1 header.b=nIRZkH5P; dmarc=none; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 2a01:111:f400:fe5d::612 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-6.00 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a01:111:f400::/48]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[uoguelph.ca]; RCPT_COUNT_FIVE(0.00)[5]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca.dwl.dnswl.org : 127.0.11.1]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[uoguelph.ca:+]; IP_SCORE(-1.50)[ipnet: 2a01:111:f000::/36(-4.20), asn: 8075(-3.25), country: US(-0.05)]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8075, ipnet:2a01:111:f000::/36, country:US]; ARC_ALLOW(-1.00)[i=1] X-BeenThere: svn-src-projects@freebsd.org X-Mailman-Version: 2.1.33 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: Tue, 12 May 2020 14:32:33 -0000 Benjamin Kaduk wrote:=0A= [stuff snipped]=0A= >You can avoid having to play games with putting stuff back on the socket= =0A= >receive buffer by using a custom BIO implementation in userspace that know= s=0A= >how to inject the received message.=0A= >Rick Macklem wrote:=0A= >>Actually, what might work for the krpc code is a new MSG_TLSAPPDATA=0A= >>flag for soreceive_generic(), which says "if the record is not applicatio= n=0A= >>data, return an error". (Sort of the opposite of what you said above, but= =0A= >>would perform the same thing.)=0A= >>This could be used for the krpc soreceive() calls, so that the non-applic= ation=0A= >>data record remains on the socket's receive buffer.=0A= Well, I'd find it a lot easier to implement MSG_TLSAPPDATA, since I've been= =0A= looking at soreceive_generic() recently.=0A= I'm guessing that a custom BIO would need to be written and the upstreamed= =0A= to openssl?=0A= =0A= Does anyone else (John maybe) have a preference?=0A= =0A= >>Then the krpc could do the upcall when the error is returned by soreceive= ()=0A= >>and the userland daemon could do an SSL_read() with=0A= >>SSL_MODE_AUTO_RETRY turned off. If I understand the man page, that will= =0A= >>make SSL_read() process the non-application data record but return with a= n=0A= >>error of SSL_ERROR_WANT_READ without taking application data off the=0A= >>socket's receive buffer queue.=0A= >=0A= >The typical way to consume non-application-data records without hanging tr= ying=0A= >to read any application data is to do a zero-length read. This still gets= far enough=0A= >into the state machine machinery to do the job before checking that the le= ngth=0A= >is nonzero.=0A= Oh, that's useful info. I recall trying it months ago and it didn't seem to= work.=0A= Maybe I was just seeing the failure and not realizing that it had worked bu= t returned=0A= failure. I'll play with this using my userland test daemons.=0A= [most stuff snipped]=0A= >In the early-data case things are more complicated. Calling regular SSL_r= ead() will=0A= >drive the handshake to completion, and there's a separate function to call= to just=0A= >try to read early data. (You could also configure things to fully deny ea= rly data which=0A= >would probably be easier.)=0A= Thanks. Good suggestion. I've never known what to do with the early data wh= en I=0A= played with the test daemons. (Again, I just threw it away.)=0A= =0A= Btw, I think I can test this using TLS1.2 because when one end does SSL_shu= tdown(),=0A= TLS1.2 sends an "alert close" and I can try handling that.=0A= =0A= Thanks for the comments, rick=0A= =0A= -Ben=0A= =0A= I might be stuck having the daemon do an SSL_read() for one application dat= a=0A= record and then it can pass that data back down into the kernel to be prepe= nded=0A= on the queue of received application data.=0A= =0A= >(I wouldn't want to MSG_PEEK for every record, since these will be rare.)= =0A= >I also do already have code that blocks kernel reception when the upcall= =0A= >to do the handshake is done, so the same could be used in this case.=0A= >=0A= >There is the slight trick that the client krpc code is in a socket upcall = that can't sleep,=0A= >so I'll have to hand it off to some other thread that can sleep when I nee= d to do it.=0A= >=0A= >Thanks for the hints, rick=0A= rick=0A= --=0A= John Baldwin=0A= _______________________________________________=0A= svn-src-projects@freebsd.org mailing l= ist=0A= https://lists.freebsd.org/mailman/listinfo/svn-src-projects=0A= To unsubscribe, send any mail to "svn-src-projects-unsubscribe@freebsd.org<= mailto:svn-src-projects-unsubscribe@freebsd.org>"=0A=