From owner-svn-src-projects@freebsd.org Wed Jul 1 23:21:11 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 3187835E381 for ; Wed, 1 Jul 2020 23:21:11 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-qb1can01on060d.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe5c::60d]) (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 49xy0618pbz3y0p; Wed, 1 Jul 2020 23:21:09 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=H/nzfbVa7JpC1mNsb7XtfU7f5Pc0NpXD0CocFFFegmVaqO0huEUYDzkwbEkuFcChOZTcJXzDupalyPYJ/bJUK6Mipl0JHmReoYasDOpDI7D2l/xIYL6eDbSCVz5H/p4Z/hERMueVUfi3t0CaybOQMZeDW2knqadyjjSLIgFefQX4R8VHCAgqHasZ9p3xy+jHkI8CEo1E7T3j1QGUF0Xc+7cBq8tQw7aS8WCNXY8G74nA5x8jCkRVnP0vdHkvy3QPzP4vcPBc8+vDi3edqg5A54PLGecyt+8GeX3oZHvXI7Wb0LPFExRJWsKuu7d1+JWxWeBBjrVCKjUI3F+7vjP85Q== 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=xzf2TYlHFIzvOYJ2bWy5vk+/PJ7aCtYEaofGP7t+k6c=; b=gMkC9LkI0WOgmgFsx49IZvLkAMEvNHPCcenG8W7S4dFb07yEZ0FBpEuAWHl9zrimn5Qi7EpTbIwtL5UKzKbd9bzgUBPrHVgBjUuX9kQTA3l4Pi7Eh1Rs2mOmCLQ9KH9nQYmBVoOoi3gJRZEd0kIpYpG33XDhe4Y+MobXBNzv5zvEFTvsT9g8b7CLRmP1ZVKdqh4xfciXmmc9G8/yV6QdFQIKzwRbLs+yzhFdtGPslOw64q0qJeShsoN2T74+qTErIqLmHamavsWobKA+cAqY+rFHFtB2o1RYPJCO+YUNPpudSc9dJLyceyYW6CJBtmTff56lpVXtyowxQL4m+zYw7w== 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=xzf2TYlHFIzvOYJ2bWy5vk+/PJ7aCtYEaofGP7t+k6c=; b=S+ReE++aKJEm9Iu82fbkVqW/oH2D/L/Xio2ECIqZYkkluXv0zLkSSLKvJcgFQmYKwjPucT+Koxut02HPyMXciR4ImkihD+wJyPNTpBMo+ZRAi3ehJDVEqqtJil/FMid3ZzPFsFITYg6Mhl92T8BV6nOllvPVhWpWNVzSyMQPyK2r/PRE/afddGdfbjK8D+JvazMxlZ5ZfcBDGP1ncSJ+J9GF8/jjqNCy6uMJjJADTdsUd66L5IX8WPjX5pzMnFZKhyhha+rRXdYzus7VOtJpeGPsbmrqx9U1zhh83zw+zaAQFOxw1h5B59/v4J+TF3d9OjUar58X5SiVw1XeT4Wjfg== Received: from QB1PR01MB3364.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:38::14) by QB1PR01MB2882.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:36::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.20; Wed, 1 Jul 2020 23:21:07 +0000 Received: from QB1PR01MB3364.CANPRD01.PROD.OUTLOOK.COM ([fe80::60f3:4ca2:8a4a:1e91]) by QB1PR01MB3364.CANPRD01.PROD.OUTLOOK.COM ([fe80::60f3:4ca2:8a4a:1e91%7]) with mapi id 15.20.3131.034; Wed, 1 Jul 2020 23:21:07 +0000 From: Rick Macklem To: Benjamin Kaduk CC: Benjamin Kaduk , Rick Macklem , src-committers , "svn-src-projects@freebsd.org" Subject: Re: svn commit: r362798 - in projects/nfs-over-tls/sys/rpc: . rpcsec_tls Thread-Topic: svn commit: r362798 - in projects/nfs-over-tls/sys/rpc: . rpcsec_tls Thread-Index: AQHWTu29MoFCP0YO4kaq4Sj4aYWIUajxUeOAgAAARmyAAAhnAIAAg0Q8gAANlPuAABMqAIABUrapgAAE0ICAAAH3+w== Date: Wed, 1 Jul 2020 23:21:07 +0000 Message-ID: References: <202006301449.05UEnq2x072917@repo.freebsd.org> <20200630163340.GN58278@kduck.mit.edu> <20200701022040.GE58278@kduck.mit.edu> , <20200701225011.GH58278@kduck.mit.edu> In-Reply-To: <20200701225011.GH58278@kduck.mit.edu> 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: 269d0c7c-0885-4951-4003-08d81e156eb1 x-ms-traffictypediagnostic: QB1PR01MB2882: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2733; x-forefront-prvs: 04519BA941 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5EB1QmQG3Tz9+oS17/lU5jCyopbfx9cGM6dPdB71j0RPlB2DMzbEkoCCB+0TXGrgN5XKW2V6n5TUsHWPsHYZvSp1JIqIjJIGitb1AuVIjalVZczierDplgJ0M5KKu9BDhpX3tct7UriMlApz8q1T618lXRMfRkxQkXuwFayYvZ9WnOFmfdCDHKhvVvTX35KfQZ90UAfkd3Zd2QFg2IEGEvgG+m9D3jx9qtsL7JpEh/ItDgvURHnBQEJiGevOe5yEqMOXl5HNkNNCoZ84YPp2HjxEn+BH+h/KveP3xVs3KqiZblE1j8gBiuoRW1ru9jFBibuyOr+FIjBXfM/Ew6MwOw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:QB1PR01MB3364.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(366004)(346002)(39850400004)(396003)(136003)(376002)(64756008)(66556008)(66476007)(66446008)(6506007)(9686003)(7696005)(478600001)(71200400001)(186003)(4326008)(83380400001)(86362001)(786003)(54906003)(316002)(8676002)(52536014)(55016002)(76116006)(91956017)(66946007)(5660300002)(33656002)(2906002)(6916009)(8936002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: IJU1gzjemOSQSjrhjlsifO07GQIL6IFZKTJ4+GGqvlzsw5eZD/qnd4sTesKvPX8SHZ1uFkMEeYPqGJb2amp08GrAjU8XmB9Jm3CLTc+CmMZ4Ggi9WLd0AbMCOpDTg+jNgF/IOVk0qBamIly/CfFpQIpy5Warrkb2c592engSzZTdRQmOqMxnZGBCBqhgO3lD3tWlHb3DqSxOyQI+xtHrSweZY+wy0t1FHwgOiVBAUZJ1AaBwIt4D9+mdPMVFz0JyuKOo0msEROuxLL1tp9j9MRJ7cKH0o2z3S1mJxn6LnjnfEuIAPU/UxjA50rlOx+OW5fxDVAkbkgX16RUA2dfDUzz5e2n+QRcvKbep8rUP3cANURfZHFxlc1ruA6t+HY2bThjKtr6H5IF6Wh6NZlEKrRU6w/T61yl9yrPYmKLKRT+U4iUOw0oPG2DKRrQrxLgESPfVKfxcJvPFZhT7A8wedv4wTl6FVJrtbwuiScqHwG6AtKJ6L64dzm8Dx9AYhKVecCgnpUzXnYnhSpSBbzvOoJNXShVEjR4u9jDEAaFFSDGzA5c4OqAA5Wr0ow1EBBXB 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-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: QB1PR01MB3364.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 269d0c7c-0885-4951-4003-08d81e156eb1 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jul 2020 23:21:07.2552 (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: BV+7QvCQLriK/ALVSV1nNgNSsdG0ZX2BosoLzdIPxYwVMM0MuyOFOzLGd97e7evre2h8dl2yF1s015ahLRHC9Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: QB1PR01MB2882 X-Rspamd-Queue-Id: 49xy0618pbz3y0p X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector1 header.b=S+ReE++a; dmarc=none; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 2a01:111:f400:fe5c::60d as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-4.84 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.005]; 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.004]; 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:dkim]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[uoguelph.ca:+]; NEURAL_HAM_SHORT(-0.33)[-0.332]; 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]; FREEMAIL_CC(0.00)[gmail.com,FreeBSD.org,freebsd.org]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901: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: Wed, 01 Jul 2020 23:21:11 -0000 Benjamin Kaduk wrote:=0A= >Rick Macklem wrote:=0A= >> >Benjamin Kaduk wrote:=0A= [stuff snipped]=0A= >> >=0A= >> >Can't you set a client-side (e.g., read) timeout, though?=0A= >> Well, in this case it would be the read (or recv or ??) that is done ins= ide the=0A= >> SSL_connect().=0A= >>=0A= >> The timer I can control is the one that I had set to 10minutes, which ti= mes out=0A= >> the upcall RPC to the userland daemon. I had set it to 10minutes so the= =0A= >> SSL_connect() would time out first, but now that I know that won't alway= s happen..=0A= >> This timer is now set to 15sec and after it times out, the kernel code d= oes a=0A= >> soshutdown(so, SHUT_RD) in the client, which seems to be sufficient to g= et=0A= >> SSL_connect() to return an error.=0A= >>=0A= >> This seems sufficient and works ok for the testing I've done.=0A= >=0A= >I don't think what you ended up with is wrong, to be clear.=0A= >=0A= >But, you have an SSL* as input to SSL_connect(), and you can call=0A= >SSL_get_fd() on that SSL*, which will give you a socket fd that you can=0A= >call setsockopt() on, if you're so inclined. The SSL_connect() abstractio= n=0A= >barrier is not leak-proof :)=0A= Well, actually in this case it is kind of the opposite..=0A= - The kernel RPC creates a socket ("struct socket *", no file descriptor)= =0A= - The daemon does a rpctls_syscall() to acquire a file descriptor referenci= ng=0A= the socket during the connect upcall.=0A= - The daemon does a SSL_set_fd() to tell the openssl library about the sock= et=0A= to use.=0A= But, yes, the daemon does know what the socket file descriptor is.=0A= =0A= What you were suggesting was a setsockopt(so, SO_RCVTIMEO..) then?=0A= =0A= That would work too, I'd guess.=0A= =0A= I would have some reservations about doing it that way.=0A= - I suspect the openssl library will always be prepared for a socket clos= ure (EOF),=0A= but I'm not so sure the library would expect a read failure with errno= =3D=3D=0A= EWOULDBLOCK. I'd have to look at the library sources and I'd also be= =0A= concerned that the situation might change w.r.t. this in the library.= =0A= =0A= But if soshutdown(so, SHUT_RD) stops working, a setsockopt(so, SO_RCVTIMEO)= =0A= would certainly be an alternate approach.=0A= =0A= It is always a little scary when you are using a "black box" like the opens= sl=0A= libraries and doing somewhat unusual things.=0A= =0A= rick=0A= =0A= =0A= > 15sec is pretty arbitrary, but I figure a timeout on the order of seconds= is=0A= > reasonable for RPC upcalls to the local daemon. (I'd guess that taking ev= en=0A= > 1sec to do an upcall would indicate something is broken.)=0A= > If others feel 15sec isn't an appropriate timeout, feel free to comment.= =0A= > (Note that this timeout should only happen when something is broken, like= =0A= > the server that does a "STARTTLS" reply but does not do a TLS handshake.= )=0A= =0A= Understood.=0A= =0A= Thanks,=0A= =0A= Ben=0A= =0A=