Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Wed, 26 Jan 2022 13:28:25 -0800
From:   Saeed Mahameed <saeedm@nvidia.com>
To:     Kees Cook <keescook@chromium.org>
Cc:     Leon Romanovsky <leon@kernel.org>,
        "David S. Miller" <davem@davemloft.net>,
        Jakub Kicinski <kuba@kernel.org>,
        Alexei Starovoitov <ast@kernel.org>,
        Daniel Borkmann <daniel@iogearbox.net>,
        Jesper Dangaard Brouer <hawk@kernel.org>,
        John Fastabend <john.fastabend@gmail.com>,
        netdev@vger.kernel.org, linux-rdma@vger.kernel.org,
        bpf@vger.kernel.org, Andrii Nakryiko <andrii@kernel.org>,
        Martin KaFai Lau <kafai@fb.com>,
        Song Liu <songliubraving@fb.com>, Yonghong Song <yhs@fb.com>,
        KP Singh <kpsingh@kernel.org>, linux-kernel@vger.kernel.org,
        linux-hardening@vger.kernel.org
Subject: Re: [PATCH v2 RESEND] net/mlx5e: Avoid field-overflowing memcpy()
Message-ID: <20220126212825.ph3w3umkwvpvtokx@sx1>
References: <20220124172028.2410761-1-keescook@chromium.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <20220124172028.2410761-1-keescook@chromium.org>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?B7DqMBeE7kVM8SHJVG+opUTta3s4g00TJHM0g8EWedxb4y8cUOoULcUsU0Ra?=
 =?us-ascii?Q?0tJx/ALKxYWf7o/pJ7EpOjjSp6j2E+lLToTgJ70rpIO0wtS20OyXDz1d5mXe?=
 =?us-ascii?Q?g6oEEMAlDxYRg9nGFN/G5lv5oO9+NK35eSKZGBLUjuzbnJEFmrI0MGAUIdck?=
 =?us-ascii?Q?4OfQmzJKujTy44rd/MSwjKeJpGuJ2OI+wBeiWt7HlNvXNOJiFw7off7CQ9Cf?=
 =?us-ascii?Q?f88NPwB7+boQOIB0gX78MNRdSP3iuErCajQwm5MtSwBWqwWr6NVanilUsLrN?=
 =?us-ascii?Q?qmPVbOZgF3j09ydukXBA6uq3msMzI9m3aSJijW01oV1x/ulbcCfGUWyiUrnV?=
 =?us-ascii?Q?KhZ+bop0tAg6sBstyxHu58/F+UkqPQjgjCdHGHJg5SICM/31ilByEDLhSReW?=
 =?us-ascii?Q?0FlRH2oqPmE941IflGrbiV12cLuiB1lVo8Pj9XOvStqZQaOoeonY0CYEs/hk?=
 =?us-ascii?Q?oB2Nis86zZVSzGZBrIJv+x9kgpLwPxx3+VDIMsRbeWVckUxdMjBjpMY4P+/V?=
 =?us-ascii?Q?1JGbvHIB69as2PXjfng2a9bCHM0T1ztGGm/KQC65QwbnVbAIZfym9B4jpsxv?=
 =?us-ascii?Q?fX7jJHOGI1nLz6LCJFS62jBNbXqauC47dK0neYZzVFYZs5XbVytDwz4f3g+I?=
 =?us-ascii?Q?BU52Mu7VyyxgRYoNcKS3TYZbpljwa3mPqfNbJ9PAXYJxYtIHUWq/elxJU/8P?=
 =?us-ascii?Q?eTTvo/KdP0Jo0PAhTIu/NXRQ6XnAoNFLKv5XYcjtT8UTPDLCl/P9NEKdff2q?=
 =?us-ascii?Q?lqKTRHDyon58gFwOYP/T/5T9lZHSkgbZ7DBYR3oGtyAYNfUJzEqQf2On63FE?=
 =?us-ascii?Q?UCMx4MG6ZqpSWaIp99eCQv6Hz/MAhntDqv+y/xc4i8aetNkvrzv2CAmlzWcK?=
 =?us-ascii?Q?GbHCrKBLORsFpARyQw8NjsCBAdMQLFOoQm2OyLuoDSFdDTdP+evoiNa1D3X6?=
 =?us-ascii?Q?PR0AA3TVt6QYQWK/7jMCJkUh+8X/PqT9fCVYcLed2SaKoVvti14gYns2B0Jw?=
 =?us-ascii?Q?yLttWDefTiUGGzye1AtaCT/0veLrP0WF6KfW75OEO9EzZsICjPmAoU5gR8eP?=
 =?us-ascii?Q?HTwKi6lfaVs3sadQ6Z0Wv7PaeAHZiDA9U/VCjed37NeUDbAGpc4JTQiElRfC?=
 =?us-ascii?Q?Rs4rQCYHP+osMAb8b9kybvL2mMbcD4oY5bMtHSU1pDWvRzSqDxuvhCV5QMn0?=
 =?us-ascii?Q?y1l5J/S0wuclNJcVwwl97HwM8l9iBNj130tZIg32ef6LduR3KXAO9AcPS7OD?=
 =?us-ascii?Q?aGXkpZ+xCsUwwjOJRGKg5Xg1BD093RePlaJtnnYiRu7MvVNEtW0XFEVDzAkx?=
 =?us-ascii?Q?VBs0btdEb9YhKyD+dWKSayzb7o1aF7DxWQ2tC+ZkwuhxIIXmpkAYZHEKYGte?=
 =?us-ascii?Q?UKeVehvw85/5dTNmY+kwZQEjy7Nj9KubLEki+U/jIR/kmSzOTWRr0VznuOvG?=
 =?us-ascii?Q?6ponuEqKEpqIAf0AJ6djyosdluoGO5K8lmvMlbK8ojjNxZhkDImIr1B6RI95?=
 =?us-ascii?Q?o3jCNetWQID5u+AL0d7Hu5eJyTK2mSKAWN7vAZphE7OA+9wsLTcDatDlarzA?=
 =?us-ascii?Q?V95FBN0Y8Vv8FUED/yEirfs/KZMihlxSpWgMGBxztzOEqVRhSvcWsDqxOhuW?=
 =?us-ascii?Q?KZ3GpA4M9zA4+64Fh8VkpVE=3D?=
X-OriginatorOrg: Nvidia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f1989e22-f02e-4cc3-fd08-08d9e112ca4f
X-MS-Exchange-CrossTenant-AuthSource: BY5PR12MB4209.namprd12.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Jan 2022 21:28:27.1737
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: UFTCEm83FxUIY6N2I5YMzcpvmwDPE124ynf7m/bVPK1EmjmYD9L8N7NkMcV/HPuNrdZZF+WZC50TjP08cGvx0Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB3465
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 24 Jan 09:20, Kees Cook wrote:
>In preparation for FORTIFY_SOURCE performing compile-time and run-time
>field bounds checking for memcpy(), memmove(), and memset(), avoid
>intentionally writing across neighboring fields.
>
>Use flexible arrays instead of zero-element arrays (which look like they
>are always overflowing) and split the cross-field memcpy() into two halves
>that can be appropriately bounds-checked by the compiler.
>
>We were doing:
>
>	#define ETH_HLEN  14
>	#define VLAN_HLEN  4
>	...
>	#define MLX5E_XDP_MIN_INLINE (ETH_HLEN + VLAN_HLEN)
>	...
>        struct mlx5e_tx_wqe      *wqe  = mlx5_wq_cyc_get_wqe(wq, pi);
>	...
>        struct mlx5_wqe_eth_seg  *eseg = &wqe->eth;
>        struct mlx5_wqe_data_seg *dseg = wqe->data;
>	...
>	memcpy(eseg->inline_hdr.start, xdptxd->data, MLX5E_XDP_MIN_INLINE);
>
>target is wqe->eth.inline_hdr.start (which the compiler sees as being
>2 bytes in size), but copying 18, intending to write across start
>(really vlan_tci, 2 bytes). The remaining 16 bytes get written into
>wqe->data[0], covering byte_count (4 bytes), lkey (4 bytes), and addr
>(8 bytes).
>
>struct mlx5e_tx_wqe {
>        struct mlx5_wqe_ctrl_seg   ctrl;                 /*     0    16 */
>        struct mlx5_wqe_eth_seg    eth;                  /*    16    16 */
>        struct mlx5_wqe_data_seg   data[];               /*    32     0 */
>
>        /* size: 32, cachelines: 1, members: 3 */
>        /* last cacheline: 32 bytes */
>};
>
>struct mlx5_wqe_eth_seg {
>        u8                         swp_outer_l4_offset;  /*     0     1 */
>        u8                         swp_outer_l3_offset;  /*     1     1 */
>        u8                         swp_inner_l4_offset;  /*     2     1 */
>        u8                         swp_inner_l3_offset;  /*     3     1 */
>        u8                         cs_flags;             /*     4     1 */
>        u8                         swp_flags;            /*     5     1 */
>        __be16                     mss;                  /*     6     2 */
>        __be32                     flow_table_metadata;  /*     8     4 */
>        union {
>                struct {
>                        __be16     sz;                   /*    12     2 */
>                        u8         start[2];             /*    14     2 */
>                } inline_hdr;                            /*    12     4 */
>                struct {
>                        __be16     type;                 /*    12     2 */
>                        __be16     vlan_tci;             /*    14     2 */
>                } insert;                                /*    12     4 */
>                __be32             trailer;              /*    12     4 */
>        };                                               /*    12     4 */
>
>        /* size: 16, cachelines: 1, members: 9 */
>        /* last cacheline: 16 bytes */
>};
>
>struct mlx5_wqe_data_seg {
>        __be32                     byte_count;           /*     0     4 */
>        __be32                     lkey;                 /*     4     4 */
>        __be64                     addr;                 /*     8     8 */
>
>        /* size: 16, cachelines: 1, members: 3 */
>        /* last cacheline: 16 bytes */
>};
>
>So, split the memcpy() so the compiler can reason about the buffer
>sizes.
>
>"pahole" shows no size nor member offset changes to struct mlx5e_tx_wqe
>nor struct mlx5e_umr_wqe. "objdump -d" shows no meaningful object
>code changes (i.e. only source line number induced differences and
>optimizations).
>
>Cc: Saeed Mahameed <saeedm@nvidia.com>
>Cc: Leon Romanovsky <leon@kernel.org>
>Cc: "David S. Miller" <davem@davemloft.net>
>Cc: Jakub Kicinski <kuba@kernel.org>
>Cc: Alexei Starovoitov <ast@kernel.org>
>Cc: Daniel Borkmann <daniel@iogearbox.net>
>Cc: Jesper Dangaard Brouer <hawk@kernel.org>
>Cc: John Fastabend <john.fastabend@gmail.com>
>Cc: netdev@vger.kernel.org
>Cc: linux-rdma@vger.kernel.org
>Cc: bpf@vger.kernel.org
>Signed-off-by: Kees Cook <keescook@chromium.org>
>---
>Since this results in no binary differences, I will carry this in my tree
>unless someone else wants to pick it up. It's one of the last remaining
>clean-ups needed for the next step in memcpy() hardening.

applied to net-next-mlx5.

Thanks,
Saeed