linux-hardening - Re: [PATCH][next] PCI: hv: Avoid multiple -Wflex-array-member-not-at-end warnings

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aCN3E7pQc5UHJ-4w@liuwe-devbox-ubuntu-v2.tail21d00.ts.net>
Date: Tue, 13 May 2025 16:45:07 +0000
From: Wei Liu <wei.liu@...nel.org>
To: Michael Kelley <mhklinux@...look.com>
Cc: "Gustavo A. R. Silva" <gustavoars@...nel.org>,
	"K. Y. Srinivasan" <kys@...rosoft.com>,
	Haiyang Zhang <haiyangz@...rosoft.com>,
	Wei Liu <wei.liu@...nel.org>, Dexuan Cui <decui@...rosoft.com>,
	Lorenzo Pieralisi <lpieralisi@...nel.org>,
	Krzysztof Wilczyński <kw@...ux.com>,
	Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>,
	Rob Herring <robh@...nel.org>, Bjorn Helgaas <bhelgaas@...gle.com>,
	"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-hardening@...r.kernel.org" <linux-hardening@...r.kernel.org>
Subject: Re: [PATCH][next] PCI: hv: Avoid multiple
 -Wflex-array-member-not-at-end warnings

On Tue, May 13, 2025 at 02:07:45AM +0000, Michael Kelley wrote:
> From: Michael Kelley <mhklinux@...look.com> Sent: Sunday, April 27, 2025 8:22 AM
> > 
> > From: Gustavo A. R. Silva <gustavoars@...nel.org> Sent: Friday, April 25, 2025 9:48
> > AM
> > >
> > > -Wflex-array-member-not-at-end was introduced in GCC-14, and we are
> > > getting ready to enable it, globally.
> > >
> > > Use the `DEFINE_RAW_FLEX()` helper for a few on-stack definitions
> > > of a flexible structure where the size of the flexible-array member
> > > is known at compile-time, and refactor the rest of the code,
> > > accordingly.
> > >
> > > So, with these changes, fix the following warnings:
> > >
> > > drivers/pci/controller/pci-hyperv.c:3809:35: warning: structure containing a flexible
> > > array member is not at the end of another structure [-Wflex-array-member-not-at-end]
> > > drivers/pci/controller/pci-hyperv.c:2831:35: warning: structure containing a flexible
> > > array member is not at the end of another structure [-Wflex-array-member-not-at-end]
> > > drivers/pci/controller/pci-hyperv.c:2468:35: warning: structure containing a flexible
> > > array member is not at the end of another structure [-Wflex-array-member-not-at-end]
> > > drivers/pci/controller/pci-hyperv.c:1830:35: warning: structure containing a flexible
> > > array member is not at the end of another structure [-Wflex-array-member-not-at-end]
> > > drivers/pci/controller/pci-hyperv.c:1593:35: warning: structure containing a flexible
> > > array member is not at the end of another structure [-Wflex-array-member-not-at-end]
> > > drivers/pci/controller/pci-hyperv.c:1504:35: warning: structure containing a flexible
> > > array member is not at the end of another structure [-Wflex-array-member-not-at-end]
> > > drivers/pci/controller/pci-hyperv.c:1424:35: warning: structure containing a flexible
> > > array member is not at the end of another structure [-Wflex-array-member-not-at-end]
> > 
> > I'm supportive of cleaning up these warnings. I've worked with the pci-hyperv.c
> > code a fair amount over the years, but never had looked closely at the on-stack
> > structs that are causing the warnings. The current code is a bit unusual and
> > perhaps unnecessarily obtuse.
> > 
> > Rather than the approach you've taken below, I tried removing the flex array
> > entirely from struct pci_packet. In all cases except one, it was used only to
> > locate the end of struct pci_packet, which is the beginning of the follow-on
> > message. Locating that follow-on message can easily be done by just referencing
> > the "buf" field in the on-stack structs, or as (pkt + 1) in the dynamically allocated
> > case. In both cases, there's no need for the flex array. In the one exception, a
> > couple of minor tweaks avoids the need for the flex array as well.
> > 
> > So here's an alternate approach to solving the problem. This approach is
> > 14 insertions and 15 deletions, so it's a lot less change than your approach.
> > I still don't understand why the on-stack struct are declared as (for example):
> > 
> > 	struct {
> > 		struct pci_packet pkt;
> > 		char buf[sizeof(struct pci_read_block)];
> > 	} pkt;
> > 
> > instead of just:
> > 
> > 	struct {
> > 		struct pci_packet pkt;
> > 		struct pci_read_block msg;
> > 	} pkt;
> > 
> > but that's a topic for another time.  Anyway, here's my proposed diff, which I've
> > compiled and smoke-tested in a VM in the Azure cloud:
> > 
> 
> Gustavo -- Are you waiting for me to submit a patch with my alternate proposal?
> I had not seen any follow up, so wanted to make sure we have clarity on who
> has the next action. Thx.

Michael, I prefer your approach. Please send a patch.

Thanks,
Wei.

> 
> Michael