From: Leon Romanovsky <leon@kernel.org>
To: Zhu Yanjun <zyjzyj2000@gmail.com>
Cc: Honggang LI <honggangli@163.com>,
jgg@ziepe.ca, 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: Thu, 30 May 2024 17:13:40 +0300 [thread overview]
Message-ID: <20240530141340.GA3884@unreal> (raw)
In-Reply-To: <71e37594-818a-493d-b3fa-9616e34bfe75@linux.dev>
On Tue, May 28, 2024 at 01:10:00PM +0200, Zhu Yanjun wrote:
> 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.
Current RDMA network is designed with assumption that all participants
are trusted.
Thanks
>
> LGTM.
>
> Zhu Yanjun
>
> >
> > Thanks
> >
>
next prev parent reply other threads:[~2024-05-30 14:26 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
2024-05-30 14:13 ` Leon Romanovsky [this message]
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=20240530141340.GA3884@unreal \
--to=leon@kernel.org \
--cc=honggangli@163.com \
--cc=jgg@ziepe.ca \
--cc=linux-rdma@vger.kernel.org \
--cc=matsuda-daisuke@fujitsu.com \
--cc=rpearsonhpe@gmail.com \
--cc=zyjzyj2000@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