Received: by 2002:a05:6602:2086:0:0:0:0 with SMTP id a6csp4436798ioa; Wed, 27 Apr 2022 03:59:56 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy2gxngEvcuT8AHv6i3HhOiPgIWd1konx9z3bxScjFitW6IfgHkAB8XJWPJM13y405SEDJ5 X-Received: by 2002:a63:d454:0:b0:386:86:6aaa with SMTP id i20-20020a63d454000000b0038600866aaamr23546672pgj.60.1651057196171; Wed, 27 Apr 2022 03:59:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1651057196; cv=none; d=google.com; s=arc-20160816; b=qvyu3/E7pmgeG3I1+m0BYcrbMIBOyCOVL6MsXC6te1+Oxn9gpaw6VCcQ5iNRUWJ5Z/ 3wothduKV7Cf6B117nLcGfDwq9AtvGhIeWD0xbhvdlgZdTJ70SGsWdlZgDuE/6wssUpi KfsQKNhYW3WExvgTyfORFyswNry/KtC4gaXzzyYT4l4K+uSfCeFBgelCxhjIlfWpogbl VKO9BgIGL/BlnMzrMqzE3cenJpjHcIyI6PDuLkpRA1fbN6AjEGeqbXFR/UNmImItmJ/M 9ZRsdXF1Yg07fRJsCTHh7SiPiWrDnEalNltl+tU2XQPNScC6nrqTt+o2Oc1DA9I6d/1c PSNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :dkim-signature; bh=UqLxJFH9O9G7EGONJdF7zaPGDT+Gp5Rj4MUtQs90Rw8=; b=rFGFsRFcPZSAOwP3olO6GPZP7+alFoUlOo6/Ne00ADTObQ78uBLrtAGezQkJlO36vE W2ogppXvrvnVdChirZLkQkeTNDT4hnjnvgyz6RvcqykGFRzYzKrSNSn50MR6DBsJeslN 1iTk8f7ag5L7y/EJgaZlu0Bn6fxj2P7j4ETPpq/gOxiR6FIHW2ic+yNuAiiv+wCr61LZ Cw/bxg0T1XEgnHvQRpu/vttB79ottSF/Gx5jWUL6TGWYvQVTa2wo02LJxhgo6tG5dYpH aDbsRSvHBTPcLMBLdt3nLTIpUyWfi1L9PdIEPcqLfS7zmCWXyqfbPN0MWI9aFjtkWJHJ 9i0g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=AffRiqDd; spf=softfail (google.com: domain of transitioning linux-nfs-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id oc13-20020a17090b1c0d00b001cb8bfcc721si1769086pjb.7.2022.04.27.03.59.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Apr 2022 03:59:56 -0700 (PDT) Received-SPF: softfail (google.com: domain of transitioning linux-nfs-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=AffRiqDd; spf=softfail (google.com: domain of transitioning linux-nfs-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (out1.vger.email [IPv6:2620:137:e000::1:20]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 743B344C51B; Wed, 27 Apr 2022 03:07:47 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1351866AbiDZPF7 (ORCPT + 99 others); Tue, 26 Apr 2022 11:05:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56328 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348182AbiDZPF6 (ORCPT ); Tue, 26 Apr 2022 11:05:58 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9FF9F6D4FA; Tue, 26 Apr 2022 08:02:50 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 37C71618B3; Tue, 26 Apr 2022 15:02:50 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2A504C385AC; Tue, 26 Apr 2022 15:02:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1650985369; bh=UqLxJFH9O9G7EGONJdF7zaPGDT+Gp5Rj4MUtQs90Rw8=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=AffRiqDdE3sz/LCauzO5r2DR1u8X3ZBhcg7XT7VKTU3vrSH6dNifdcC9oPMhnaaRD tooa/9C3ApCFhD//EgeHVZ82iVkKzlYd2B6UqG57bnBNJ0fPNqq6OhT/hX0c5vDWeh rgfmRxorcK/qZvO1uhoIRGxhWmZumkGnIeQXAV1Tf0QSVEqf9IVRlvkmQOcSCXdhy8 0J9ZWL6F67+N2w8N8QWxhosFSa49dwqVNg3/FVKrcvf/IpkP/UKcxgzgEYl7pzBJwa ++gNj9yu0l2OoOLlPC4pNJ0y7KuGlv4TJ5jfpzGVJ/jrYBuytNv8GWIdigaG0WTmsx eQ7dmMOvblH/w== Date: Tue, 26 Apr 2022 08:02:47 -0700 From: Jakub Kicinski To: Sagi Grimberg Cc: Hannes Reinecke , Chuck Lever , netdev@vger.kernel.org, linux-nfs@vger.kernel.org, linux-nvme@lists.infradead.org, linux-cifs@vger.kernel.org, linux-fsdevel@vger.kernel.org, ak@tempesta-tech.com, borisp@nvidia.com, simo@redhat.com Subject: Re: [PATCH RFC 4/5] net/tls: Add support for PF_TLSH (a TLS handshake listener) Message-ID: <20220426080247.19bbb64e@kernel.org> In-Reply-To: <1fca2eda-83e4-fe39-13c8-0e5e7553689b@grimberg.me> References: <165030051838.5073.8699008789153780301.stgit@oracle-102.nfsv4.dev> <165030059051.5073.16723746870370826608.stgit@oracle-102.nfsv4.dev> <20220425101459.15484d17@kernel.org> <66077b73-c1a4-d2ae-c8e4-3e19e9053171@suse.de> <1fca2eda-83e4-fe39-13c8-0e5e7553689b@grimberg.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RDNS_NONE,SPF_HELO_NONE autolearn=unavailable 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: X-Mailing-List: linux-nfs@vger.kernel.org On Tue, 26 Apr 2022 17:29:03 +0300 Sagi Grimberg wrote: > >> Create the socket in user space, do all the handshakes you need there > >> and then pass it to the kernel.=C2=A0 This is how NBD + TLS works.=C2= =A0 Scales > >> better and requires much less kernel code. > >> =20 > > But we can't, as the existing mechanisms (at least for NVMe) creates th= e=20 > > socket in-kernel. > > Having to create the socket in userspace would require a completely new= =20 > > interface for nvme and will not be backwards compatible. =20 >=20 > And we will still need the upcall anyways when we reconnect=20 > (re-establish the socket) That totally flew over my head, I have zero familiarity with in-kernel storage network users :S In all honesty the tls code in the kernel is a bit of a dumping ground. People come, dump a bunch of code and disappear. Nobody seems to care that the result is still (years in) not ready for production use :/ Until a month ago it'd break connections even under moderate memory pressure. This set does not even have selftests. 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.