linux-kernel - Re: [PATCH 2/6] scsi: mpt3sas: Use flexible arrays when less obviously possible

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 for Android: free password hash cracker in your pocket

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

Message-ID: <ZMTJHZLu7szzsx1s@equiv.tech>
Date:   Sat, 29 Jul 2023 01:09:01 -0700
From:   James Seo <james@...iv.tech>
To:     Kees Cook <keescook@...omium.org>
Cc:     Sathya Prakash <sathya.prakash@...adcom.com>,
        Sreekanth Reddy <sreekanth.reddy@...adcom.com>,
        Suganath Prabu Subramani 
        <suganath-prabu.subramani@...adcom.com>,
        "James E.J. Bottomley" <jejb@...ux.ibm.com>,
        "Martin K. Petersen" <martin.petersen@...cle.com>,
        "Gustavo A. R. Silva" <gustavoars@...nel.org>,
        MPT-FusionLinux.pdl@...adcom.com, linux-scsi@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/6] scsi: mpt3sas: Use flexible arrays when less
 obviously possible

Hi, thanks for reviewing.

On Fri, Jul 28, 2023 at 03:26:57PM -0700, Kees Cook wrote:
> Doing build comparisons here, I see a lot of binary changes. They may
> be, as you say, harmless, and since you've actually got hardware then
> this is a good verification of the changes, but I do wonder if this
> needs more detailed commit log (or split up patches).
> 
> However, the problem I see is that this code was already doing weird
> stuff with structs that appear to not have been using flex arrays
> actually. With "pahole" I can see struct MPT3SAS_ADAPTER changes:
> 
> -       Mpi2IOUnitPage8_t          iounit_pg8;           /*  3668    40 */
> -       Mpi2IOCPage1_t             ioc_pg1_copy;         /*  3708    24 */
> +       Mpi2IOUnitPage8_t          iounit_pg8;           /*  3668    16 */
> +       Mpi2IOCPage1_t             ioc_pg1_copy;         /*  3684    24 */
> 
> struct _MPI2_CONFIG_PAGE_IO_UNIT_8 (Mpi2IOUnitPage8_t) is in the
> _middle_ of struct MPT3SAS_ADAPTER.... :|

In this particular case, the flex array member of iounit_pg8 is never
used, and iounit_pg8 itself is never used outside of the function
that fetches and sets it on the per-adapter struct MPT3SAS_ADAPTER.

iounit_pg8 could probably be removed, now that I think about it.
Maybe I will.

> In the earlier attempts at this conversion, it seemed that some of these
> are actually fixed-size:
> 
> https://lore.kernel.org/lkml/20210202235118.GA314410@embeddedor/

Yes, I tried to leave such terminal arrays alone. But I'll revisit
each change in this commit.

> I think this patch needs to be broken up into per-struct changes, so
> they can be reviewed individually.

Sure, I can do that. I'll resubmit this commit and the one following
(which depends on this commit) as a new series with more details.
Hopefully this will encourage the Broadcom folks who know this driver
best to chime in as well.

By the way, I noticed you've done something like this in the past to
preserve struct size for userspace, just in case:

	/* MPI2_IOUNIT8_SENSOR		Sensor[1]; */
	union {
		MPI2_IOUNIT8_SENSOR	_LegacyPadding;
		__DECLARE_FLEX_ARRAY(MPI2_IOUNIT8_SENSOR, Sensor);
	};

I don't think userspace is a concern for us here, but would you be
more comfortable if I did this too/instead?

James