From owner-svn-src-projects@freebsd.org Wed May 20 04:59:54 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 05C9F2FEAB5 for ; Wed, 20 May 2020 04:59:54 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49RgXm6P3Nz4g27; Wed, 20 May 2020 04:59:52 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 04K4xmlo031313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 20 May 2020 00:59:50 -0400 Date: Tue, 19 May 2020 21:59:47 -0700 From: Benjamin Kaduk To: Rick Macklem Cc: Benjamin Kaduk , John Baldwin , Rick Macklem , "src-committers@freebsd.org" , "svn-src-projects@freebsd.org" Subject: Re: svn commit: r360859 - projects/nfs-over-tls/sys/rpc Message-ID: <20200520045947.GX58497@kduck.mit.edu> References: <202005100017.04A0Hd7I058863@repo.freebsd.org> <6739df0b-e621-2ca5-8f92-821822733772@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) X-Rspamd-Queue-Id: 49RgXm6P3Nz4g27 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of kaduk@mit.edu designates 18.9.28.11 as permitted sender) smtp.mailfrom=kaduk@mit.edu X-Spamd-Result: default: False [-1.87 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[24.16.140.251:received]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:18.9.28.0/24]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[mit.edu]; RCPT_COUNT_FIVE(0.00)[6]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[18.9.28.11:from]; NEURAL_HAM_SHORT(-0.59)[-0.587]; NEURAL_HAM_MEDIUM(-0.78)[-0.780]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:3, ipnet:18.9.0.0/16, country:US]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; RCVD_COUNT_TWO(0.00)[2] 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: Wed, 20 May 2020 04:59:54 -0000 On Tue, May 12, 2020 at 02:32:29PM +0000, Rick Macklem wrote: > Benjamin Kaduk wrote: > [stuff snipped] > >You can avoid having to play games with putting stuff back on the socket > >receive buffer by using a custom BIO implementation in userspace that knows > >how to inject the received message. > >Rick Macklem wrote: > >>Actually, what might work for the krpc code is a new MSG_TLSAPPDATA > >>flag for soreceive_generic(), which says "if the record is not application > >>data, return an error". (Sort of the opposite of what you said above, but > >>would perform the same thing.) > >>This could be used for the krpc soreceive() calls, so that the non-application > >>data record remains on the socket's receive buffer. > Well, I'd find it a lot easier to implement MSG_TLSAPPDATA, since I've been > looking at soreceive_generic() recently. > I'm guessing that a custom BIO would need to be written and the upstreamed > to openssl? It doesn't have to be upstreamed; the idea of the API is that it's modular and anyone can slot in their own implementation for their particular communication needs. -Ben