Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Chuck Lever III <chuck.lever@oracle.com>
To:     Jakub Kicinski <kuba@kernel.org>
CC:     netdev <netdev@vger.kernel.org>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
        "linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
        "linux-cifs@vger.kernel.org" <linux-cifs@vger.kernel.org>,
        "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
        "ak@tempesta-tech.com" <ak@tempesta-tech.com>,
        "borisp@nvidia.com" <borisp@nvidia.com>,
        "simo@redhat.com" <simo@redhat.com>
Subject: Re: [PATCH RFC 4/5] net/tls: Add support for PF_TLSH (a TLS handshake
 listener)
Thread-Topic: [PATCH RFC 4/5] net/tls: Add support for PF_TLSH (a TLS
 handshake listener)
Thread-Index: AQHYU0RqwCfhD8h+BkiXOp6ayeNVBq0A6XOAgAFYlQCAABKoAIAAEbcAgACC9gCAAPo/AIAAmfUAgAAanYCAAUmbgIAADJ6A
Date:   Thu, 28 Apr 2022 21:54:01 +0000
Message-ID: <661A8F3F-A95E-412E-B9A7-F35A95610729@oracle.com>
References: <165030051838.5073.8699008789153780301.stgit@oracle-102.nfsv4.dev>
 <165030059051.5073.16723746870370826608.stgit@oracle-102.nfsv4.dev>
 <20220425101459.15484d17@kernel.org>
 <E8809EC2-D49A-4171-8C88-D5E24FFA4079@oracle.com>
 <20220426075504.18be4ee2@kernel.org>
 <BA6BB8F6-3A2A-427B-A5D7-30B5F778B7E0@oracle.com>
 <20220426164712.068e365c@kernel.org>
 <7B871201-AC3C-46E2-98B0-52B44530E7BD@oracle.com>
 <20220427165354.2eed6c5b@kernel.org>
 <F64C2771-663D-4BE7-9EB9-A8859818C7F8@oracle.com>
 <20220428140851.6e9eebd5@kernel.org>
In-Reply-To: <20220428140851.6e9eebd5@kernel.org>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?Ziwax6lgDB9+Maf/ZJaZVhBMCn+z759Ox0I4kRna5RkD5LQTFrdjlJmnA8nT?=
 =?us-ascii?Q?4CMunYDYyTG11fgH7mUBHK6uqxJYwbJmDpW/pvjUriqS1rzq2xlGb1urqu5O?=
 =?us-ascii?Q?g+p4NejY2Mn07iECtD5bwv1WHRsr1yKvhP16XxZUMkCiQTwQK34qQ26FGKUX?=
 =?us-ascii?Q?IFX2TmGY8qYI7zltBpKZMaDhpK9OEixfZMt7KVbIzgspwdAVh6rbHu3L47/7?=
 =?us-ascii?Q?CHr99Gwb+OCIihDAwpLebpNcM0in1QScCuGDHevcJ2tnhWtxbmUil17osylC?=
 =?us-ascii?Q?DZTaHtxIZEGQZCAWCMgEWtax/gUkJ9PEAj1P+we1lGnt0KWIQlumx5Hj1MQE?=
 =?us-ascii?Q?1OlqpRj1l1LZGZ2zLZyrlvmcdxjsQwYXQhesAmvUNmFzb1FTh6+iyszWura/?=
 =?us-ascii?Q?clg9NOLINjgX/htrdmQh6o97pGqfnw7wjxPgswMC9QbeZd2JRJ3cB3P4gmjc?=
 =?us-ascii?Q?MsxGpuieDSWBa7M1/ZzlRenbKrphGNOUoX+ploVxutpFV0L6se2v8XUEAHMT?=
 =?us-ascii?Q?WN786R9oA4mgvASsku+XEmAQWxHGyU5bP8KOXAM8rua1xn9jPBZoRvPb33GS?=
 =?us-ascii?Q?eaNWAkmFVRsdq0HcZN3968l01O98iRwAX4Ax4UoXHylSz727DPKHoyWJEui3?=
 =?us-ascii?Q?xTHEABc1YVHtP6WxxzRsgC+/+cupTQbQ+J5Jv5ZDRmk4nfi8xQp56IkRHBr5?=
 =?us-ascii?Q?1YVPHes9lRQ7Ssul7T1UOl59+mh/D5xODE64RIqMkoZ/Kd7mNzBp8yiYOAro?=
 =?us-ascii?Q?sbM5Jym6MIKUKmqXxKtxG4xZa02YtM8REb1ndp+3490l3eLRLQnticEDD9AY?=
 =?us-ascii?Q?qGQ9FoOqixXzkaEJDcwTWL+1LvbS6vP9YlXdoHdgLau84sq38siy1GVFCF4o?=
 =?us-ascii?Q?fZxhcOqPONEhw9bWKGg1Tm22popL5GPdq+E7SoiPeMnxF1O99zyt8ix6DYog?=
 =?us-ascii?Q?CM4uVbO1f4DnyJknNnTUZCtytMITXjGqobXGiUltv2+YBLdyTe68QdOdtxgr?=
 =?us-ascii?Q?sqbY8/FOdaLYLwU06z690I82kZRU07g1ZpqUsLwjqjbdi4kjgNEtHJSO6hM4?=
 =?us-ascii?Q?vh0VI7vvOfuW2cwOTYWQW+hZ2iMXl0rcHIaKuk56X48h/eC5fWdrCXROYY1C?=
 =?us-ascii?Q?bklIdJMJlTbu3eLCL2noGPkReDg54uVr4KCqSelOhkhdjlq1XXwf/XV5UcHx?=
 =?us-ascii?Q?Nlz8oe8tuS8LGQLZrHUHMYuQI7WbtTqpbfnXfyihWKHp0kk8F/XHiwx5Fg5v?=
 =?us-ascii?Q?c0ZqLUgADQ+g4TqWdSK5jjVMfXmNDDmyeYyhhlC39H+Ndywuw9JfbYS7i9jZ?=
 =?us-ascii?Q?BaFprRvI2P7tOY10j+5IWEo8Jr8xq0fsxsB5Go5UcyiKhgZ86t8XvCEnFJd+?=
 =?us-ascii?Q?sg//ckSvHoDAPLU3yHSUkYpIB8wNyc0x22tCbJPJgKgY+ce8/GJZjIduI4Ab?=
 =?us-ascii?Q?iiZ5X/VXDQM931mmmc0N98vTxlBAoHUS5HhV8uydzIFiKDemW6DDZ9hBqtLg?=
 =?us-ascii?Q?SnyRSiMtqPQ/cN2MIK/9Qrm36uT2SQbLzG70aR1tQV0KKpGkIKsCV50gj6qO?=
 =?us-ascii?Q?AIpIuhMBFmWmx1LJcOhlzMFZTJesf+npyfy9wSgTC6YpkqeEBmYYMoSC++QJ?=
 =?us-ascii?Q?I5z306d1nBau6Y5hNmeehcdBUrw4PiYmyo5iilw9Bie4jrhoj3l7qqRKdbvz?=
 =?us-ascii?Q?755hHvvC8dnqG21vFrP2YZ4OwzqrD+c3q6h8bUMAhh0L7Ghn2j4O6WuIppqc?=
 =?us-ascii?Q?ZXATwPvDsRemDpqJe9jUyPdOsh594TA=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <C2A152BA4975DC4DB507253F325B75EE@namprd10.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN0PR10MB5128.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ee074f59-bc5c-439c-ebf7-08da29619b50
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Apr 2022 21:54:02.0215
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 8UZOPBo09vvCQiUNwCasaZHSXxOlWpiHiXu2y8akNNuo8QIYousK/rfaT77dISE6QeRPe/BGumn3cKd+zsYEYg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN0PR10MB5223
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.486,18.0.858
 definitions=2022-04-28_04:2022-04-28,2022-04-28 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 mlxlogscore=999
 malwarescore=0 mlxscore=0 phishscore=0 bulkscore=0 adultscore=0
 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2202240000 definitions=main-2204280128
