Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
From:   Chuck Lever III <chuck.lever@oracle.com>
To:     Trond Myklebust <trondmy@hammerspace.com>
CC:     "linux-cifs@vger.kernel.org" <linux-cifs@vger.kernel.org>,
        "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
        "linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "simo@redhat.com" <simo@redhat.com>,
        "ak@tempesta-tech.com" <ak@tempesta-tech.com>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
        "borisp@nvidia.com" <borisp@nvidia.com>
Subject: Re: [PATCH RFC 08/15] SUNRPC: Add RPC_TASK_CORK flag
Thread-Topic: [PATCH RFC 08/15] SUNRPC: Add RPC_TASK_CORK flag
Thread-Index: AQHYU0UH7NIJR860dUOYblj2e849Maz2i/EAgAEAwYCAAA1cAIAACfaA
Date:   Tue, 19 Apr 2022 19:40:10 +0000
Message-ID: <B7355D85-1CCF-4836-9B85-E6C9E019CD9E@oracle.com>
References: <165030062272.5246.16956092606399079004.stgit@oracle-102.nfsv4.dev>
 <165030072175.5246.14868635576137008067.stgit@oracle-102.nfsv4.dev>
 <a771c65353d0805fc5f028fa56691ee762d6843f.camel@hammerspace.com>
 <AE1190F4-EDE4-4C2D-94C9-02A5EDAAFBC6@oracle.com>
 <36618d90e44961aed7b40c4640952fd574fce60c.camel@hammerspace.com>
