From: Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@gmail.com>
To: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Cc: amd-gfx@lists.freedesktop.org,
paulo.miguel.almeida.rodenas@gmail.com,
dri-devel@lists.freedesktop.org, linux-hardening@vger.kernel.org,
"Alex Deucher" <alexdeucher@gmail.com>,
"Christian König" <christian.koenig@amd.com>
Subject: Re: [RFC] Approaches to deal with a struct with multiple fake flexible arrays members
Date: Thu, 10 Nov 2022 14:31:31 +1300 [thread overview]
Message-ID: <Y2xUc9Q/+zTYbjaL@mail.google.com> (raw)
In-Reply-To: <Y2xJxUnDnesWYckj@work>
On Wed, Nov 09, 2022 at 06:45:57PM -0600, Gustavo A. R. Silva wrote:
> On Wed, Nov 09, 2022 at 04:45:42PM +1300, Paulo Miguel Almeida wrote:
>
> Adding Alex, Christian and DRM lists to the thread.
Thanks so much for your reply Gustavo
Yep, that's a good idea.
>
> > struct _ATOM_INIT_REG_BLOCK {
> > USHORT usRegIndexTblSize; /* 0 2 */
> > USHORT usRegDataBlkSize; /* 2 2 */
> > ATOM_INIT_REG_INDEX_FORMAT asRegIndexBuf[1]; /* 4 3 */
> > ATOM_MEMORY_SETTING_DATA_BLOCK asRegDataBuf[1]; /* 7 8 */
>
> I didn't find evidence that asRegDataBuf is used anywhere in the
> codebase[1].
> ...
> <snip>
> ...
> As I pointed out above, I don't see asRegDataBuf[] being used in the
> codebase (of course it may describe firmware memory layout). Instead,
> there is this jump to a block of data past asRegIndexBuf[]:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1444:
> 1444: ATOM_MEMORY_SETTING_DATA_BLOCK *reg_data =
> 1445: (ATOM_MEMORY_SETTING_DATA_BLOCK *)
> 1446: ((u8 *)reg_block + (2 * sizeof(u16)) +
> 1447: le16_to_cpu(reg_block->usRegIndexTblSize));
>
> So, it seems the one relevant array, from the kernel side, is
> asRegIndexBuf[]. I wonder if we really need asRegDataBuf[] in that
> structure... or if we could try modifying that struct and only have
> asRegIndexBuf[] as last member? and then we can transform it into a
> flex-array member.
I saw that one too. That would be the way it's currently accessing
asRegDataBuf member as the existing struct would make asRegDataBuf[0] point
to some index within the asRegIndexBuf member (as you probably got it too)
you are right... asRegDataBuff isn't used from a static analysis
point of view but removing it make the code a bit cryptic, right?
That's pickle, ay? :-)
>
> If for any strong reasong we cannot remove asRegDataBuf[] then I think we
> could give it a try and use DECLARE_FLEX_ARRAY() to declare both arrays
> in the structure.
>
Out of curiosity, why both rather than just asRegIndexBuf?
> But first, of course, Alex, Christian, it'd be really great if we can
> have your input and feedback. :)
>
> Thanks!
> --
> Gustavo
>
- Paulo A.
WARNING: multiple messages have this Message-ID (diff)
From: Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@gmail.com>
To: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Cc: linux-hardening@vger.kernel.org,
"Christian König" <christian.koenig@amd.com>,
"Alex Deucher" <alexdeucher@gmail.com>,
amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
paulo.miguel.almeida.rodenas@gmail.com
Subject: Re: [RFC] Approaches to deal with a struct with multiple fake flexible arrays members
Date: Thu, 10 Nov 2022 14:31:31 +1300 [thread overview]
Message-ID: <Y2xUc9Q/+zTYbjaL@mail.google.com> (raw)
In-Reply-To: <Y2xJxUnDnesWYckj@work>
On Wed, Nov 09, 2022 at 06:45:57PM -0600, Gustavo A. R. Silva wrote:
> On Wed, Nov 09, 2022 at 04:45:42PM +1300, Paulo Miguel Almeida wrote:
>
> Adding Alex, Christian and DRM lists to the thread.
Thanks so much for your reply Gustavo
Yep, that's a good idea.
>
> > struct _ATOM_INIT_REG_BLOCK {
> > USHORT usRegIndexTblSize; /* 0 2 */
> > USHORT usRegDataBlkSize; /* 2 2 */
> > ATOM_INIT_REG_INDEX_FORMAT asRegIndexBuf[1]; /* 4 3 */
> > ATOM_MEMORY_SETTING_DATA_BLOCK asRegDataBuf[1]; /* 7 8 */
>
> I didn't find evidence that asRegDataBuf is used anywhere in the
> codebase[1].
> ...
> <snip>
> ...
> As I pointed out above, I don't see asRegDataBuf[] being used in the
> codebase (of course it may describe firmware memory layout). Instead,
> there is this jump to a block of data past asRegIndexBuf[]:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1444:
> 1444: ATOM_MEMORY_SETTING_DATA_BLOCK *reg_data =
> 1445: (ATOM_MEMORY_SETTING_DATA_BLOCK *)
> 1446: ((u8 *)reg_block + (2 * sizeof(u16)) +
> 1447: le16_to_cpu(reg_block->usRegIndexTblSize));
>
> So, it seems the one relevant array, from the kernel side, is
> asRegIndexBuf[]. I wonder if we really need asRegDataBuf[] in that
> structure... or if we could try modifying that struct and only have
> asRegIndexBuf[] as last member? and then we can transform it into a
> flex-array member.
I saw that one too. That would be the way it's currently accessing
asRegDataBuf member as the existing struct would make asRegDataBuf[0] point
to some index within the asRegIndexBuf member (as you probably got it too)
you are right... asRegDataBuff isn't used from a static analysis
point of view but removing it make the code a bit cryptic, right?
That's pickle, ay? :-)
>
> If for any strong reasong we cannot remove asRegDataBuf[] then I think we
> could give it a try and use DECLARE_FLEX_ARRAY() to declare both arrays
> in the structure.
>
Out of curiosity, why both rather than just asRegIndexBuf?
> But first, of course, Alex, Christian, it'd be really great if we can
> have your input and feedback. :)
>
> Thanks!
> --
> Gustavo
>
- Paulo A.
WARNING: multiple messages have this Message-ID (diff)
From: Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@gmail.com>
To: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Cc: amd-gfx@lists.freedesktop.org,
paulo.miguel.almeida.rodenas@gmail.com,
dri-devel@lists.freedesktop.org, linux-hardening@vger.kernel.org,
"Christian König" <christian.koenig@amd.com>
Subject: Re: [RFC] Approaches to deal with a struct with multiple fake flexible arrays members
Date: Thu, 10 Nov 2022 14:31:31 +1300 [thread overview]
Message-ID: <Y2xUc9Q/+zTYbjaL@mail.google.com> (raw)
In-Reply-To: <Y2xJxUnDnesWYckj@work>
On Wed, Nov 09, 2022 at 06:45:57PM -0600, Gustavo A. R. Silva wrote:
> On Wed, Nov 09, 2022 at 04:45:42PM +1300, Paulo Miguel Almeida wrote:
>
> Adding Alex, Christian and DRM lists to the thread.
Thanks so much for your reply Gustavo
Yep, that's a good idea.
>
> > struct _ATOM_INIT_REG_BLOCK {
> > USHORT usRegIndexTblSize; /* 0 2 */
> > USHORT usRegDataBlkSize; /* 2 2 */
> > ATOM_INIT_REG_INDEX_FORMAT asRegIndexBuf[1]; /* 4 3 */
> > ATOM_MEMORY_SETTING_DATA_BLOCK asRegDataBuf[1]; /* 7 8 */
>
> I didn't find evidence that asRegDataBuf is used anywhere in the
> codebase[1].
> ...
> <snip>
> ...
> As I pointed out above, I don't see asRegDataBuf[] being used in the
> codebase (of course it may describe firmware memory layout). Instead,
> there is this jump to a block of data past asRegIndexBuf[]:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1444:
> 1444: ATOM_MEMORY_SETTING_DATA_BLOCK *reg_data =
> 1445: (ATOM_MEMORY_SETTING_DATA_BLOCK *)
> 1446: ((u8 *)reg_block + (2 * sizeof(u16)) +
> 1447: le16_to_cpu(reg_block->usRegIndexTblSize));
>
> So, it seems the one relevant array, from the kernel side, is
> asRegIndexBuf[]. I wonder if we really need asRegDataBuf[] in that
> structure... or if we could try modifying that struct and only have
> asRegIndexBuf[] as last member? and then we can transform it into a
> flex-array member.
I saw that one too. That would be the way it's currently accessing
asRegDataBuf member as the existing struct would make asRegDataBuf[0] point
to some index within the asRegIndexBuf member (as you probably got it too)
you are right... asRegDataBuff isn't used from a static analysis
point of view but removing it make the code a bit cryptic, right?
That's pickle, ay? :-)
>
> If for any strong reasong we cannot remove asRegDataBuf[] then I think we
> could give it a try and use DECLARE_FLEX_ARRAY() to declare both arrays
> in the structure.
>
Out of curiosity, why both rather than just asRegIndexBuf?
> But first, of course, Alex, Christian, it'd be really great if we can
> have your input and feedback. :)
>
> Thanks!
> --
> Gustavo
>
- Paulo A.
next prev parent reply other threads:[~2022-11-10 2:13 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-09 3:45 [RFC] Approaches to deal with a struct with multiple fake flexible arrays members Paulo Miguel Almeida
2022-11-10 0:45 ` Gustavo A. R. Silva
2022-11-10 0:45 ` Gustavo A. R. Silva
2022-11-10 0:45 ` Gustavo A. R. Silva
2022-11-10 1:31 ` Paulo Miguel Almeida [this message]
2022-11-10 1:31 ` Paulo Miguel Almeida
2022-11-10 1:31 ` Paulo Miguel Almeida
2022-11-10 3:20 ` Alex Deucher
2022-11-10 3:20 ` Alex Deucher
2022-11-11 5:39 ` Gustavo A. R. Silva
2022-11-11 5:39 ` Gustavo A. R. Silva
2022-11-11 6:05 ` Paulo Miguel Almeida
2022-11-11 6:05 ` Paulo Miguel Almeida
2022-11-11 6:05 ` Paulo Miguel Almeida
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=Y2xUc9Q/+zTYbjaL@mail.google.com \
--to=paulo.miguel.almeida.rodenas@gmail.com \
--cc=alexdeucher@gmail.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gustavoars@kernel.org \
--cc=linux-hardening@vger.kernel.org \
/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.