X-Proofpoint-GUID: DjJJRuAKuPmDYt1m9nAfKMYzgC7Pz_IV
X-Proofpoint-ORIG-GUID: DjJJRuAKuPmDYt1m9nAfKMYzgC7Pz_IV
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,
        SPF_NONE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org


> On Apr 28, 2022, at 5:08 PM, Jakub Kicinski <kuba@kernel.org> wrote:
>=20
> On Thu, 28 Apr 2022 01:29:10 +0000 Chuck Lever III wrote:
>>> Is it possible to instead create a fd-passing-like structured message
>>> which could carry the fd and all the relevant context (what goes=20
>>> via the getsockopt() now)?
>>>=20
>>> The user space agent can open such upcall socket, then bind to
>>> whatever entity it wants to talk to on the kernel side and read
>>> the notifications via recv()? =20
>>=20
>> We considered this kind of design. A reasonable place to start there
>> would be to fabricate new NETLINK messages to do this. I don't see
>> much benefit over what is done now, it's just a different isomer of
>> syntactic sugar, but it could be considered.
>>=20
>> The issue is how the connected socket is materialized in user space.
>> accept(2) is the historical way to instantiate an already connected
>> socket in a process's file table, and seems like a natural fit. When
>> the handshake agent is done with the handshake, it closes the socket.
>> This invokes the tlsh_release() function which can check=20
>=20
> Actually - is that strictly necessary? It seems reasonable for NFS to
> check that it got TLS, since that's what it explicitly asks for per
> standard. But it may not always be the goal. In large data center
> networks there can be a policy the user space agent consults to choose
> what security to install. It may end up doing the auth but not enable
> crypto if confidentiality is deemed unnecessary.

> Obviously you may not have those requirements but if we can cover them
> without extra complexity it'd be great.

We can be flexible about how/where handshake success is checked.

However, using a simple close(2) to signal that the handshake
has completed does not communicate whether the handshake was
indeed successful. We will need a (richer) return/error code
from the handshake agent for that use case.


>> whether the IV implantation was successful.
>=20
> I'm used to IV meaning Initialization Vector in context of crypto,
> what does "IV implementation" stand for?

Implantation, not implementation. The handshake agent implants
the initialization vector in the socket before it closes it.


--
Chuck Lever