From: Kees Cook <keescook@chromium.org>
To: "Christian König" <christian.koenig@amd.com>
Cc: Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@gmail.com>,
Grigory Vasilyev <h0tc0d3@gmail.com>,
"Pan, Xinhui" <Xinhui.Pan@amd.com>,
linux-kernel@vger.kernel.org, amd-gfx@lists.freedesktop.org,
Slark Xiao <slark_xiao@163.com>,
Hans de Goede <hdegoede@redhat.com>,
Claudio Suarez <cssk@net-c.es>,
dri-devel@lists.freedesktop.org, Daniel Vetter <daniel@ffwll.ch>,
Alex Deucher <alexander.deucher@amd.com>,
David Airlie <airlied@gmail.com>,
Rongguang Wei <weirongguang@kylinos.cn>,
linux-hardening@vger.kernel.org
Subject: Re: [PATCH] [next] drm/amdgpu: Replace one-element array with flexible-array member
Date: Fri, 28 Oct 2022 09:36:19 -0700 [thread overview]
Message-ID: <202210280855.9DF8E4D72@keescook> (raw)
In-Reply-To: <04e37ee1-53b0-97ab-d6d7-a39edfbdc2ea@amd.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <keescook@chromium.org>
To: "Christian König" <christian.koenig@amd.com>
Cc: Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@gmail.com>,
Alex Deucher <alexander.deucher@amd.com>,
"Pan, Xinhui" <Xinhui.Pan@amd.com>,
David Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>,
Hans de Goede <hdegoede@redhat.com>,
Grigory Vasilyev <h0tc0d3@gmail.com>,
Claudio Suarez <cssk@net-c.es>, Slark Xiao <slark_xiao@163.com>,
Rongguang Wei <weirongguang@kylinos.cn>,
amd-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org, linux-hardening@vger.kernel.org
Subject: Re: [PATCH] [next] drm/amdgpu: Replace one-element array with flexible-array member
Date: Fri, 28 Oct 2022 09:36:19 -0700 [thread overview]
Message-ID: <202210280855.9DF8E4D72@keescook> (raw)
In-Reply-To: <04e37ee1-53b0-97ab-d6d7-a39edfbdc2ea@amd.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: Kees Cook <keescook@chromium.org>
To: "Christian König" <christian.koenig@amd.com>
Cc: Paulo Miguel Almeida <paulo.miguel.almeida.rodenas@gmail.com>,
Grigory Vasilyev <h0tc0d3@gmail.com>,
"Pan, Xinhui" <Xinhui.Pan@amd.com>,
linux-kernel@vger.kernel.org, amd-gfx@lists.freedesktop.org,
Slark Xiao <slark_xiao@163.com>,
Hans de Goede <hdegoede@redhat.com>,
Claudio Suarez <cssk@net-c.es>,
dri-devel@lists.freedesktop.org,
Alex Deucher <alexander.deucher@amd.com>,
Rongguang Wei <weirongguang@kylinos.cn>,
linux-hardening@vger.kernel.org
Subject: Re: [PATCH] [next] drm/amdgpu: Replace one-element array with flexible-array member
Date: Fri, 28 Oct 2022 09:36:19 -0700 [thread overview]
Message-ID: <202210280855.9DF8E4D72@keescook> (raw)
In-Reply-To: <04e37ee1-53b0-97ab-d6d7-a39edfbdc2ea@amd.com>
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
next prev parent reply other threads:[~2022-10-31 8:14 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
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=202210280855.9DF8E4D72@keescook \
--to=keescook@chromium.org \
--cc=Xinhui.Pan@amd.com \
--cc=airlied@gmail.com \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=christian.koenig@amd.com \
--cc=cssk@net-c.es \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.org \
--cc=h0tc0d3@gmail.com \
--cc=hdegoede@redhat.com \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=paulo.miguel.almeida.rodenas@gmail.com \
--cc=slark_xiao@163.com \
--cc=weirongguang@kylinos.cn \
/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.