public inbox for linux-rdma@vger.kernel.org
 help / color / mirror / Atom feed
From: Zhu Yanjun <zyjzyj2000@gmail.com>
To: Honggang LI <honggangli@163.com>
Cc: jgg@ziepe.ca, leon@kernel.org, rpearsonhpe@gmail.com,
	matsuda-daisuke@fujitsu.com, linux-rdma@vger.kernel.org
Subject: Re: [PATCH] RDMA/rxe: Fix responder length checking for UD request packets
Date: Tue, 28 May 2024 13:10:00 +0200	[thread overview]
Message-ID: <71e37594-818a-493d-b3fa-9616e34bfe75@linux.dev> (raw)
In-Reply-To: <Zk_y-DYV_2fOSxOF@fc39>

On 24.05.24 03:52, Honggang LI wrote:
> On Thu, May 23, 2024 at 05:03:12PM +0200, Zhu Yanjun wrote:
>> Subject: Re: [PATCH] RDMA/rxe: Fix responder length checking for UD request
>>   packets
>> From: Zhu Yanjun <yanjun.zhu@linux.dev>
>> Date: Thu, 23 May 2024 17:03:12 +0200
>>
>>
>> On 23.05.24 14:06, Zhu Yanjun wrote:
>>>
>>> On 23.05.24 11:46, Honggang LI wrote:
>>>> According to the IBA specification:
>>>> If a UD request packet is detected with an invalid length, the request
>>>> shall be an invalid request and it shall be silently dropped by
>>>> the responder. The responder then waits for a new request packet.
>>>>
>>>> commit 689c5421bfe0 ("RDMA/rxe: Fix incorrect responder length
>>>> checking")
>>>> defers responder length check for UD QPs in function `copy_data`.
>>>> But it introduces a regression issue for UD QPs.
>>>>
>>>> When the packet size is too large to fit in the receive buffer.
>>>> `copy_data` will return error code -EINVAL. Then `send_data_in`
>>>> will return RESPST_ERR_MALFORMED_WQE. UD QP will transfer into
>>>> ERROR state.
>>>>
>>>> Fixes: 689c5421bfe0 ("RDMA/rxe: Fix incorrect responder length
>>>> checking")
>>>> Signed-off-by: Honggang LI <honggangli@163.com>
>>>> ---
>>>>    drivers/infiniband/sw/rxe/rxe_resp.c | 12 ++++++++++++
>>>>    1 file changed, 12 insertions(+)
>>>>
>>>> diff --git a/drivers/infiniband/sw/rxe/rxe_resp.c
>>>> b/drivers/infiniband/sw/rxe/rxe_resp.c
>>>> index 963382f625d7..a74f29dcfdc9 100644
>>>> --- a/drivers/infiniband/sw/rxe/rxe_resp.c
>>>> +++ b/drivers/infiniband/sw/rxe/rxe_resp.c
>>>> @@ -354,6 +354,18 @@ static enum resp_states
>>>> rxe_resp_check_length(struct rxe_qp *qp,
>>>>         * receive buffer later. For rmda operations additional
>>>>         * length checks are performed in check_rkey.
>>>>         */
>>>> +    if ((qp_type(qp) == IB_QPT_GSI) || (qp_type(qp) == IB_QPT_UD)) {
>>>
>>>  From IBA specification:
>>>
>>> "
>>>
>>> QP1, used for the General Services Interface (GSI).
>>> •This QP uses the Unreliable Datagram transport service.
>>> •All traffic to and from this QP uses any VL other than VL15.
>>> •GSI packets arriving before the current packet’s command completes may
>>> be dropped (i.e. the minimum queue depth of QP1 is one).
>>>
>>> "
>>>
>>> GSI should be MAD packets. And it should have a fixed format. Not sure
>>> if the payload of GSI packets will exceed the size of the recv buffer.
> 
> It's dangerous to trust remote GSI request packets always fit in local
> receive buffer. A well-designed hostile GSI request packet can render
> remote QP1 into ERROR state. That means the remote node can't establish
> new RC QP connections.

Thanks, Honggang.
Based on our discussion, this seems to be a security problem. It seems 
that this problem is related with MLX5. Before MLX5 engineers jump into 
this problem, to RXE, this commit can avoid RXE hang in ERROR state.

LGTM.

Zhu Yanjun

> 
> Thanks
> 


  reply	other threads:[~2024-05-28 11:10 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-23  9:46 [PATCH] RDMA/rxe: Fix responder length checking for UD request packets Honggang LI
2024-05-23 12:06 ` Zhu Yanjun
2024-05-23 15:03   ` Zhu Yanjun
2024-05-24  1:52     ` Honggang LI
2024-05-28 11:10       ` Zhu Yanjun [this message]
2024-05-30 14:13         ` Leon Romanovsky
2024-05-30 14:17 ` Leon Romanovsky
2024-06-07  8:57   ` Zhu Yanjun
2024-06-09 10:38     ` Leon Romanovsky

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=71e37594-818a-493d-b3fa-9616e34bfe75@linux.dev \
    --to=zyjzyj2000@gmail.com \
    --cc=honggangli@163.com \
    --cc=jgg@ziepe.ca \
    --cc=leon@kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=matsuda-daisuke@fujitsu.com \
    --cc=rpearsonhpe@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox