Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp802490pxj; Fri, 28 May 2021 16:34:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxq2rVtlCJQnbLg5RpXJxwWLWRsSwnvAA60qUrRb9x7FRXsGYDlZHhf/pDmF/WMQ3cKPHbK X-Received: by 2002:a05:6402:2217:: with SMTP id cq23mr12336353edb.29.1622244870944; Fri, 28 May 2021 16:34:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1622244870; cv=none; d=google.com; s=arc-20160816; b=hmV0pbF8AJ4HuzjCcR7hqUVS8dAMIwgH5qoOcwdFuDSEX1DuPugLf6D5HgsZPvkeCB j0mK5qFW9i91fVSZYRob8OpAS6YQnmoGRKDGUn4g9nGP4DU6xDIj0wqpzPtf73jSD1PW gM80JsDQOuTIfOeqXPH2xjwKkMIG0dujKvIU6jY2MNsj+OmsoO+WldcDGhEUYumAYFjv xP1qo/7uyQB6N+cxXY3hVuZZi78ue4RzdzIkoiQYr7BLMPlA3ubuzRkiODVn7kUP1NuM rBZcoXKjc/SVLuWDgPwgV3w56+cBtJAlEWBMFBhYagWS3mx11vcvp9BOB8Gyg7rm0OA7 nFBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=l0QiEp4fOc8S5QViRiss/YOyViBh54YK1qbk6itUu3Y=; b=DHqPC90EQ3xctHmo1Du9rgR7O2ZHOPeR/QpN000I7HdMowsePQXUziZE/fwmXPnmaL EQbbVq3sWmOi3bDbCfffjnz0UN2wrMy2dWE+4kpIlRQmbvL9mY/GwLmE4BzXeo1zc4+c GaryG4LicWJqm2PIvcMSFnPpWYrFJR0BYGlMYfZ58ZY8VYjOUPeUMkBdm8XNmOWI9loN uxqdI2KfwUHfYPU8TyZR59XqMbaQAxkYKn6YsDesC/TpYmVx97U1UfDDt8o3k2svPte9 nO2BpkBwnXGggr40fzuxPMc27mOryvXthHhPrVL+3XGPApJKJy4FM5FTQzgP7Rrc20ek 040g== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@embeddedor.com header.s=default header.b=hfHFdB2g; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r6si5922828edq.457.2021.05.28.16.34.07; Fri, 28 May 2021 16:34:30 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=fail header.i=@embeddedor.com header.s=default header.b=hfHFdB2g; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229635AbhE1X3x (ORCPT + 99 others); Fri, 28 May 2021 19:29:53 -0400 Received: from gateway20.websitewelcome.com ([192.185.65.13]:49072 "EHLO gateway20.websitewelcome.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229631AbhE1X3v (ORCPT ); Fri, 28 May 2021 19:29:51 -0400 X-Greylist: delayed 1370 seconds by postgrey-1.27 at vger.kernel.org; Fri, 28 May 2021 19:29:51 EDT Received: from cm13.websitewelcome.com (cm13.websitewelcome.com [100.42.49.6]) by gateway20.websitewelcome.com (Postfix) with ESMTP id 2E8BC400F809E for ; Fri, 28 May 2021 17:50:58 -0500 (CDT) Received: from gator4166.hostgator.com ([108.167.133.22]) by cmsmtp with SMTP id mlWFlSTkpAEP6mlWFlyBQy; Fri, 28 May 2021 18:03:55 -0500 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=embeddedor.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=l0QiEp4fOc8S5QViRiss/YOyViBh54YK1qbk6itUu3Y=; b=hfHFdB2gtMTdm+yR9F0X8Y8+Q7 WWt4ZoW+rct8us9Qm9jDnJ/hIWmWK1vXP/HixYtmhOmu2IRaNSqrVdkfY4WUfY91EwGDuPm7Am6ar sWuhSQ+AUbNrl0HlBVzjAudg3OYKRCRvTEZ+oXJhLAywfG7jkI0U76h8ToOpG/mXHY8N3LQRO1eXc n3MPtDG+iL6meF7nnhJPLzOJJ0M3HeEZaUMSvaiP3BeqtHUBonxZrNxCiUNAKZVEyM/nrFTIGmR2C /0vBA+O7+f2dOkhDJT9asucCecvfegs6WAaBKVeaD0/pM61wTZQyT9VGe0ZLpQQ5402htBSFbsxo7 MD+905Vw==; Received: from 187-162-31-110.static.axtel.net ([187.162.31.110]:39030 helo=[192.168.15.8]) by gator4166.hostgator.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1lmlWD-002pRA-6Z; Fri, 28 May 2021 18:03:53 -0500 Subject: Re: [Intel-wired-lan] [PATCH][next] virtchnl: Replace one-element array in struct virtchnl_vsi_queue_config_info To: "Nguyen, Anthony L" , "Brandeburg, Jesse" , "gustavoars@kernel.org" Cc: "intel-wired-lan@lists.osuosl.org" , "linux-kernel@vger.kernel.org" , "linux-hardening@vger.kernel.org" References: <20210525231658.GA176466@embeddedor> From: "Gustavo A. R. Silva" Message-ID: <85e62583-5db9-ac5c-fdf9-8e3f6a50f3fa@embeddedor.com> Date: Fri, 28 May 2021 18:04:51 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator4166.hostgator.com X-AntiAbuse: Original Domain - vger.kernel.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - embeddedor.com X-BWhitelist: no X-Source-IP: 187.162.31.110 X-Source-L: No X-Exim-ID: 1lmlWD-002pRA-6Z X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 187-162-31-110.static.axtel.net ([192.168.15.8]) [187.162.31.110]:39030 X-Source-Auth: gustavo@embeddedor.com X-Email-Count: 6 X-Source-Cap: Z3V6aWRpbmU7Z3V6aWRpbmU7Z2F0b3I0MTY2Lmhvc3RnYXRvci5jb20= X-Local-Domain: yes Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5/28/21 16:56, Nguyen, Anthony L wrote: > On Tue, 2021-05-25 at 18:16 -0500, Gustavo A. R. Silva wrote: >> There is a regular need in the kernel to provide a way to declare >> having a >> dynamically sized set of trailing elements in a structure. Kernel >> code >> should always use “flexible array members”[1] for these cases. The >> older >> style of one-element or zero-length arrays should no longer be >> used[2]. >> >> Refactor the code according to the use of a flexible-array member in >> struct >> virtchnl_vsi_queue_config_info instead of one-element array, and use >> the >> flex_array_size() helper. >> >> [1] https://en.wikipedia.org/wiki/Flexible_array_member >> [2] >> https://www.kernel.org/doc/html/v5.10/process/deprecated.html#zero-length-and-one-element-arrays >> >> Link: https://github.com/KSPP/linux/issues/79 >> Signed-off-by: Gustavo A. R. Silva >> --- >> include/linux/avf/virtchnl.h | 9 ++++----- >> 1 file changed, 4 insertions(+), 5 deletions(-) >> >> diff --git a/include/linux/avf/virtchnl.h >> b/include/linux/avf/virtchnl.h >> index b554913804bd..ed9c4998f8ac 100644 >> --- a/include/linux/avf/virtchnl.h >> +++ b/include/linux/avf/virtchnl.h >> @@ -338,10 +338,10 @@ struct virtchnl_vsi_queue_config_info { >> u16 vsi_id; >> u16 num_queue_pairs; >> u32 pad; >> - struct virtchnl_queue_pair_info qpair[1]; >> + struct virtchnl_queue_pair_info qpair[]; >> }; >> >> -VIRTCHNL_CHECK_STRUCT_LEN(72, virtchnl_vsi_queue_config_info); >> +VIRTCHNL_CHECK_STRUCT_LEN(8, virtchnl_vsi_queue_config_info); >> >> /* VIRTCHNL_OP_REQUEST_QUEUES >> * VF sends this message to request the PF to allocate additional >> queues to >> @@ -997,9 +997,8 @@ virtchnl_vc_validate_vf_msg(struct >> virtchnl_version_info *ver, u32 v_opcode, >> if (msglen >= valid_len) { >> struct virtchnl_vsi_queue_config_info *vqc = >> (struct virtchnl_vsi_queue_config_info >> *)msg; >> - valid_len += (vqc->num_queue_pairs * >> - sizeof(struct >> - virtchnl_queue_pair_info)) >> ; >> + valid_len += flex_array_size(vqc, qpair, >> + vqc- >>> num_queue_pairs); > > The virtchnl file acts as a binary interface between physical and > virtual functions. There's no guaruntee that the PF and VF will both > have the newest version. Thus changing this will break compatibility. > Specifically, the way the size was validated for this op code > incorrectly expects an extra queue pair structure. Some other > structures have similar length calculation flaws. We agree that fixing > this is important, but the fix needs to account that old drivers will > send an off by 1 size. > > To properly handle compatibility we need to introduce a feature flag to > indicate the new behavior. If the feature flag is not set, we acccept > messages with the old format (with the extra size). If both the PF and > VF support the feature flag, we'll use the correct size calculations. > We're looking to add this and would like to do all the virtchnl > structure fixes in one series. > Oh OK, I see. In this case, I think something like this might work just fine: https://git.kernel.org/linus/c0a744dcaa29e9537e8607ae9c965ad936124a4d What do you think? Thanks -- Gustavo