From: "Gustavo A. R. Silva" <gustavoars@kernel.org>
To: Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@gmail.com>
Cc: "Alex Deucher" <alexdeucher@gmail.com>,
dri-devel@lists.freedesktop.org, linux-hardening@vger.kernel.org,
amd-gfx@lists.freedesktop.org,
"Christian König" <christian.koenig@amd.com>
Subject: Re: [RFC] Approaches to deal with a struct with multiple fake flexible arrays members
Date: Wed, 9 Nov 2022 18:45:57 -0600 [thread overview]
Message-ID: <Y2xJxUnDnesWYckj@work> (raw)
In-Reply-To: <Y2siZmiTD40mTYpJ@mail.google.com>
On Wed, Nov 09, 2022 at 04:45:42PM +1300, Paulo Miguel Almeida wrote:
Adding Alex, Christian and DRM lists to the thread.
> Hi KSPP community,
>
> I've been working on replacing 1-element arrays with flex array members
> on the drm/amdgpu files. I came across one insteresting case which I
> may need to pick your brains to find a solution for it.
>
> The structure below has two fake flexible arrays but I would get an
> error if I try make them both FAM. How should/could I deal with the
> asRegIndexBuf in this case? In theory, DECLARE_FLEX_ARRAY would "work"
> but that doesn't seem to be its intended usage as far I've searched.
> (unless I got it wrong, if that's the case, feel free to set me straight)
>
> Any ideas?
>
> 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].
>
> /* size: 15, cachelines: 1, members: 4 */
> /* last cacheline: 15 bytes */
> } __attribute__((__packed__));
Alex, Christian,
It looks like this structure is only being used as a template to populate
instances of struct atom_mc_reg_table[2] and that these[3] are the only
places where asRegIndexBuf[] is being used. Apparently, this array is only
being used to retrieve it's address so that a pointer can jump[4] in chucks
of size sizeof(ATOM_INIT_REG_INDEX_FORMAT):
drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1461:
1461: format = (ATOM_INIT_REG_INDEX_FORMAT *)
1462: ((u8 *)format + sizeof(ATOM_INIT_REG_INDEX_FORMAT));
up to (VBIOS_MC_REGISTER_ARRAY_SIZE * sizeof(ATOM_INIT_REG_INDEX_FORMAT))[5],
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.
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.
But first, of course, Alex, Christian, it'd be really great if we can
have your input and feedback. :)
Thanks!
--
Gustavo
[1] https://elixir.bootlin.com/linux/latest/C/ident/asRegDataBuf
[2] https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c#L1441
[3] https://elixir.bootlin.com/linux/latest/C/ident/asRegIndexBuf
WARNING: multiple messages have this Message-ID (diff)
From: "Gustavo A. R. Silva" <gustavoars@kernel.org>
To: Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@gmail.com>
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
Subject: Re: [RFC] Approaches to deal with a struct with multiple fake flexible arrays members
Date: Wed, 9 Nov 2022 18:45:57 -0600 [thread overview]
Message-ID: <Y2xJxUnDnesWYckj@work> (raw)
In-Reply-To: <Y2siZmiTD40mTYpJ@mail.google.com>
On Wed, Nov 09, 2022 at 04:45:42PM +1300, Paulo Miguel Almeida wrote:
Adding Alex, Christian and DRM lists to the thread.
> Hi KSPP community,
>
> I've been working on replacing 1-element arrays with flex array members
> on the drm/amdgpu files. I came across one insteresting case which I
> may need to pick your brains to find a solution for it.
>
> The structure below has two fake flexible arrays but I would get an
> error if I try make them both FAM. How should/could I deal with the
> asRegIndexBuf in this case? In theory, DECLARE_FLEX_ARRAY would "work"
> but that doesn't seem to be its intended usage as far I've searched.
> (unless I got it wrong, if that's the case, feel free to set me straight)
>
> Any ideas?
>
> 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].
>
> /* size: 15, cachelines: 1, members: 4 */
> /* last cacheline: 15 bytes */
> } __attribute__((__packed__));
Alex, Christian,
It looks like this structure is only being used as a template to populate
instances of struct atom_mc_reg_table[2] and that these[3] are the only
places where asRegIndexBuf[] is being used. Apparently, this array is only
being used to retrieve it's address so that a pointer can jump[4] in chucks
of size sizeof(ATOM_INIT_REG_INDEX_FORMAT):
drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1461:
1461: format = (ATOM_INIT_REG_INDEX_FORMAT *)
1462: ((u8 *)format + sizeof(ATOM_INIT_REG_INDEX_FORMAT));
up to (VBIOS_MC_REGISTER_ARRAY_SIZE * sizeof(ATOM_INIT_REG_INDEX_FORMAT))[5],
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.
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.
But first, of course, Alex, Christian, it'd be really great if we can
have your input and feedback. :)
Thanks!
--
Gustavo
[1] https://elixir.bootlin.com/linux/latest/C/ident/asRegDataBuf
[2] https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c#L1441
[3] https://elixir.bootlin.com/linux/latest/C/ident/asRegIndexBuf
WARNING: multiple messages have this Message-ID (diff)
From: "Gustavo A. R. Silva" <gustavoars@kernel.org>
To: Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@gmail.com>
Cc: dri-devel@lists.freedesktop.org, linux-hardening@vger.kernel.org,
amd-gfx@lists.freedesktop.org,
"Christian König" <christian.koenig@amd.com>
Subject: Re: [RFC] Approaches to deal with a struct with multiple fake flexible arrays members
Date: Wed, 9 Nov 2022 18:45:57 -0600 [thread overview]
Message-ID: <Y2xJxUnDnesWYckj@work> (raw)
In-Reply-To: <Y2siZmiTD40mTYpJ@mail.google.com>
On Wed, Nov 09, 2022 at 04:45:42PM +1300, Paulo Miguel Almeida wrote:
Adding Alex, Christian and DRM lists to the thread.
> Hi KSPP community,
>
> I've been working on replacing 1-element arrays with flex array members
> on the drm/amdgpu files. I came across one insteresting case which I
> may need to pick your brains to find a solution for it.
>
> The structure below has two fake flexible arrays but I would get an
> error if I try make them both FAM. How should/could I deal with the
> asRegIndexBuf in this case? In theory, DECLARE_FLEX_ARRAY would "work"
> but that doesn't seem to be its intended usage as far I've searched.
> (unless I got it wrong, if that's the case, feel free to set me straight)
>
> Any ideas?
>
> 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].
>
> /* size: 15, cachelines: 1, members: 4 */
> /* last cacheline: 15 bytes */
> } __attribute__((__packed__));
Alex, Christian,
It looks like this structure is only being used as a template to populate
instances of struct atom_mc_reg_table[2] and that these[3] are the only
places where asRegIndexBuf[] is being used. Apparently, this array is only
being used to retrieve it's address so that a pointer can jump[4] in chucks
of size sizeof(ATOM_INIT_REG_INDEX_FORMAT):
drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c:1461:
1461: format = (ATOM_INIT_REG_INDEX_FORMAT *)
1462: ((u8 *)format + sizeof(ATOM_INIT_REG_INDEX_FORMAT));
up to (VBIOS_MC_REGISTER_ARRAY_SIZE * sizeof(ATOM_INIT_REG_INDEX_FORMAT))[5],
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.
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.
But first, of course, Alex, Christian, it'd be really great if we can
have your input and feedback. :)
Thanks!
--
Gustavo
[1] https://elixir.bootlin.com/linux/latest/C/ident/asRegDataBuf
[2] https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c#L1441
[3] https://elixir.bootlin.com/linux/latest/C/ident/asRegIndexBuf
next prev parent reply other threads:[~2022-11-10 0:46 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 [this message]
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
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=Y2xJxUnDnesWYckj@work \
--to=gustavoars@kernel.org \
--cc=alexdeucher@gmail.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=christian.koenig@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-hardening@vger.kernel.org \
--cc=paulo.miguel.almeida.rodenas@gmail.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.