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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.