Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp3141480ybc; Thu, 21 Nov 2019 04:03:18 -0800 (PST) X-Google-Smtp-Source: APXvYqy/4qSs1fhhM0lhpPoPCjTj/fwtPaKbD/2DaLgf6dG+PeqH/60n0yBKjKSGSBJjCzNAdk84 X-Received: by 2002:a1c:9e10:: with SMTP id h16mr9373054wme.91.1574337798242; Thu, 21 Nov 2019 04:03:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574337798; cv=none; d=google.com; s=arc-20160816; b=SvmKYK5ElhzQaZv/TXMWDW421BsMDbs0UWk8DfLvt2oKaskRAUWijXYPWP1gvbqqV1 VStSCC3W0BFic7lD+tJ1pMRMPB5l1QsYPD4MeGIXNfy90OhyiUJ109JTxOlgne5vIQXp jGFbtu/aFpibuNoOUU+SE/jx3uoc0aCzWZffuRG+PhfxCvO6tsrr+R7iHS7pd2j4Ewt/ TkgmMYAbq1HlMiwpwSi8HKzfMK/5pb0FtuKiU4w8AEwp47fgR/IS9nJXmdi3UjO5iAO/ Ddiec/TPfBtTczKq++JHRJLj8rEgcPDrM1LvHTadao0S3RmrY27WyOZAUT/krpfxcORP E/MQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=VUUenEDSyf7E6Q6d36xzi2nRnssyMVHGsfvd2D5saDs=; b=MmO+2BptqKRLbkO06YSVegYkG65Nk+ND2DlDvBfdN8p+zHw/5Au1ceC6zctZftuH0C dXdcmhic+evXzJFYao8rJ+lO9CMycYKNMmOzXGc7YKwYZqxwV3DmSeu/1tdhzBcFe4Ur yqC1biq3zHatjzplrENvPwWSXOW+qVYJiDdqINK29yEArURCajVt4xEaCvqNl2E7zRTP Z458Ui6oR6PJI//b6wR4HRDz3awa9ka4KJkE0v4Op2ZQwzQI+zv+Dn7pmechVUcocz24 US9ZgwroHCRJALXmVAsn9Y/vKOSGB7juIeUoO/5IPVEwLjalYKjZfpCqwIB9SLTfSwfc WxnQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g54si1843941eda.101.2019.11.21.04.02.50; Thu, 21 Nov 2019 04:03:18 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726613AbfKUL6X (ORCPT + 99 others); Thu, 21 Nov 2019 06:58:23 -0500 Received: from mail3-relais-sop.national.inria.fr ([192.134.164.104]:21309 "EHLO mail3-relais-sop.national.inria.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726197AbfKUL6W (ORCPT ); Thu, 21 Nov 2019 06:58:22 -0500 X-IronPort-AV: E=Sophos;i="5.69,224,1571695200"; d="scan'208";a="327507864" Received: from portablejulia.rsr.lip6.fr ([132.227.76.63]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Nov 2019 12:58:18 +0100 Date: Thu, 21 Nov 2019 12:58:18 +0100 (CET) From: Julia Lawall X-X-Sender: julia@hadrien To: Michal Kubecek cc: "Enrico Weigelt, metux IT consult" , jakub.kicinski@netronome.com, ast@kernel.org, natechancellor@gmail.com, jiang.xuexin@zte.com.cn, cocci , f.fainelli@gmail.com, daniel@iogearbox.net, john.fastabend@gmail.com, lirongqing@baidu.com, maxime.chevallier@bootlin.com, vivien.didelot@gmail.com, dan.carpenter@oracle.com, wang.yi59@zte.com.cn, hawk@kernel.org, arnd@arndb.de, jiri@mellanox.com, xue.zhihong@zte.com.cn, zhanglin , Thomas Gleixner , bpf@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linyunsheng@huawei.com, pablo@netfilter.org, Joe Perches , Andrew Morton , Linus Torvalds , davem@davemloft.net Subject: Re: [Cocci] [PATCH] net: Zeroing the structure ethtool_wolinfo in ethtool_get_wol() In-Reply-To: <20191121111917.GE29650@unicorn.suse.cz> Message-ID: References: <1572076456-12463-1-git-send-email-zhang.lin16@zte.com.cn> <20191121111917.GE29650@unicorn.suse.cz> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 21 Nov 2019, Michal Kubecek wrote: > On Thu, Nov 21, 2019 at 11:23:34AM +0100, Enrico Weigelt, metux IT consult wrote: > > On 26.10.19 21:40, Joe Perches wrote: > > > On Sat, 2019-10-26 at 15:54 +0800, zhanglin wrote: > > >> memset() the structure ethtool_wolinfo that has padded bytes > > >> but the padded bytes have not been zeroed out. > > > [] > > >> diff --git a/net/core/ethtool.c b/net/core/ethtool.c > > > [] > > >> @@ -1471,11 +1471,13 @@ static int ethtool_reset(struct net_device *dev, char __user *useraddr) > > >> > > >> static int ethtool_get_wol(struct net_device *dev, char __user *useraddr) > > >> { > > >> - struct ethtool_wolinfo wol = { .cmd = ETHTOOL_GWOL }; > > >> + struct ethtool_wolinfo wol; > > >> > > >> if (!dev->ethtool_ops->get_wol) > > >> return -EOPNOTSUPP; > > >> > > >> + memset(&wol, 0, sizeof(struct ethtool_wolinfo)); > > >> + wol.cmd = ETHTOOL_GWOL; > > >> dev->ethtool_ops->get_wol(dev, &wol); > > >> > > >> if (copy_to_user(useraddr, &wol, sizeof(wol))) > > > > > > It seems likely there are more of these. > > > > > > Is there any way for coccinelle to find them? > > > > Just curios: is static struct initialization (on stack) something that > > should be avoided ? I've been under the impression that static > > initialization allows thinner code and gives the compiler better chance > > for optimizations. > > Not in general. The (potential) problem here is that the structure has > padding and it is as a whole (i.e. including the padding) copied to > userspace. While I'm not aware of a compiler that wouldn't actually > initialize the whole data block including the padding in this case, the > C standard provides no guarantee about that so that to be sure we cannot > leak leftover kernel data to userspace, we need to explicitly initialize > the whole block. I'm not sure that it is likely that the compiler will do anything other than ensure that all the fields are initialized. Among the files that I could compile, the only case with actual padding and no memset, memcpy, copy_from_user or structure assignment that I could find was drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c There is the code struct drm_amdgpu_info_device dev_info = {}; but I couldn't see any thing in the assembly language that seemed to zero the structure. gcc probably thought its job was done because all fields are subsequently initialized. But the size of the structure does not seem to be the same as the sum of the size of the fields. The set of fields was collected with Coccinelle, which could be unreliable for this task. julia > > If the structure is not going to be copied to userspace (or otherwise > exposed), using the initializer is fully sufficient and looks cleaner. > > Michal Kubecek > _______________________________________________ > Cocci mailing list > Cocci@systeme.lip6.fr > https://systeme.lip6.fr/mailman/listinfo/cocci >