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+BkiXOp6ayeNVBq0A6XOAgAFYlQCAABKoAIAAEbcA
Date:   Tue, 26 Apr 2022 15:58:29 +0000
Message-ID: <BA6BB8F6-3A2A-427B-A5D7-30B5F778B7E0@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>
In-Reply-To: <20220426075504.18be4ee2@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?eK0fZPenmab8Q+FU2vWqrHdhBrd/zwyr7daqKPeTUnE8roIYoglZAHBaSnCI?=
 =?us-ascii?Q?YLK9dsD6bZa7Ea1Zdaww1xe6DHRhUA12myP+cro1F4ENJdPFkTBWgIwtEn1r?=
 =?us-ascii?Q?/KP0PNAQAqBbv8QeB8UjsihFCjiTdfjQwld/e9fNxNG7HYAYCArmN+LniKEt?=
 =?us-ascii?Q?ee1lWYR5AiSiywMMHsoSxAZXrimrZSIGmFopx3qUid/u/DVGq2gT8X+sdGYy?=
 =?us-ascii?Q?w9NEUO9BQPg6zNckWSc3oEjRZ6YiJ0NhptW7km4bUYgXzP7laPZ1QgPw66vx?=
 =?us-ascii?Q?aiLSCNUV2lYLViJRjKLKnLo9R2sRVSQfrdJzL/mhz+bvvvQm75CLAkO2GCUa?=
 =?us-ascii?Q?DTqp+sX+YhpfAwn3nxSCy7pOwpI6oEKd/ImW75nXTI8n/ITj08erzkfbvslD?=
 =?us-ascii?Q?Rx36w266os4UrIXDUEoLsdBNxFN4jTAXcbdE01MRxASbm0jJrUC+SiaB14Qo?=
 =?us-ascii?Q?hFXpWUfDcE9v+wfq6mj9FdfOmsu0etFzP5sKshnpC4Cd3oWc8Sq5XuTxakGn?=
 =?us-ascii?Q?j9A5SIhelCIB1eDtYOCMxvUOH+IV5uK6IXWCqXLvJ5f7P4qeZnF9SW60zObL?=
 =?us-ascii?Q?Y0h5d7nu/TorDkaNLQtASklZxNWnOZQ0ayjYoAfnPf6+isJ5lHCp1h01aDDS?=
 =?us-ascii?Q?/YDnv1n384z07xnOkAEcV/+cLOsHJVVMQm1HsSC7N/ozSFOlTTcL/0MDg9aI?=
 =?us-ascii?Q?FvAtqF6rykxX4AYMq796Ty8++Z2LuNKja7DeLL+Agy8DA2/vEUeCocEffLK/?=
 =?us-ascii?Q?53EM0Ek0tdjKdOMj/klWGUepkhC4NZb59RGU0gYhoFh7CKjBUqheibT9wsCq?=
 =?us-ascii?Q?xd9gNJuBtJb3LZxbd7NSJopAErg0HI79+gxygC7INv/Z1VCc8k+5uMtuSKex?=
 =?us-ascii?Q?dG1rOJnjk89sdBrAfZkIoEAEv4RDpVeglCL/MTkqVP0Gkum+ISWKnk/VAN/+?=
 =?us-ascii?Q?OifRc4H9BIDzR6xBSk5gitvUq7ZHhbElu2A9ce2dS4TXz1pxVUB/iiR9Bx+S?=
 =?us-ascii?Q?1+PXmXjljHYE7T7iH98URwVato9/3d7cj3klvbGOSDCGFDn7Srkv1onEfNeS?=
 =?us-ascii?Q?tu5RE45oNSS8J0ibEXjwn86LU6+Ync0QfZ3fhv5XsI/huOPrgN9uwMjaBn4Z?=
 =?us-ascii?Q?hzYA0i5FgEemWRyXUS2jmZNpiVBrxYIMn5kFvNz8cjzuWrojC+xr8C/vKJI6?=
 =?us-ascii?Q?NcieEsgnXVKE+p/0xKbtc+zw3jUYgE+S9rFQtUdSzuNe6hiaByd3PBn4ikKA?=
 =?us-ascii?Q?CBlafM6r0C1KyoigcyZ5/onet2suQRZizZl4e0pqKcuaU62EW2xMjfs5lUeN?=
 =?us-ascii?Q?PCOcqCRHasxG+r/uuAhD63Q2gKyQHWmEhbvOf6Nv3ZLxGDxR2x6aK9bExcpH?=
 =?us-ascii?Q?NXmgmpvCT59nwxKU695xSWMwGz2rrtAjUo9hQAqcbkOuvR7M5YsXFkp9mv6d?=
 =?us-ascii?Q?fT7y1VeQ/0ZceakCjaZ0T1J2ZcXA5hrT8inSW0K7DHMg6boa2FbE3V9o2slm?=
 =?us-ascii?Q?tGOk1VhkDpxjK4bpsBwGu3EAScgCtq3hYqA0G54JVt8qS7YIsjqToeul/8fP?=
 =?us-ascii?Q?Q1efRM/wnl9YqTGESNrj3qkfzlP8LdJz+Bdf5YwKSi4P41NyKaD8t3yaknkk?=
 =?us-ascii?Q?mG3VPDoy7LEECk1acKHM6EMoF5+GdrsH5xBdQr0tHTWm4cRUGa1tSgNmkVQv?=
 =?us-ascii?Q?D44nopC8AG4WH5rJLxHjWW08y/O9/TTru3i3DAHcIkc+lyJhIbPECgX2Rs56?=
 =?us-ascii?Q?HrVHdXU75iYs6L4hxgm0I8i6XR8OU4g=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <64E2B96AF1A06C419AD15E09EFB65BF3@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: 77452933-27f2-4e48-7aef-08da279d9b0b
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Apr 2022 15:58:29.0749
 (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: 0QMiT/ygn9+vpO3yQfq9iuWhztRWfgZPAK2jdMtmjO8ICgqN4NBPFTm0s6Bmd7ZzCLtZ7/kRQy6O+XY1v9EaQw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR10MB4271
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.486,18.0.858
 definitions=2022-04-26_04:2022-04-26,2022-04-26 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 spamscore=0 adultscore=0
 mlxscore=0 bulkscore=0 suspectscore=0 malwarescore=0 mlxlogscore=840
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000
 definitions=main-2204260101
X-Proofpoint-ORIG-GUID: cNxx0F5KkMBruHhr--iprTh8_G7gJ22R
X-Proofpoint-GUID: cNxx0F5KkMBruHhr--iprTh8_G7gJ22R
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 26, 2022, at 10:55 AM, Jakub Kicinski <kuba@kernel.org> wrote:
>=20
> On Tue, 26 Apr 2022 13:48:20 +0000 Chuck Lever III wrote:
>>> Create the socket in user space, do all the handshakes you need there
>>> and then pass it to the kernel.  This is how NBD + TLS works.  Scales
>>> better and requires much less kernel code. =20
>>=20
>> The RPC-with-TLS standard allows unencrypted RPC traffic on the connecti=
on
>> before sending ClientHello. I think we'd like to stick with creating the
>> socket in the kernel, for this reason and for the reasons Hannes mention=
s
>> in his reply.
>=20
> Umpf, I presume that's reviewed by security people in IETF so I guess
> it's done right this time (tm).

> Your wording seems careful not to imply that you actually need that,
> tho. Am I over-interpreting?

RPC-with-TLS requires one RPC as a "starttls" token. That could be
done in user space as part of the handshake, but it is currently
done in the kernel to enable the user agent to be shared with other
kernel consumers of TLS. Keep in mind that we already have two
real consumers: NVMe and RPC-with-TLS; and possibly QUIC.

You asserted earlier that creating sockets in user space "scales
better" but did not provide any data. Can we see some? How well
does it need to scale for storage protocols that use long-lived
connections?

Also, why has no-one mentioned the NBD on TLS implementation to
us before? I will try to review that code soon.


> This set does not even have selftests.

I can include unit tests with the prototype. Someone needs to
educate me on what is the preferred unit test paradigm for this
type of subsystem. Examples in the current kernel code base would
help too.


> Plus there are more protocols being actively worked on (QUIC, PSP etc.)
> Having per ULP special sauce to invoke a user space helper is not the
> paradigm we chose, and the time as inopportune as ever to change that.

When we started discussing TLS handshake requirements with some
community members several years ago, creating the socket in
kernel and passing it up to a user agent was the suggested design.
Has that recommendation changed since then?

I'd prefer an in-kernel handshake implementation over a user
space one (even one that is sharable amongst transports and ULPs
as my proposal is intended to be). However, so far we've been told
that an in-kernel handshake implementation is a non-starter.

But in the abstract, we agree that having a single TLS handshake
mechanism for kernel consumers is preferable.


--
Chuck Lever