From: Kees Cook <kees@kernel.org>
To: srinivas pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: Erick Archer <erick.archer@outlook.com>,
Jiri Kosina <jikos@kernel.org>,
Benjamin Tissoires <bentiss@kernel.org>,
Justin Stitt <justinstitt@google.com>,
"Gustavo A. R. Silva" <gustavoars@kernel.org>,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-hardening@vger.kernel.org
Subject: Re: [RFC] HID: ishtp-hid-client: replace fake-flex arrays with flex-array members
Date: Thu, 22 Aug 2024 20:44:36 -0700 [thread overview]
Message-ID: <202408222044.7EA51146E@keescook> (raw)
In-Reply-To: <4e68c0164022ca41494c6d577766dd4b66c93e9f.camel@linux.intel.com>
On Tue, Jun 11, 2024 at 11:26:25PM -0700, srinivas pandruvada wrote:
> On Sat, 2024-06-08 at 11:56 +0200, Erick Archer wrote:
> > Hi Srinivas,
> > First of all, thanks for looking at this ;)
> >
> > On Sat, Jun 08, 2024 at 01:42:54AM -0700, srinivas pandruvada wrote:
> > > On Sun, 2024-05-26 at 15:32 +0200, Erick Archer wrote:
> > > > One-element arrays as fake flex arrays are deprecated [1] and we
> > > > are
> > > > moving towards adopting C99 flexible-array members, instead. This
> > > > case
> > > > also has more complexity because it is a flexible array of
> > > > flexible
> > > > arrays and this patch needs to be ready to enable the new
> > > > compiler
> > > > flag
> > > > -Wflex-array-member-not-at-end (coming in GCC-14) globally.
> > > >
> > > > So, define a new struct type for the single reports:
> > > >
> > > > struct report {
> > > > uint16_t size;
> > > > struct hostif_msg_hdr msg;
> > > > } __packed;
> > > >
> > > > but without the payload (flex array) in it. And add this payload
> > > > to
> > > > the
> > > > "hostif_msg" structure. This way, in the "report_list" structure
> > > > we
> > > > can
> > > > declare a flex array of single reports which now do not contain
> > > > another
> > > > flex array.
> > > >
> > > > struct report_list {
> > > > [...]
> > > > struct report reports[];
> > > > } __packed;
> > > >
> > > > Also, use "container_of()" whenever we need to retrieve a pointer
> > > > to
> > > > the flexible structure, through which we can access the flexible
> > > > array
> > > > if needed.
> > > >
> > > > Moreover, refactor the code accordingly to use the new structures
> > > > and
> > > > take advantage of this avoiding some pointer arithmetic and using
> > > > the
> > > > "struct_size" helper when possible.
> > > >
> > > > This way, the code is more readable and safer.
> > >
> > > Applied and tested, atleast didn't break anything.
> > >
> > > But the explanation above didn't give me enough clue. You have
> > > added a
> > > payload[] in the struct hostif_msg {} then using that as a message
> > > pointer following the header. I think this description needs to be
> > > better.
> >
> > Yeah, I will try to improve the commit message. What do you think
> > about
> > the following parragrafs?
> >
> > [I have copied part of the message to show where the new info will
> > be]
> > > > declare a flex array of single reports which now do not contain
> > > > another flex array.
> > > >
> > > > struct report_list {
> > > > [...]
> > > > struct report reports[];
> > > > } __packed;
> >
> > Therefore, the "struct hostif_msg" is now made up of a header and a
> > payload. And the "struct report" uses only the "hostif_msg" header.
> > The perfect solution would be for the "report" structure to use the
> > whole "hostif_msg" structure but this is not possible due to nested
> > flexible arrays. Anyway, the end result is equivalent since this
> > patch
> > does attemp to change the behaviour of the code.
> >
> > Now as well, we have more clarity after the cast from the raw bytes
> > to
> > the new structures.
> >
> > > >
> > > > Also, use "container_of()" whenever we need to retrieve a pointer
> > > > to
> > > > the flexible structure, through which we can access the flexible
> > > > array
> > > > if needed.
> >
> > I would like to know if it is enough :)
>
> The apporoach is fine. But I don't like clubbing other changes like
> struct_size(). That make code difficult to follow.
Erick, can you respin this patch without the struct_size() change? I
think it looks like it could land otherwise.
-Kees
>
> Thanks,
> Srinivas
>
>
>
> >
> > Regards,
> > Erick
> > >
> > > Thanks,
> > > Srinivas
>
--
Kees Cook
prev parent reply other threads:[~2024-08-23 3:44 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-26 13:32 [RFC] HID: ishtp-hid-client: replace fake-flex arrays with flex-array members Erick Archer
2024-06-08 8:42 ` srinivas pandruvada
2024-06-08 9:56 ` Erick Archer
2024-06-12 6:26 ` srinivas pandruvada
2024-08-23 3:44 ` Kees Cook [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202408222044.7EA51146E@keescook \
--to=kees@kernel.org \
--cc=bentiss@kernel.org \
--cc=erick.archer@outlook.com \
--cc=gustavoars@kernel.org \
--cc=jikos@kernel.org \
--cc=justinstitt@google.com \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=srinivas.pandruvada@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).