* [PATCH] [next] drm/amdgpu: Replace one-element array with flexible-array member @ 2022-10-28 5:10 Paulo Miguel Almeida 2022-10-28 7:18 ` Christian König 0 siblings, 1 reply; 16+ messages in thread From: Paulo Miguel Almeida @ 2022-10-28 5:10 UTC (permalink / raw) To: Alex Deucher, Christian König, Pan, Xinhui, David Airlie, Daniel Vetter, Hans de Goede, Grigory Vasilyev, Paulo Miguel Almeida, Claudio Suarez, Slark Xiao, Rongguang Wei, amd-gfx, dri-devel Cc: linux-kernel, linux-hardening One-element arrays are deprecated, and we are replacing them with flexible array members instead. So, replace one-element array with flexible-array member in struct _ATOM_FAKE_EDID_PATCH_RECORD and refactor the rest of the code accordingly. This helps with the ongoing efforts to tighten the FORTIFY_SOURCE routines on memcpy() and help us make progress towards globally enabling -fstrict-flex-arrays=3 [1]. Link: https://github.com/KSPP/linux/issues/79 Link: https://github.com/KSPP/linux/issues/238 Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 [1] Signed-off-by: Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@gmail.com> --- drivers/gpu/drm/amd/amdgpu/atombios_encoders.c | 10 +++++++--- drivers/gpu/drm/amd/include/atombios.h | 2 +- 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c index 6be9ac2b9c5b..6b5abf1249db 100644 --- a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c +++ b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c @@ -2079,10 +2079,14 @@ amdgpu_atombios_encoder_get_lcd_info(struct amdgpu_encoder *encoder) } else kfree(edid); } + + record += struct_size(fake_edid_record, + ucFakeEDIDString, + fake_edid_record->ucFakeEDIDLength); + } else { + /* empty fake edid record must be 3 bytes long */ + record += sizeof(ATOM_FAKE_EDID_PATCH_RECORD) + 1; } - record += fake_edid_record->ucFakeEDIDLength ? - fake_edid_record->ucFakeEDIDLength + 2 : - sizeof(ATOM_FAKE_EDID_PATCH_RECORD); break; case LCD_PANEL_RESOLUTION_RECORD_TYPE: panel_res_record = (ATOM_PANEL_RESOLUTION_PATCH_RECORD *)record; diff --git a/drivers/gpu/drm/amd/include/atombios.h b/drivers/gpu/drm/amd/include/atombios.h index 15943bc21bc5..b5b1d073f8e2 100644 --- a/drivers/gpu/drm/amd/include/atombios.h +++ b/drivers/gpu/drm/amd/include/atombios.h @@ -4107,7 +4107,7 @@ typedef struct _ATOM_FAKE_EDID_PATCH_RECORD { UCHAR ucRecordType; UCHAR ucFakeEDIDLength; // = 128 means EDID length is 128 bytes, otherwise the EDID length = ucFakeEDIDLength*128 - UCHAR ucFakeEDIDString[1]; // This actually has ucFakeEdidLength elements. + UCHAR ucFakeEDIDString[]; // This actually has ucFakeEdidLength elements. } ATOM_FAKE_EDID_PATCH_RECORD; typedef struct _ATOM_PANEL_RESOLUTION_PATCH_RECORD -- 2.37.3 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [PATCH] [next] drm/amdgpu: Replace one-element array with flexible-array member 2022-10-28 5:10 [PATCH] [next] drm/amdgpu: Replace one-element array with flexible-array member Paulo Miguel Almeida @ 2022-10-28 7:18 ` Christian König 2022-10-28 16:36 ` Kees Cook 0 siblings, 1 reply; 16+ messages in thread From: Christian König @ 2022-10-28 7:18 UTC (permalink / raw) To: Paulo Miguel Almeida, Alex Deucher, Christian König, Pan, Xinhui, David Airlie, Daniel Vetter, Hans de Goede, Grigory Vasilyev, Claudio Suarez, Slark Xiao, Rongguang Wei, amd-gfx, dri-devel Cc: linux-kernel, linux-hardening Am 28.10.22 um 07:10 schrieb Paulo Miguel Almeida: > One-element arrays are deprecated, and we are replacing them with > flexible array members instead. So, replace one-element array with > flexible-array member in struct _ATOM_FAKE_EDID_PATCH_RECORD and > refactor the rest of the code accordingly. > > This helps with the ongoing efforts to tighten the FORTIFY_SOURCE > routines on memcpy() and help us make progress towards globally > enabling -fstrict-flex-arrays=3 [1]. > > Link: https://github.com/KSPP/linux/issues/79 > Link: https://github.com/KSPP/linux/issues/238 > Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 [1] I'm not sure if that's a good idea. We had multiple attempts to refactor this now and it always caused a regression. Additional to that the header in question came from our BIOS team and isn't following Linux styles in general. Alex what do you think? Regards, Christian. > > Signed-off-by: Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@gmail.com> > --- > drivers/gpu/drm/amd/amdgpu/atombios_encoders.c | 10 +++++++--- > drivers/gpu/drm/amd/include/atombios.h | 2 +- > 2 files changed, 8 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c > index 6be9ac2b9c5b..6b5abf1249db 100644 > --- a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c > +++ b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c > @@ -2079,10 +2079,14 @@ amdgpu_atombios_encoder_get_lcd_info(struct amdgpu_encoder *encoder) > } else > kfree(edid); > } > + > + record += struct_size(fake_edid_record, > + ucFakeEDIDString, > + fake_edid_record->ucFakeEDIDLength); > + } else { > + /* empty fake edid record must be 3 bytes long */ > + record += sizeof(ATOM_FAKE_EDID_PATCH_RECORD) + 1; > } > - record += fake_edid_record->ucFakeEDIDLength ? > - fake_edid_record->ucFakeEDIDLength + 2 : > - sizeof(ATOM_FAKE_EDID_PATCH_RECORD); > break; > case LCD_PANEL_RESOLUTION_RECORD_TYPE: > panel_res_record = (ATOM_PANEL_RESOLUTION_PATCH_RECORD *)record; > diff --git a/drivers/gpu/drm/amd/include/atombios.h b/drivers/gpu/drm/amd/include/atombios.h > index 15943bc21bc5..b5b1d073f8e2 100644 > --- a/drivers/gpu/drm/amd/include/atombios.h > +++ b/drivers/gpu/drm/amd/include/atombios.h > @@ -4107,7 +4107,7 @@ typedef struct _ATOM_FAKE_EDID_PATCH_RECORD > { > UCHAR ucRecordType; > UCHAR ucFakeEDIDLength; // = 128 means EDID length is 128 bytes, otherwise the EDID length = ucFakeEDIDLength*128 > - UCHAR ucFakeEDIDString[1]; // This actually has ucFakeEdidLength elements. > + UCHAR ucFakeEDIDString[]; // This actually has ucFakeEdidLength elements. > } ATOM_FAKE_EDID_PATCH_RECORD; > > typedef struct _ATOM_PANEL_RESOLUTION_PATCH_RECORD ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] [next] drm/amdgpu: Replace one-element array with flexible-array member 2022-10-28 7:18 ` Christian König 2022-10-28 16:36 ` Kees Cook @ 2022-10-28 16:36 ` Kees Cook 0 siblings, 0 replies; 16+ messages in thread From: Kees Cook @ 2022-10-28 16:36 UTC (permalink / raw) To: Christian König Cc: Paulo Miguel Almeida, Grigory Vasilyev, Pan, Xinhui, linux-kernel, amd-gfx, Slark Xiao, Hans de Goede, Claudio Suarez, dri-devel, Alex Deucher, Rongguang Wei, linux-hardening On Fri, Oct 28, 2022 at 09:18:39AM +0200, Christian König wrote: > Am 28.10.22 um 07:10 schrieb Paulo Miguel Almeida: > > One-element arrays are deprecated, and we are replacing them with > > flexible array members instead. So, replace one-element array with > > flexible-array member in struct _ATOM_FAKE_EDID_PATCH_RECORD and > > refactor the rest of the code accordingly. > > > > This helps with the ongoing efforts to tighten the FORTIFY_SOURCE > > routines on memcpy() and help us make progress towards globally > > enabling -fstrict-flex-arrays=3 [1]. > > > > Link: https://github.com/KSPP/linux/issues/79 > > Link: https://github.com/KSPP/linux/issues/238 > > Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 [1] > > I'm not sure if that's a good idea. We had multiple attempts to refactor > this now and it always caused a regression. > > Additional to that the header in question came from our BIOS team and isn't > following Linux styles in general. > > Alex what do you think? Fake flexible arrays (i.e. 1-element arrays) are deprecated in Linux[1] (and, frankly, deprecated in C since 1999 and even well before then given the 0-sized extension that was added in GCC), so we can't continue to bring them into kernel sources. Their use breaks both compile-time and run-time bounds checking efforts, etc. All that said, converting away from them can be tricky, and I think such conversions need to explicitly show how they were checked for binary differences[2]. Paulo, can you please check for deltas and report your findings in the commit log? Note that add struct_size() use in the same patch may result in binary differences, so for more complex cases, you may want to split the 1-element conversion from the struct_size() conversions. -Kees [1] https://docs.kernel.org/process/deprecated.html#zero-length-and-one-element-arrays [2] https://outflux.net/blog/archives/2022/06/24/finding-binary-differences/ -- Kees Cook ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] [next] drm/amdgpu: Replace one-element array with flexible-array member @ 2022-10-28 16:36 ` Kees Cook 0 siblings, 0 replies; 16+ messages in thread From: Kees Cook @ 2022-10-28 16:36 UTC (permalink / raw) To: Christian König Cc: Paulo Miguel Almeida, Grigory Vasilyev, Pan, Xinhui, linux-kernel, amd-gfx, Slark Xiao, Hans de Goede, Claudio Suarez, dri-devel, Daniel Vetter, Alex Deucher, David Airlie, Rongguang Wei, linux-hardening On Fri, Oct 28, 2022 at 09:18:39AM +0200, Christian König wrote: > Am 28.10.22 um 07:10 schrieb Paulo Miguel Almeida: > > One-element arrays are deprecated, and we are replacing them with > > flexible array members instead. So, replace one-element array with > > flexible-array member in struct _ATOM_FAKE_EDID_PATCH_RECORD and > > refactor the rest of the code accordingly. > > > > This helps with the ongoing efforts to tighten the FORTIFY_SOURCE > > routines on memcpy() and help us make progress towards globally > > enabling -fstrict-flex-arrays=3 [1]. > > > > Link: https://github.com/KSPP/linux/issues/79 > > Link: https://github.com/KSPP/linux/issues/238 > > Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 [1] > > I'm not sure if that's a good idea. We had multiple attempts to refactor > this now and it always caused a regression. > > Additional to that the header in question came from our BIOS team and isn't > following Linux styles in general. > > Alex what do you think? Fake flexible arrays (i.e. 1-element arrays) are deprecated in Linux[1] (and, frankly, deprecated in C since 1999 and even well before then given the 0-sized extension that was added in GCC), so we can't continue to bring them into kernel sources. Their use breaks both compile-time and run-time bounds checking efforts, etc. All that said, converting away from them can be tricky, and I think such conversions need to explicitly show how they were checked for binary differences[2]. Paulo, can you please check for deltas and report your findings in the commit log? Note that add struct_size() use in the same patch may result in binary differences, so for more complex cases, you may want to split the 1-element conversion from the struct_size() conversions. -Kees [1] https://docs.kernel.org/process/deprecated.html#zero-length-and-one-element-arrays [2] https://outflux.net/blog/archives/2022/06/24/finding-binary-differences/ -- Kees Cook ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] [next] drm/amdgpu: Replace one-element array with flexible-array member @ 2022-10-28 16:36 ` Kees Cook 0 siblings, 0 replies; 16+ messages in thread From: Kees Cook @ 2022-10-28 16:36 UTC (permalink / raw) To: Christian König Cc: Paulo Miguel Almeida, Alex Deucher, Pan, Xinhui, David Airlie, Daniel Vetter, Hans de Goede, Grigory Vasilyev, Claudio Suarez, Slark Xiao, Rongguang Wei, amd-gfx, dri-devel, linux-kernel, linux-hardening On Fri, Oct 28, 2022 at 09:18:39AM +0200, Christian König wrote: > Am 28.10.22 um 07:10 schrieb Paulo Miguel Almeida: > > One-element arrays are deprecated, and we are replacing them with > > flexible array members instead. So, replace one-element array with > > flexible-array member in struct _ATOM_FAKE_EDID_PATCH_RECORD and > > refactor the rest of the code accordingly. > > > > This helps with the ongoing efforts to tighten the FORTIFY_SOURCE > > routines on memcpy() and help us make progress towards globally > > enabling -fstrict-flex-arrays=3 [1]. > > > > Link: https://github.com/KSPP/linux/issues/79 > > Link: https://github.com/KSPP/linux/issues/238 > > Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 [1] > > I'm not sure if that's a good idea. We had multiple attempts to refactor > this now and it always caused a regression. > > Additional to that the header in question came from our BIOS team and isn't > following Linux styles in general. > > Alex what do you think? Fake flexible arrays (i.e. 1-element arrays) are deprecated in Linux[1] (and, frankly, deprecated in C since 1999 and even well before then given the 0-sized extension that was added in GCC), so we can't continue to bring them into kernel sources. Their use breaks both compile-time and run-time bounds checking efforts, etc. All that said, converting away from them can be tricky, and I think such conversions need to explicitly show how they were checked for binary differences[2]. Paulo, can you please check for deltas and report your findings in the commit log? Note that add struct_size() use in the same patch may result in binary differences, so for more complex cases, you may want to split the 1-element conversion from the struct_size() conversions. -Kees [1] https://docs.kernel.org/process/deprecated.html#zero-length-and-one-element-arrays [2] https://outflux.net/blog/archives/2022/06/24/finding-binary-differences/ -- Kees Cook ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] [next] drm/amdgpu: Replace one-element array with flexible-array member 2022-10-28 16:36 ` Kees Cook (?) @ 2022-10-28 17:33 ` Christian König -1 siblings, 0 replies; 16+ messages in thread From: Christian König @ 2022-10-28 17:33 UTC (permalink / raw) To: Kees Cook Cc: Paulo Miguel Almeida, Alex Deucher, Pan, Xinhui, David Airlie, Daniel Vetter, Hans de Goede, Grigory Vasilyev, Claudio Suarez, Slark Xiao, Rongguang Wei, amd-gfx, dri-devel, linux-kernel, linux-hardening Am 28.10.22 um 18:36 schrieb Kees Cook: > On Fri, Oct 28, 2022 at 09:18:39AM +0200, Christian König wrote: >> Am 28.10.22 um 07:10 schrieb Paulo Miguel Almeida: >>> One-element arrays are deprecated, and we are replacing them with >>> flexible array members instead. So, replace one-element array with >>> flexible-array member in struct _ATOM_FAKE_EDID_PATCH_RECORD and >>> refactor the rest of the code accordingly. >>> >>> This helps with the ongoing efforts to tighten the FORTIFY_SOURCE >>> routines on memcpy() and help us make progress towards globally >>> enabling -fstrict-flex-arrays=3 [1]. >>> >>> Link: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FKSPP%2Flinux%2Fissues%2F79&data=05%7C01%7Cchristian.koenig%40amd.com%7C600d3657cbe441ae969d08dab9028c1c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638025717852262567%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=h78kYVA3ee9fDDwD5XGNgYJuUAZtBitVpk2354cOLO4%3D&reserved=0 >>> Link: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FKSPP%2Flinux%2Fissues%2F238&data=05%7C01%7Cchristian.koenig%40amd.com%7C600d3657cbe441ae969d08dab9028c1c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638025717852262567%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=k1k7LwxIxIw5c9QM3gM2pA9DVGF4Kz20IJWs5tY4xzE%3D&reserved=0 >>> Link: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.gnu.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D101836&data=05%7C01%7Cchristian.koenig%40amd.com%7C600d3657cbe441ae969d08dab9028c1c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638025717852262567%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=LJB4Rs1xOE82UpLbqtZOgPgi7OmvR02T9fikpKamdiY%3D&reserved=0 [1] >> I'm not sure if that's a good idea. We had multiple attempts to refactor >> this now and it always caused a regression. >> >> Additional to that the header in question came from our BIOS team and isn't >> following Linux styles in general. >> >> Alex what do you think? > Fake flexible arrays (i.e. 1-element arrays) are deprecated in Linux[1] > (and, frankly, deprecated in C since 1999 and even well before then given > the 0-sized extension that was added in GCC), so we can't continue to > bring them into kernel sources. Their use breaks both compile-time and > run-time bounds checking efforts, etc. I'm perfectly aware of that. The issue is that we have tried to fix this multiple times now and reverted back to the original behavior because some user with a 10-15 year old hardware complained that it broke his system. We can't really test every hw generation of the last 15 years for regressions. > All that said, converting away from them can be tricky, and I think such > conversions need to explicitly show how they were checked for binary > differences[2]. Oh, that's a great idea! Yes, if this can be guaranteed then the change is obviously perfectly ok. Thanks, Christian. > > Paulo, can you please check for deltas and report your findings in the > commit log? Note that add struct_size() use in the same patch may result > in binary differences, so for more complex cases, you may want to split > the 1-element conversion from the struct_size() conversions. > > -Kees > > [1] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.kernel.org%2Fprocess%2Fdeprecated.html%23zero-length-and-one-element-arrays&data=05%7C01%7Cchristian.koenig%40amd.com%7C600d3657cbe441ae969d08dab9028c1c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638025717852262567%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6v1qt3zMrSTFDgnF9TO3aurqvG1fPjH2grRu47e2tEA%3D&reserved=0 > [2] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Foutflux.net%2Fblog%2Farchives%2F2022%2F06%2F24%2Ffinding-binary-differences%2F&data=05%7C01%7Cchristian.koenig%40amd.com%7C600d3657cbe441ae969d08dab9028c1c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638025717852262567%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=g3yCIXBAD0OJwK5EdxRfJVeSBevbA1WOeyFM%2BiZC%2F%2FM%3D&reserved=0 > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] [next] drm/amdgpu: Replace one-element array with flexible-array member @ 2022-10-28 17:33 ` Christian König 0 siblings, 0 replies; 16+ messages in thread From: Christian König @ 2022-10-28 17:33 UTC (permalink / raw) To: Kees Cook Cc: Paulo Miguel Almeida, Grigory Vasilyev, Pan, Xinhui, linux-kernel, amd-gfx, Slark Xiao, Hans de Goede, Claudio Suarez, dri-devel, Daniel Vetter, Alex Deucher, David Airlie, Rongguang Wei, linux-hardening Am 28.10.22 um 18:36 schrieb Kees Cook: > On Fri, Oct 28, 2022 at 09:18:39AM +0200, Christian König wrote: >> Am 28.10.22 um 07:10 schrieb Paulo Miguel Almeida: >>> One-element arrays are deprecated, and we are replacing them with >>> flexible array members instead. So, replace one-element array with >>> flexible-array member in struct _ATOM_FAKE_EDID_PATCH_RECORD and >>> refactor the rest of the code accordingly. >>> >>> This helps with the ongoing efforts to tighten the FORTIFY_SOURCE >>> routines on memcpy() and help us make progress towards globally >>> enabling -fstrict-flex-arrays=3 [1]. >>> >>> Link: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FKSPP%2Flinux%2Fissues%2F79&data=05%7C01%7Cchristian.koenig%40amd.com%7C600d3657cbe441ae969d08dab9028c1c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638025717852262567%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=h78kYVA3ee9fDDwD5XGNgYJuUAZtBitVpk2354cOLO4%3D&reserved=0 >>> Link: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FKSPP%2Flinux%2Fissues%2F238&data=05%7C01%7Cchristian.koenig%40amd.com%7C600d3657cbe441ae969d08dab9028c1c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638025717852262567%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=k1k7LwxIxIw5c9QM3gM2pA9DVGF4Kz20IJWs5tY4xzE%3D&reserved=0 >>> Link: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.gnu.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D101836&data=05%7C01%7Cchristian.koenig%40amd.com%7C600d3657cbe441ae969d08dab9028c1c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638025717852262567%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=LJB4Rs1xOE82UpLbqtZOgPgi7OmvR02T9fikpKamdiY%3D&reserved=0 [1] >> I'm not sure if that's a good idea. We had multiple attempts to refactor >> this now and it always caused a regression. >> >> Additional to that the header in question came from our BIOS team and isn't >> following Linux styles in general. >> >> Alex what do you think? > Fake flexible arrays (i.e. 1-element arrays) are deprecated in Linux[1] > (and, frankly, deprecated in C since 1999 and even well before then given > the 0-sized extension that was added in GCC), so we can't continue to > bring them into kernel sources. Their use breaks both compile-time and > run-time bounds checking efforts, etc. I'm perfectly aware of that. The issue is that we have tried to fix this multiple times now and reverted back to the original behavior because some user with a 10-15 year old hardware complained that it broke his system. We can't really test every hw generation of the last 15 years for regressions. > All that said, converting away from them can be tricky, and I think such > conversions need to explicitly show how they were checked for binary > differences[2]. Oh, that's a great idea! Yes, if this can be guaranteed then the change is obviously perfectly ok. Thanks, Christian. > > Paulo, can you please check for deltas and report your findings in the > commit log? Note that add struct_size() use in the same patch may result > in binary differences, so for more complex cases, you may want to split > the 1-element conversion from the struct_size() conversions. > > -Kees > > [1] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.kernel.org%2Fprocess%2Fdeprecated.html%23zero-length-and-one-element-arrays&data=05%7C01%7Cchristian.koenig%40amd.com%7C600d3657cbe441ae969d08dab9028c1c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638025717852262567%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6v1qt3zMrSTFDgnF9TO3aurqvG1fPjH2grRu47e2tEA%3D&reserved=0 > [2] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Foutflux.net%2Fblog%2Farchives%2F2022%2F06%2F24%2Ffinding-binary-differences%2F&data=05%7C01%7Cchristian.koenig%40amd.com%7C600d3657cbe441ae969d08dab9028c1c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638025717852262567%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=g3yCIXBAD0OJwK5EdxRfJVeSBevbA1WOeyFM%2BiZC%2F%2FM%3D&reserved=0 > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] [next] drm/amdgpu: Replace one-element array with flexible-array member @ 2022-10-28 17:33 ` Christian König 0 siblings, 0 replies; 16+ messages in thread From: Christian König @ 2022-10-28 17:33 UTC (permalink / raw) To: Kees Cook Cc: Paulo Miguel Almeida, Grigory Vasilyev, Pan, Xinhui, linux-kernel, amd-gfx, Slark Xiao, Hans de Goede, Claudio Suarez, dri-devel, Alex Deucher, Rongguang Wei, linux-hardening Am 28.10.22 um 18:36 schrieb Kees Cook: > On Fri, Oct 28, 2022 at 09:18:39AM +0200, Christian König wrote: >> Am 28.10.22 um 07:10 schrieb Paulo Miguel Almeida: >>> One-element arrays are deprecated, and we are replacing them with >>> flexible array members instead. So, replace one-element array with >>> flexible-array member in struct _ATOM_FAKE_EDID_PATCH_RECORD and >>> refactor the rest of the code accordingly. >>> >>> This helps with the ongoing efforts to tighten the FORTIFY_SOURCE >>> routines on memcpy() and help us make progress towards globally >>> enabling -fstrict-flex-arrays=3 [1]. >>> >>> Link: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FKSPP%2Flinux%2Fissues%2F79&data=05%7C01%7Cchristian.koenig%40amd.com%7C600d3657cbe441ae969d08dab9028c1c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638025717852262567%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=h78kYVA3ee9fDDwD5XGNgYJuUAZtBitVpk2354cOLO4%3D&reserved=0 >>> Link: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FKSPP%2Flinux%2Fissues%2F238&data=05%7C01%7Cchristian.koenig%40amd.com%7C600d3657cbe441ae969d08dab9028c1c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638025717852262567%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=k1k7LwxIxIw5c9QM3gM2pA9DVGF4Kz20IJWs5tY4xzE%3D&reserved=0 >>> Link: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.gnu.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D101836&data=05%7C01%7Cchristian.koenig%40amd.com%7C600d3657cbe441ae969d08dab9028c1c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638025717852262567%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=LJB4Rs1xOE82UpLbqtZOgPgi7OmvR02T9fikpKamdiY%3D&reserved=0 [1] >> I'm not sure if that's a good idea. We had multiple attempts to refactor >> this now and it always caused a regression. >> >> Additional to that the header in question came from our BIOS team and isn't >> following Linux styles in general. >> >> Alex what do you think? > Fake flexible arrays (i.e. 1-element arrays) are deprecated in Linux[1] > (and, frankly, deprecated in C since 1999 and even well before then given > the 0-sized extension that was added in GCC), so we can't continue to > bring them into kernel sources. Their use breaks both compile-time and > run-time bounds checking efforts, etc. I'm perfectly aware of that. The issue is that we have tried to fix this multiple times now and reverted back to the original behavior because some user with a 10-15 year old hardware complained that it broke his system. We can't really test every hw generation of the last 15 years for regressions. > All that said, converting away from them can be tricky, and I think such > conversions need to explicitly show how they were checked for binary > differences[2]. Oh, that's a great idea! Yes, if this can be guaranteed then the change is obviously perfectly ok. Thanks, Christian. > > Paulo, can you please check for deltas and report your findings in the > commit log? Note that add struct_size() use in the same patch may result > in binary differences, so for more complex cases, you may want to split > the 1-element conversion from the struct_size() conversions. > > -Kees > > [1] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.kernel.org%2Fprocess%2Fdeprecated.html%23zero-length-and-one-element-arrays&data=05%7C01%7Cchristian.koenig%40amd.com%7C600d3657cbe441ae969d08dab9028c1c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638025717852262567%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=6v1qt3zMrSTFDgnF9TO3aurqvG1fPjH2grRu47e2tEA%3D&reserved=0 > [2] https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Foutflux.net%2Fblog%2Farchives%2F2022%2F06%2F24%2Ffinding-binary-differences%2F&data=05%7C01%7Cchristian.koenig%40amd.com%7C600d3657cbe441ae969d08dab9028c1c%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638025717852262567%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=g3yCIXBAD0OJwK5EdxRfJVeSBevbA1WOeyFM%2BiZC%2F%2FM%3D&reserved=0 > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] [next] drm/amdgpu: Replace one-element array with flexible-array member 2022-10-28 17:33 ` Christian König (?) @ 2022-10-29 0:43 ` Paulo Miguel Almeida -1 siblings, 0 replies; 16+ messages in thread From: Paulo Miguel Almeida @ 2022-10-29 0:43 UTC (permalink / raw) To: Christian König Cc: Kees Cook, Alex Deucher, Pan, Xinhui, David Airlie, Daniel Vetter, Hans de Goede, Grigory Vasilyev, Claudio Suarez, Slark Xiao, Rongguang Wei, amd-gfx, dri-devel, linux-kernel, linux-hardening On Fri, Oct 28, 2022 at 07:33:17PM +0200, Christian König wrote: > Am 28.10.22 um 18:36 schrieb Kees Cook: > > > All that said, converting away from them can be tricky, and I think such > > conversions need to explicitly show how they were checked for binary > > differences[2]. > > Oh, that's a great idea! Yes, if this can be guaranteed then the change is > obviously perfectly ok. > > > > > Paulo, can you please check for deltas and report your findings in the > > commit log? Note that add struct_size() use in the same patch may result > > in binary differences, so for more complex cases, you may want to split > > the 1-element conversion from the struct_size() conversions. > > > > -Kees Noted. I will reporting my findings on commit logs from now onwards. Given that I split the if-ternary to avoid checking "fake_edid_record->ucFakeEDIDLength" twice then (for the current patch), yes, there will be changes to *.o|ko files. Knowing that Christian would feel more confident with no binary changes at this point, I will send a different patch aiming solely on the replacement of 1-elem array without incurring binary changes. -- Paulo A. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] [next] drm/amdgpu: Replace one-element array with flexible-array member @ 2022-10-29 0:43 ` Paulo Miguel Almeida 0 siblings, 0 replies; 16+ messages in thread From: Paulo Miguel Almeida @ 2022-10-29 0:43 UTC (permalink / raw) To: Christian König Cc: Kees Cook, Grigory Vasilyev, Pan, Xinhui, linux-kernel, amd-gfx, Slark Xiao, Hans de Goede, Claudio Suarez, dri-devel, Daniel Vetter, Alex Deucher, David Airlie, Rongguang Wei, linux-hardening On Fri, Oct 28, 2022 at 07:33:17PM +0200, Christian König wrote: > Am 28.10.22 um 18:36 schrieb Kees Cook: > > > All that said, converting away from them can be tricky, and I think such > > conversions need to explicitly show how they were checked for binary > > differences[2]. > > Oh, that's a great idea! Yes, if this can be guaranteed then the change is > obviously perfectly ok. > > > > > Paulo, can you please check for deltas and report your findings in the > > commit log? Note that add struct_size() use in the same patch may result > > in binary differences, so for more complex cases, you may want to split > > the 1-element conversion from the struct_size() conversions. > > > > -Kees Noted. I will reporting my findings on commit logs from now onwards. Given that I split the if-ternary to avoid checking "fake_edid_record->ucFakeEDIDLength" twice then (for the current patch), yes, there will be changes to *.o|ko files. Knowing that Christian would feel more confident with no binary changes at this point, I will send a different patch aiming solely on the replacement of 1-elem array without incurring binary changes. -- Paulo A. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH] [next] drm/amdgpu: Replace one-element array with flexible-array member @ 2022-10-29 0:43 ` Paulo Miguel Almeida 0 siblings, 0 replies; 16+ messages in thread From: Paulo Miguel Almeida @ 2022-10-29 0:43 UTC (permalink / raw) To: Christian König Cc: Kees Cook, Grigory Vasilyev, Pan, Xinhui, linux-kernel, amd-gfx, Slark Xiao, Hans de Goede, Claudio Suarez, dri-devel, Alex Deucher, Rongguang Wei, linux-hardening On Fri, Oct 28, 2022 at 07:33:17PM +0200, Christian König wrote: > Am 28.10.22 um 18:36 schrieb Kees Cook: > > > All that said, converting away from them can be tricky, and I think such > > conversions need to explicitly show how they were checked for binary > > differences[2]. > > Oh, that's a great idea! Yes, if this can be guaranteed then the change is > obviously perfectly ok. > > > > > Paulo, can you please check for deltas and report your findings in the > > commit log? Note that add struct_size() use in the same patch may result > > in binary differences, so for more complex cases, you may want to split > > the 1-element conversion from the struct_size() conversions. > > > > -Kees Noted. I will reporting my findings on commit logs from now onwards. Given that I split the if-ternary to avoid checking "fake_edid_record->ucFakeEDIDLength" twice then (for the current patch), yes, there will be changes to *.o|ko files. Knowing that Christian would feel more confident with no binary changes at this point, I will send a different patch aiming solely on the replacement of 1-elem array without incurring binary changes. -- Paulo A. ^ permalink raw reply [flat|nested] 16+ messages in thread
* [PATCH v2] [next] drm/amdgpu: Replace one-element array with flexible-array member 2022-10-29 0:43 ` Paulo Miguel Almeida @ 2022-10-29 1:30 ` Paulo Miguel Almeida -1 siblings, 0 replies; 16+ messages in thread From: Paulo Miguel Almeida @ 2022-10-29 1:30 UTC (permalink / raw) To: Alex Deucher, Christian König, Pan, Xinhui, David Airlie, Daniel Vetter, Hans de Goede, Paulo Miguel Almeida, Claudio Suarez, Harry Wentland, Grigory Vasilyev, Slark Xiao, Rongguang Wei, amd-gfx, dri-devel Cc: linux-kernel, linux-hardening, paulo.miguel.almeida.rodenas One-element arrays are deprecated, and we are replacing them with flexible array members instead. So, replace one-element array with flexible-array member in struct _ATOM_FAKE_EDID_PATCH_RECORD and refactor the rest of the code accordingly. Important to mention is that doing a build before/after this patch results in no binary output differences. This helps with the ongoing efforts to tighten the FORTIFY_SOURCE routines on memcpy() and help us make progress towards globally enabling -fstrict-flex-arrays=3 [1]. Link: https://github.com/KSPP/linux/issues/79 Link: https://github.com/KSPP/linux/issues/238 Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 [1] Signed-off-by: Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@gmail.com> --- Changelog: v2: no binary output differences patch; report binary changes findings on commit log. Res: Kees Cook v1: https://lore.kernel.org/lkml/Y1tkWdwPUp+UdpM0@mail.google.com/ --- drivers/gpu/drm/amd/amdgpu/atombios_encoders.c | 7 +++++-- drivers/gpu/drm/amd/include/atombios.h | 2 +- 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c index 6be9ac2b9c5b..18ae9433e463 100644 --- a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c +++ b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c @@ -2081,8 +2081,11 @@ amdgpu_atombios_encoder_get_lcd_info(struct amdgpu_encoder *encoder) } } record += fake_edid_record->ucFakeEDIDLength ? - fake_edid_record->ucFakeEDIDLength + 2 : - sizeof(ATOM_FAKE_EDID_PATCH_RECORD); + struct_size(fake_edid_record, + ucFakeEDIDString, + fake_edid_record->ucFakeEDIDLength) : + /* empty fake edid record must be 3 bytes long */ + sizeof(ATOM_FAKE_EDID_PATCH_RECORD) + 1; break; case LCD_PANEL_RESOLUTION_RECORD_TYPE: panel_res_record = (ATOM_PANEL_RESOLUTION_PATCH_RECORD *)record; diff --git a/drivers/gpu/drm/amd/include/atombios.h b/drivers/gpu/drm/amd/include/atombios.h index 15943bc21bc5..b5b1d073f8e2 100644 --- a/drivers/gpu/drm/amd/include/atombios.h +++ b/drivers/gpu/drm/amd/include/atombios.h @@ -4107,7 +4107,7 @@ typedef struct _ATOM_FAKE_EDID_PATCH_RECORD { UCHAR ucRecordType; UCHAR ucFakeEDIDLength; // = 128 means EDID length is 128 bytes, otherwise the EDID length = ucFakeEDIDLength*128 - UCHAR ucFakeEDIDString[1]; // This actually has ucFakeEdidLength elements. + UCHAR ucFakeEDIDString[]; // This actually has ucFakeEdidLength elements. } ATOM_FAKE_EDID_PATCH_RECORD; typedef struct _ATOM_PANEL_RESOLUTION_PATCH_RECORD -- 2.37.3 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* [PATCH v2] [next] drm/amdgpu: Replace one-element array with flexible-array member @ 2022-10-29 1:30 ` Paulo Miguel Almeida 0 siblings, 0 replies; 16+ messages in thread From: Paulo Miguel Almeida @ 2022-10-29 1:30 UTC (permalink / raw) To: Alex Deucher, Christian König, Pan, Xinhui, David Airlie, Daniel Vetter, Hans de Goede, Paulo Miguel Almeida, Claudio Suarez, Harry Wentland, Grigory Vasilyev, Slark Xiao, Rongguang Wei, amd-gfx, dri-devel Cc: paulo.miguel.almeida.rodenas, linux-kernel, linux-hardening One-element arrays are deprecated, and we are replacing them with flexible array members instead. So, replace one-element array with flexible-array member in struct _ATOM_FAKE_EDID_PATCH_RECORD and refactor the rest of the code accordingly. Important to mention is that doing a build before/after this patch results in no binary output differences. This helps with the ongoing efforts to tighten the FORTIFY_SOURCE routines on memcpy() and help us make progress towards globally enabling -fstrict-flex-arrays=3 [1]. Link: https://github.com/KSPP/linux/issues/79 Link: https://github.com/KSPP/linux/issues/238 Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 [1] Signed-off-by: Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@gmail.com> --- Changelog: v2: no binary output differences patch; report binary changes findings on commit log. Res: Kees Cook v1: https://lore.kernel.org/lkml/Y1tkWdwPUp+UdpM0@mail.google.com/ --- drivers/gpu/drm/amd/amdgpu/atombios_encoders.c | 7 +++++-- drivers/gpu/drm/amd/include/atombios.h | 2 +- 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c index 6be9ac2b9c5b..18ae9433e463 100644 --- a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c +++ b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c @@ -2081,8 +2081,11 @@ amdgpu_atombios_encoder_get_lcd_info(struct amdgpu_encoder *encoder) } } record += fake_edid_record->ucFakeEDIDLength ? - fake_edid_record->ucFakeEDIDLength + 2 : - sizeof(ATOM_FAKE_EDID_PATCH_RECORD); + struct_size(fake_edid_record, + ucFakeEDIDString, + fake_edid_record->ucFakeEDIDLength) : + /* empty fake edid record must be 3 bytes long */ + sizeof(ATOM_FAKE_EDID_PATCH_RECORD) + 1; break; case LCD_PANEL_RESOLUTION_RECORD_TYPE: panel_res_record = (ATOM_PANEL_RESOLUTION_PATCH_RECORD *)record; diff --git a/drivers/gpu/drm/amd/include/atombios.h b/drivers/gpu/drm/amd/include/atombios.h index 15943bc21bc5..b5b1d073f8e2 100644 --- a/drivers/gpu/drm/amd/include/atombios.h +++ b/drivers/gpu/drm/amd/include/atombios.h @@ -4107,7 +4107,7 @@ typedef struct _ATOM_FAKE_EDID_PATCH_RECORD { UCHAR ucRecordType; UCHAR ucFakeEDIDLength; // = 128 means EDID length is 128 bytes, otherwise the EDID length = ucFakeEDIDLength*128 - UCHAR ucFakeEDIDString[1]; // This actually has ucFakeEdidLength elements. + UCHAR ucFakeEDIDString[]; // This actually has ucFakeEdidLength elements. } ATOM_FAKE_EDID_PATCH_RECORD; typedef struct _ATOM_PANEL_RESOLUTION_PATCH_RECORD -- 2.37.3 ^ permalink raw reply related [flat|nested] 16+ messages in thread
* Re: [PATCH v2] [next] drm/amdgpu: Replace one-element array with flexible-array member 2022-10-29 1:30 ` Paulo Miguel Almeida (?) @ 2022-11-02 16:12 ` Alex Deucher -1 siblings, 0 replies; 16+ messages in thread From: Alex Deucher @ 2022-11-02 16:12 UTC (permalink / raw) To: Paulo Miguel Almeida Cc: Grigory Vasilyev, Pan, Xinhui, linux-kernel, amd-gfx, Slark Xiao, Hans de Goede, Claudio Suarez, dri-devel, Alex Deucher, Christian König, Rongguang Wei, linux-hardening Applied. Thanks! Alex On Fri, Oct 28, 2022 at 9:31 PM Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@gmail.com> wrote: > > One-element arrays are deprecated, and we are replacing them with > flexible array members instead. So, replace one-element array with > flexible-array member in struct _ATOM_FAKE_EDID_PATCH_RECORD and > refactor the rest of the code accordingly. > > Important to mention is that doing a build before/after this patch > results in no binary output differences. > > This helps with the ongoing efforts to tighten the FORTIFY_SOURCE > routines on memcpy() and help us make progress towards globally > enabling -fstrict-flex-arrays=3 [1]. > > Link: https://github.com/KSPP/linux/issues/79 > Link: https://github.com/KSPP/linux/issues/238 > Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 [1] > > Signed-off-by: Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@gmail.com> > --- > Changelog: > > v2: no binary output differences patch; report binary changes findings > on commit log. Res: Kees Cook > v1: https://lore.kernel.org/lkml/Y1tkWdwPUp+UdpM0@mail.google.com/ > --- > drivers/gpu/drm/amd/amdgpu/atombios_encoders.c | 7 +++++-- > drivers/gpu/drm/amd/include/atombios.h | 2 +- > 2 files changed, 6 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c > index 6be9ac2b9c5b..18ae9433e463 100644 > --- a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c > +++ b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c > @@ -2081,8 +2081,11 @@ amdgpu_atombios_encoder_get_lcd_info(struct amdgpu_encoder *encoder) > } > } > record += fake_edid_record->ucFakeEDIDLength ? > - fake_edid_record->ucFakeEDIDLength + 2 : > - sizeof(ATOM_FAKE_EDID_PATCH_RECORD); > + struct_size(fake_edid_record, > + ucFakeEDIDString, > + fake_edid_record->ucFakeEDIDLength) : > + /* empty fake edid record must be 3 bytes long */ > + sizeof(ATOM_FAKE_EDID_PATCH_RECORD) + 1; > break; > case LCD_PANEL_RESOLUTION_RECORD_TYPE: > panel_res_record = (ATOM_PANEL_RESOLUTION_PATCH_RECORD *)record; > diff --git a/drivers/gpu/drm/amd/include/atombios.h b/drivers/gpu/drm/amd/include/atombios.h > index 15943bc21bc5..b5b1d073f8e2 100644 > --- a/drivers/gpu/drm/amd/include/atombios.h > +++ b/drivers/gpu/drm/amd/include/atombios.h > @@ -4107,7 +4107,7 @@ typedef struct _ATOM_FAKE_EDID_PATCH_RECORD > { > UCHAR ucRecordType; > UCHAR ucFakeEDIDLength; // = 128 means EDID length is 128 bytes, otherwise the EDID length = ucFakeEDIDLength*128 > - UCHAR ucFakeEDIDString[1]; // This actually has ucFakeEdidLength elements. > + UCHAR ucFakeEDIDString[]; // This actually has ucFakeEdidLength elements. > } ATOM_FAKE_EDID_PATCH_RECORD; > > typedef struct _ATOM_PANEL_RESOLUTION_PATCH_RECORD > -- > 2.37.3 > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2] [next] drm/amdgpu: Replace one-element array with flexible-array member @ 2022-11-02 16:12 ` Alex Deucher 0 siblings, 0 replies; 16+ messages in thread From: Alex Deucher @ 2022-11-02 16:12 UTC (permalink / raw) To: Paulo Miguel Almeida Cc: Alex Deucher, Christian König, Pan, Xinhui, David Airlie, Daniel Vetter, Hans de Goede, Claudio Suarez, Harry Wentland, Grigory Vasilyev, Slark Xiao, Rongguang Wei, amd-gfx, dri-devel, linux-kernel, linux-hardening Applied. Thanks! Alex On Fri, Oct 28, 2022 at 9:31 PM Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@gmail.com> wrote: > > One-element arrays are deprecated, and we are replacing them with > flexible array members instead. So, replace one-element array with > flexible-array member in struct _ATOM_FAKE_EDID_PATCH_RECORD and > refactor the rest of the code accordingly. > > Important to mention is that doing a build before/after this patch > results in no binary output differences. > > This helps with the ongoing efforts to tighten the FORTIFY_SOURCE > routines on memcpy() and help us make progress towards globally > enabling -fstrict-flex-arrays=3 [1]. > > Link: https://github.com/KSPP/linux/issues/79 > Link: https://github.com/KSPP/linux/issues/238 > Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 [1] > > Signed-off-by: Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@gmail.com> > --- > Changelog: > > v2: no binary output differences patch; report binary changes findings > on commit log. Res: Kees Cook > v1: https://lore.kernel.org/lkml/Y1tkWdwPUp+UdpM0@mail.google.com/ > --- > drivers/gpu/drm/amd/amdgpu/atombios_encoders.c | 7 +++++-- > drivers/gpu/drm/amd/include/atombios.h | 2 +- > 2 files changed, 6 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c > index 6be9ac2b9c5b..18ae9433e463 100644 > --- a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c > +++ b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c > @@ -2081,8 +2081,11 @@ amdgpu_atombios_encoder_get_lcd_info(struct amdgpu_encoder *encoder) > } > } > record += fake_edid_record->ucFakeEDIDLength ? > - fake_edid_record->ucFakeEDIDLength + 2 : > - sizeof(ATOM_FAKE_EDID_PATCH_RECORD); > + struct_size(fake_edid_record, > + ucFakeEDIDString, > + fake_edid_record->ucFakeEDIDLength) : > + /* empty fake edid record must be 3 bytes long */ > + sizeof(ATOM_FAKE_EDID_PATCH_RECORD) + 1; > break; > case LCD_PANEL_RESOLUTION_RECORD_TYPE: > panel_res_record = (ATOM_PANEL_RESOLUTION_PATCH_RECORD *)record; > diff --git a/drivers/gpu/drm/amd/include/atombios.h b/drivers/gpu/drm/amd/include/atombios.h > index 15943bc21bc5..b5b1d073f8e2 100644 > --- a/drivers/gpu/drm/amd/include/atombios.h > +++ b/drivers/gpu/drm/amd/include/atombios.h > @@ -4107,7 +4107,7 @@ typedef struct _ATOM_FAKE_EDID_PATCH_RECORD > { > UCHAR ucRecordType; > UCHAR ucFakeEDIDLength; // = 128 means EDID length is 128 bytes, otherwise the EDID length = ucFakeEDIDLength*128 > - UCHAR ucFakeEDIDString[1]; // This actually has ucFakeEdidLength elements. > + UCHAR ucFakeEDIDString[]; // This actually has ucFakeEdidLength elements. > } ATOM_FAKE_EDID_PATCH_RECORD; > > typedef struct _ATOM_PANEL_RESOLUTION_PATCH_RECORD > -- > 2.37.3 > ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [PATCH v2] [next] drm/amdgpu: Replace one-element array with flexible-array member @ 2022-11-02 16:12 ` Alex Deucher 0 siblings, 0 replies; 16+ messages in thread From: Alex Deucher @ 2022-11-02 16:12 UTC (permalink / raw) To: Paulo Miguel Almeida Cc: Grigory Vasilyev, Harry Wentland, Pan, Xinhui, linux-kernel, amd-gfx, Slark Xiao, Hans de Goede, Claudio Suarez, dri-devel, Daniel Vetter, Alex Deucher, David Airlie, Christian König, Rongguang Wei, linux-hardening Applied. Thanks! Alex On Fri, Oct 28, 2022 at 9:31 PM Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@gmail.com> wrote: > > One-element arrays are deprecated, and we are replacing them with > flexible array members instead. So, replace one-element array with > flexible-array member in struct _ATOM_FAKE_EDID_PATCH_RECORD and > refactor the rest of the code accordingly. > > Important to mention is that doing a build before/after this patch > results in no binary output differences. > > This helps with the ongoing efforts to tighten the FORTIFY_SOURCE > routines on memcpy() and help us make progress towards globally > enabling -fstrict-flex-arrays=3 [1]. > > Link: https://github.com/KSPP/linux/issues/79 > Link: https://github.com/KSPP/linux/issues/238 > Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 [1] > > Signed-off-by: Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@gmail.com> > --- > Changelog: > > v2: no binary output differences patch; report binary changes findings > on commit log. Res: Kees Cook > v1: https://lore.kernel.org/lkml/Y1tkWdwPUp+UdpM0@mail.google.com/ > --- > drivers/gpu/drm/amd/amdgpu/atombios_encoders.c | 7 +++++-- > drivers/gpu/drm/amd/include/atombios.h | 2 +- > 2 files changed, 6 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c > index 6be9ac2b9c5b..18ae9433e463 100644 > --- a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c > +++ b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c > @@ -2081,8 +2081,11 @@ amdgpu_atombios_encoder_get_lcd_info(struct amdgpu_encoder *encoder) > } > } > record += fake_edid_record->ucFakeEDIDLength ? > - fake_edid_record->ucFakeEDIDLength + 2 : > - sizeof(ATOM_FAKE_EDID_PATCH_RECORD); > + struct_size(fake_edid_record, > + ucFakeEDIDString, > + fake_edid_record->ucFakeEDIDLength) : > + /* empty fake edid record must be 3 bytes long */ > + sizeof(ATOM_FAKE_EDID_PATCH_RECORD) + 1; > break; > case LCD_PANEL_RESOLUTION_RECORD_TYPE: > panel_res_record = (ATOM_PANEL_RESOLUTION_PATCH_RECORD *)record; > diff --git a/drivers/gpu/drm/amd/include/atombios.h b/drivers/gpu/drm/amd/include/atombios.h > index 15943bc21bc5..b5b1d073f8e2 100644 > --- a/drivers/gpu/drm/amd/include/atombios.h > +++ b/drivers/gpu/drm/amd/include/atombios.h > @@ -4107,7 +4107,7 @@ typedef struct _ATOM_FAKE_EDID_PATCH_RECORD > { > UCHAR ucRecordType; > UCHAR ucFakeEDIDLength; // = 128 means EDID length is 128 bytes, otherwise the EDID length = ucFakeEDIDLength*128 > - UCHAR ucFakeEDIDString[1]; // This actually has ucFakeEdidLength elements. > + UCHAR ucFakeEDIDString[]; // This actually has ucFakeEdidLength elements. > } ATOM_FAKE_EDID_PATCH_RECORD; > > typedef struct _ATOM_PANEL_RESOLUTION_PATCH_RECORD > -- > 2.37.3 > ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2022-11-02 16:17 UTC | newest] Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-10-28 5:10 [PATCH] [next] drm/amdgpu: Replace one-element array with flexible-array member Paulo Miguel Almeida 2022-10-28 7:18 ` Christian König 2022-10-28 16:36 ` Kees Cook 2022-10-28 16:36 ` Kees Cook 2022-10-28 16:36 ` Kees Cook 2022-10-28 17:33 ` Christian König 2022-10-28 17:33 ` Christian König 2022-10-28 17:33 ` Christian König 2022-10-29 0:43 ` Paulo Miguel Almeida 2022-10-29 0:43 ` Paulo Miguel Almeida 2022-10-29 0:43 ` Paulo Miguel Almeida 2022-10-29 1:30 ` [PATCH v2] " Paulo Miguel Almeida 2022-10-29 1:30 ` Paulo Miguel Almeida 2022-11-02 16:12 ` Alex Deucher 2022-11-02 16:12 ` Alex Deucher 2022-11-02 16:12 ` Alex Deucher
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.