In-Reply-To: <36618d90e44961aed7b40c4640952fd574fce60c.camel@hammerspace.com>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?8xmoy22Y/2vkwO2khRzfk276rPKErJa0gNJ6JWmYTzmndQNFMDan0RUGgt9O?=
 =?us-ascii?Q?7W1TGcijE2xwOfTmSOd8VdoVIgNn2kBvP7MKnu2gg4Zm0HQfHsj3DH8oXCZI?=
 =?us-ascii?Q?VAqDiyBXyOo5/p36G0kEGjB+d9P0ZJUxDYlmMEsl06jiHmGZaaNfE6a2KlOR?=
 =?us-ascii?Q?mZdu0q1F9uzlQSCJXEA/KGyBi5j1wmd/uzPD3/yo/JsZno9172bjoqEdJKMs?=
 =?us-ascii?Q?WGHRyZbX7E4LW6z2AZiBZq6qT4WtoVdFhIzLcNfbK07JUGKs6BdOUEMfiY5M?=
 =?us-ascii?Q?fJNlA5pBOOBcUhMPgGy3iBKxqGhpTJe6ynRONH9iz3JwsLBVHSF55RMZfn6h?=
 =?us-ascii?Q?HGUUmHalavgXZ34pi/AZ3dl625l3+/6qjkGbDloqgj/8dlkprkoW2LXB227o?=
 =?us-ascii?Q?1FSFZ2pVqIp+CibRePyW6mbdMv3a1x6BkN/zA6gYX6buVwhzr4tXA+M8gOlZ?=
 =?us-ascii?Q?liF1Yi8G70oEOy1NIfwvNyl1JtEob80mBz5gOCQ3dUgN+feK87aj4AuWFdMJ?=
 =?us-ascii?Q?QJgzWHRqVrkAhZPNSv65cM0IAEHEfSl1AMnysY17nOYrvDCdMJ5AYznfbR89?=
 =?us-ascii?Q?siNQUFAK5YEBOGIhTh8QYM1oKKPDlCgqPUlrXndCblP/TMx6LwgWbzvKQi3T?=
 =?us-ascii?Q?xLFyLl8jDEIUeHjNHfQatvFsL15RrcPl2CfHqAkUDOw949HweQWnlQNFjr7W?=
 =?us-ascii?Q?Oi2Rkwb0xFcAU5hQRpRYBwPeCaMSj4MQJHurNsgl4GG/b/qeWbMqfVPoWqSQ?=
 =?us-ascii?Q?r9KEgBxi81o0Su6g5K9TQVfW8LLNY6/kFSlTMcxRdqsTyfTkyFSDb4Qog2Li?=
 =?us-ascii?Q?z645FWfNZxgHgDgio0bTuqw2jCf9bl+NKAJ5avKm6Okm6viKTZ5HOEZ05HEQ?=
 =?us-ascii?Q?ka8ltv8NuhTPLS2sCFVOx5cz9LOj6eq54JRQeXk7HAa8B1uUMKCy+0upbT0m?=
 =?us-ascii?Q?qfVEDARpgFVBDr8q1zKWGgOPDinzvXnkR+AUhH+5f8y+qgtLF7dhuvOCPMYz?=
 =?us-ascii?Q?yQ3mm7niha+mafSTOH8PnwM5u0SzJToaWptYdUNenHw90XaAvIqbXKeY2hBW?=
 =?us-ascii?Q?5DtD8MYClZKGvUvPwRF0mJxxTluI0S5oKmUspr2jP8qP1gANFeaOpYQjf3GB?=
 =?us-ascii?Q?4ehjN4HXyv7tHIOzPX8UaDWldqvyTFbpjys26Kk3Bw4xEojgqLnPyAYAniOf?=
 =?us-ascii?Q?8UNP1SazJK1uJY72IzI6Rd+2Nv+X3oAllQJPSNkMcMm7RW/a1+6vCxP83k6F?=
 =?us-ascii?Q?V9xol5ELuq9w1yPTAYdkkoqUPvudq3B7qi9tBfb/KKFWFuf4W/ZCt/F7gyA2?=
 =?us-ascii?Q?HU86OOIBOAmgDq2eHox5ERjdTCeppm52r+p+4Vg3H1GhevAaODxzh97OzQZH?=
 =?us-ascii?Q?w2RK1bgkFbLjrHeB1B4bXuSP7SlXTD94REUD2P2ovvsXElQXzpNE9xsAkyAH?=
 =?us-ascii?Q?wFeKMZKPyLwOz+HQUe+4Gp/3xaIEIQ1ls/oirNUADorKZve8hrWVCXqw2HaX?=
 =?us-ascii?Q?KU2AkJyM9x44N2u6+tvGS7noC0aoIRWDXF2C9zxto0FvPgBqxN1qjbSDiGWb?=
 =?us-ascii?Q?yL9prdKWWYw+/Qtv8iwLwEszfsQERFGdheIUE3rbcAsX8LcaEhvDQIIoKbES?=
 =?us-ascii?Q?LOSxXyH0SUzPIaWXgY5ecHAeCghC4IMmnqcbaZGTZ0AKodDl4+Yy7b+AA8Yb?=
 =?us-ascii?Q?dmAcnNo1Y2xVKPIoQjf7E9PwjDR2dSJ7GavGnVFUBoyIlIna3dBAdHFeS5wW?=
 =?us-ascii?Q?q6myeIinlqYldk0pLLgWEZcZhVlTTpU=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <CCA815AB4FC1AC479E9A3206739D3865@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: 2c814be9-2790-4374-78af-08da223c6a2f
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Apr 2022 19:40:10.0287
 (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: FcHnq8nCDMNIlaHVyXFuRkkp6mTg+OyXL6RxPVFM2ZT8PNkf+a1NMkro5donsHi+RCaY75iyrW3NPISCey8tWQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN0PR10MB5333
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.486,18.0.858
 definitions=2022-04-19_07:2022-04-15,2022-04-19 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 bulkscore=0
 suspectscore=0 mlxscore=0 spamscore=0 mlxlogscore=999 phishscore=0
 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1
 engine=8.12.0-2202240000 definitions=main-2204190110
X-Proofpoint-ORIG-GUID: wWBQEIw0JjFBAdLu1n6rFZh2iyaKQLzn
X-Proofpoint-GUID: wWBQEIw0JjFBAdLu1n6rFZh2iyaKQLzn
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE autolearn=no
	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 19, 2022, at 3:04 PM, Trond Myklebust <trondmy@hammerspace.com> wr=
ote:
>=20
> On Tue, 2022-04-19 at 18:16 +0000, Chuck Lever III wrote:
>>=20
>>=20
>>> On Apr 18, 2022, at 10:57 PM, Trond Myklebust
>>> <trondmy@hammerspace.com> wrote:
>>>=20
>>> On Mon, 2022-04-18 at 12:52 -0400, Chuck Lever wrote:
>>>> Introduce a mechanism to cause xprt_transmit() to break out of
>>>> its
>>>> sending loop at a specific rpc_rqst, rather than draining the
>>>> whole
>>>> transmit queue.
>>>>=20
>>>> This enables the client to send just an RPC TLS probe and then
>>>> wait
>>>> for the response before proceeding with the rest of the queue.
>>>>=20
>>>> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
>>>> ---
>>>>  include/linux/sunrpc/sched.h  |    2 ++
>>>>  include/trace/events/sunrpc.h |    1 +
>>>>  net/sunrpc/xprt.c             |    2 ++
>>>>  3 files changed, 5 insertions(+)
>>>>=20
>>>> diff --git a/include/linux/sunrpc/sched.h
>>>> b/include/linux/sunrpc/sched.h
>>>> index 599133fb3c63..f8c09638fa69 100644
>>>> --- a/include/linux/sunrpc/sched.h
>>>> +++ b/include/linux/sunrpc/sched.h
>>>> @@ -125,6 +125,7 @@ struct rpc_task_setup {
>>>>  #define RPC_TASK_TLSCRED               0x00000008      /* Use
>>>> AUTH_TLS credential */
>>>>  #define RPC_TASK_NULLCREDS             0x00000010      /* Use
>>>> AUTH_NULL credential */
>>>>  #define RPC_CALL_MAJORSEEN             0x00000020      /* major
>>>> timeout seen */
>>>> +#define RPC_TASK_CORK                  0x00000040      /* cork
>>>> the
>>>> xmit queue */
>>>>  #define RPC_TASK_DYNAMIC               0x00000080      /* task
>>>> was
>>>> kmalloc'ed */
>>>>  #define        RPC_TASK_NO_ROUND_ROBIN         0x00000100    =20
>>>> /*
>>>> send requests on "main" xprt */
>>>>  #define RPC_TASK_SOFT                  0x00000200      /* Use
>>>> soft
>>>> timeouts */
>>>> @@ -137,6 +138,7 @@ struct rpc_task_setup {
>>>> =20
>>>>  #define RPC_IS_ASYNC(t)                ((t)->tk_flags &
>>>> RPC_TASK_ASYNC)
>>>>  #define RPC_IS_SWAPPER(t)      ((t)->tk_flags &
>>>> RPC_TASK_SWAPPER)
>>>> +#define RPC_IS_CORK(t)         ((t)->tk_flags & RPC_TASK_CORK)
>>>>  #define RPC_IS_SOFT(t)         ((t)->tk_flags &
>>>> (RPC_TASK_SOFT|RPC_TASK_TIMEOUT))
>>>>  #define RPC_IS_SOFTCONN(t)     ((t)->tk_flags &
>>>> RPC_TASK_SOFTCONN)
>>>>  #define RPC_WAS_SENT(t)                ((t)->tk_flags &
>>>> RPC_TASK_SENT)
>>>> diff --git a/include/trace/events/sunrpc.h
>>>> b/include/trace/events/sunrpc.h
>>>> index 811187c47ebb..e8d6adff1a50 100644
>>>> --- a/include/trace/events/sunrpc.h
>>>> +++ b/include/trace/events/sunrpc.h
>>>> @@ -312,6 +312,7 @@ TRACE_EVENT(rpc_request,
>>>>                 { RPC_TASK_TLSCRED, "TLSCRED"
>>>> },                        \
>>>>                 { RPC_TASK_NULLCREDS, "NULLCREDS"
>>>> },                    \
>>>>                 { RPC_CALL_MAJORSEEN, "MAJORSEEN"
>>>> },                    \
>>>> +               { RPC_TASK_CORK, "CORK"
>>>> },                              \
>>>>                 { RPC_TASK_DYNAMIC, "DYNAMIC"
>>>> },                        \
>>>>                 { RPC_TASK_NO_ROUND_ROBIN, "NO_ROUND_ROBIN"
>>>> },          \
>>>>                 { RPC_TASK_SOFT, "SOFT"
>>>> },                              \
>>>> diff --git a/net/sunrpc/xprt.c b/net/sunrpc/xprt.c
>>>> index 86d62cffba0d..4b303b945b51 100644
>>>> --- a/net/sunrpc/xprt.c
>>>> +++ b/net/sunrpc/xprt.c
>>>> @@ -1622,6 +1622,8 @@ xprt_transmit(struct rpc_task *task)
>>>>                 if (xprt_request_data_received(task) &&
>>>>                     !test_bit(RPC_TASK_NEED_XMIT, &task-
>>>>> tk_runstate))
>>>>                         break;
>>>> +               if (RPC_IS_CORK(task))
>>>> +                       break;
>>>>                 cond_resched_lock(&xprt->queue_lock);
>>>>         }
>>>>         spin_unlock(&xprt->queue_lock);
>>>>=20
>>>>=20
>>>=20
>>> This is entirely the wrong place for this kind of control
>>> mechanism.
>>=20
>> I'm not sure I entirely understand your concern, so bear with
>> me while I try to clarify.
>>=20
>>=20
>>> TLS vs not-TLS needs to be decided up front when we initialise the
>>> transport (i.e. at mount time or whenever the pNFS channels are set
>>> up). Otherwise, we're vulnerable to downgrade attacks.
>>=20
>> Downgrade attacks are prevented by using "xprtsec=3Dtls" because
>> in that case, transport creation fails if either the AUTH_TLS
>> fails or the handshake fails.
>>=20
>> The TCP connection has to be established first, though. Then the
>> client can send the RPC_AUTH_TLS probe, which is the same as the
>> NULL ping that it already sends. That mechanism is independent
>> of the lower layer transport (TCP in this case).
>>=20
>> Therefore, RPC traffic must be stoppered while the client:
>>=20
>> 1. waits for the AUTH_TLS probe's reply, and
>>=20
>> 2. waits for the handshake to complete
>>=20
>> Because an RPC message is involved in this interaction, I didn't
>> see a way to implement it completely within xprtsock's TCP
>> connection logic. IMO, driving the handshake has to be done by
>> the generic RPC client.
>>=20
>> So, do you mean that I need to replace RPC_TASK_CORK with a
>> special return code from xs_tcp_send_request() ?
>=20
>=20
> I mean the right mechanism for controlling whether or not the transport
> is ready to serve RPC requests is through the XPRT_CONNECTED flag. All
> the existing generic RPC error handling, congestion handling, etc
> depends on that flag being set correctly.
>=20
> Until the TLS socket has completed its handshake protocol and is ready
> to transmit data, it should not be declared connected. The distinction
> between the two states 'TCP is unconnected' and 'TLS handshake is
> incomplete' is a socket/transport setup detail as far as the RPC xprt
> layer is concerned: just another set of intermediate states between
> SYN_SENT and ESTABLISHED.

