Re: [PATCH v5 net-next 13/13] mlx5: support BIG TCP packets

[Kees Cook <keescook@chromium.org>]

On Wed, May 11, 2022 at 09:26:48AM -0700, Jakub Kicinski wrote:
> On Tue, 10 May 2022 19:55:16 -0700 Kees Cook wrote:
> > On Mon, May 09, 2022 at 06:38:53PM -0700, Jakub Kicinski wrote:
> > > So we're leaving the warning for Kees to deal with?
> > > 
> > > Kees is there some form of "I know what I'm doing" cast 
> > > that you could sneak us under the table?  
> > 
> > Okay, I've sent this[1] now. If that looks okay to you, I figure you'll
> > land it via netdev for the coming merge window?
> 
> I was about to say "great!" but perhaps given we're adding an unsafe_
> flavor of something a "it is what it is" would be a more appropriate
> reaction.

Heh, well, I think it's just calling a spade a spade: plain memcpy is
already unsafe. The goal is for the kernel's (fortified) memcpy to be
"provably" safe. :) But yeah, I get what you mean. I'm sad that I don't
yet have a workable way to deal with this code pattern, but I'm getting
close, I think. My random notes currently are:

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tx.c b/drivers/net/ethernet/mellanox/mlx5/core/en_tx.c
index 2dc48406cd08..595d0db4e97a 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tx.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tx.c
@@ -386,6 +386,14 @@ mlx5e_sq_xmit_wqe(struct mlx5e_txqsq *sq, struct sk_buff *skb,
 			stats->added_vlan_packets++;
 		} else {
 			eseg->inline_hdr.sz |= cpu_to_be16(attr->ihs);
+/* interface could take:
+	fas: wqe
+	dst: eth.inline_hdr.start
+	src: skb->data
+	bytes: attr->ihs
+	elements member: data
+	elements_count value: wqe_attr->ds_cnt_inl
+*/
 			memcpy(eseg->inline_hdr.start, skb->data, attr->ihs);
 		}
 		dseg += wqe_attr->ds_cnt_inl;

There's a similar case with how netlink constructs things (i.e.
performing a memcpy across some of the trailing header members and then
into the flex array) that may share this code pattern, and at least one
patch to mlx5 I'd sent before could be refactored back into this to
unsplit the memcpy there.

Anyway, I'll continue to chip away at it.

-- 
Kees Cook