First, TLS is technically an upper layer protocol. It's not
part of the transport protocol. This is exactly how it's
implemented in the Linux kernel. And, TLS works on transports
other than TCP, so that makes it a reasonable candidate for
treatment in the generic client rather than in a particular
transport mechanism.

Second, the "intermediate states" would be /outside/ of SYN_SENT
and ESTABLISHED. A TCP transport has to be in the ESTABLISHED
state (ie, the transport's connection handshake has to be
complete) before any TLS traffic can go over it.

Most importantly, the client has to send an RPC message first
before it can start a TLS handshake. The RPC-with-TLS protocol
specification requires that the handshake be preceded with the
NULL AUTH_TLS request, which is an RPC. Otherwise, there's no
way for the server end to know when to expect a handshake.

In today's RPC client, the underlying connection has to be in
the XPRT_CONNECTED state before the RPC client can exchange any
RPC transaction, including AUTH_TLS NULL.

To make it work the way you've suggested, we would have to build
a mechanism that could send the AUTH_TLS NULL and receive and
parse its reply /before/ the client has put the transport into
the XPRT_CONNECTED state, and that NULL request would have to
be driven from inside the transport instance (not via the FSM
where all other RPC traffic originates).

Do you have any suggestions about how to make this last point
less painful?


--
Chuck Lever