All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Luben Tuikov <luben.tuikov@amd.com>
Cc: "Alex Deucher" <alexdeucher@gmail.com>,
	"Christian Koenig" <christian.koenig@amd.com>,
	"Xiaojie Yuan" <xiaojie.yuan@amd.com>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"David Airlie" <airlied@linux.ie>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Felix Kuehling" <Felix.Kuehling@amd.com>,
	LKML <linux-kernel@vger.kernel.org>,
	"amd-gfx list" <amd-gfx@lists.freedesktop.org>,
	"Nicholas Kazlauskas" <nicholas.kazlauskas@amd.com>,
	"Marek Olšák" <marek.olsak@amd.com>,
	"Hans de Goede" <hdegoede@redhat.com>, Trek <trek00@inbox.ru>,
	"Maling list - DRI developers" <dri-devel@lists.freedesktop.org>,
	"Daniel Vetter" <daniel@ffwll.ch>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Evan Quan" <evan.quan@amd.com>, "Leo Liu" <leo.liu@amd.com>,
	"Peilin Ye" <yepeilin.cs@gmail.com>,
	"Dan Carpenter" <dan.carpenter@oracle.com>,
	linux-kernel-mentees@lists.linuxfoundation.org
Subject: Re: [Linux-kernel-mentees] [PATCH] drm/amdgpu: Prevent kernel-infoleak in amdgpu_info_ioctl()
Date: Fri, 31 Jul 2020 09:34:13 +0200	[thread overview]
Message-ID: <CAK8P3a2+Vv5=bKDR=NU8jcNgAoZRk+EKG11NU7bQSetyVDvn=w@mail.gmail.com> (raw)
In-Reply-To: <8c5cf518-12d2-7495-7822-c7ebf8e61972@amd.com>

On Thu, Jul 30, 2020 at 11:09 PM Luben Tuikov <luben.tuikov@amd.com> wrote:
> On 2020-07-29 9:49 a.m., Alex Deucher wrote:
> > On Wed, Jul 29, 2020 at 4:11 AM Christian König
> > <ckoenig.leichtzumerken@gmail.com> wrote:
> >>
> >> Am 28.07.20 um 21:29 schrieb Peilin Ye:
> >>> Compiler leaves a 4-byte hole near the end of `dev_info`, causing
> >>> amdgpu_info_ioctl() to copy uninitialized kernel stack memory to userspace
> >>> when `size` is greater than 356.
> >>>
> >>> In 2015 we tried to fix this issue by doing `= {};` on `dev_info`, which
> >>> unfortunately does not initialize that 4-byte hole. Fix it by using
> >>> memset() instead.
> >>>
> >>> Cc: stable@vger.kernel.org
> >>> Fixes: c193fa91b918 ("drm/amdgpu: information leak in amdgpu_info_ioctl()")
> >>> Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
> >>> Suggested-by: Dan Carpenter <dan.carpenter@oracle.com>
> >>> Signed-off-by: Peilin Ye <yepeilin.cs@gmail.com>
> >>
> >> Reviewed-by: Christian König <christian.koenig@amd.com>
> >>
> >> I can't count how many of those we have fixed over the years.
> >>
> >> At some point we should probably document that using "= {}" or "= { 0 }"
> >> in the kernel is a really bad idea and should be avoided.
> >
> > Moreover, it seems like different compilers seem to behave relatively
> > differently with these and we often get reports of warnings with these
> > on clang.  When in doubt, memset.
>
> There are quite a few of those under drivers/gpu/drm, for "amd/", "scheduler/"
> drm*.c files,
>
> $find . \( -regex "./drm.*\.c" -or -regex "./amd/.*\.c" -or -regex "./scheduler/.*\.c" \) -exec egrep -n -- " *= *{ *(|NULL|0) *}" \{\} \+ | wc -l
> 374
> $_
>
> Out of which only 16 are of the non-ISO C variety, "= {}",
>
> $find . \( -regex "./drm.*\.c" -or -regex "./amd/.*\.c" -or -regex "./scheduler/.*\.c" \) -exec egrep -n -- " *= *{ *}" \{\} \+ | wc -l
> 16
> $_

That is an unrelated issue, those were introduced to deal with older compilers
that do not accept '{0}' as an initializer for an aggregate whose
first member is
another aggregate. Generally speaking, '= { }' is better to use in the
kernel than
'= { 0 }' because all supported compilers interpret that the same way for all
structures.

     Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Luben Tuikov <luben.tuikov@amd.com>
Cc: "Daniel Vetter" <daniel@ffwll.ch>,
	"David Airlie" <airlied@linux.ie>,
	"Felix Kuehling" <Felix.Kuehling@amd.com>,
	LKML <linux-kernel@vger.kernel.org>,
	"amd-gfx list" <amd-gfx@lists.freedesktop.org>,
	"Nicholas Kazlauskas" <nicholas.kazlauskas@amd.com>,
	"Marek Olšák" <marek.olsak@amd.com>,
	"Hans de Goede" <hdegoede@redhat.com>,
	linux-kernel-mentees@lists.linuxfoundation.org,
	Trek <trek00@inbox.ru>,
	"Maling list - DRI developers" <dri-devel@lists.freedesktop.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"Peilin Ye" <yepeilin.cs@gmail.com>,
	"Alex Deucher" <alexdeucher@gmail.com>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Evan Quan" <evan.quan@amd.com>, "Leo Liu" <leo.liu@amd.com>,
	"Christian Koenig" <christian.koenig@amd.com>,
	"Dan Carpenter" <dan.carpenter@oracle.com>,
	"Xiaojie Yuan" <xiaojie.yuan@amd.com>
Subject: Re: [Linux-kernel-mentees] [PATCH] drm/amdgpu: Prevent kernel-infoleak in amdgpu_info_ioctl()
Date: Fri, 31 Jul 2020 09:34:13 +0200	[thread overview]
Message-ID: <CAK8P3a2+Vv5=bKDR=NU8jcNgAoZRk+EKG11NU7bQSetyVDvn=w@mail.gmail.com> (raw)
In-Reply-To: <8c5cf518-12d2-7495-7822-c7ebf8e61972@amd.com>

On Thu, Jul 30, 2020 at 11:09 PM Luben Tuikov <luben.tuikov@amd.com> wrote:
> On 2020-07-29 9:49 a.m., Alex Deucher wrote:
> > On Wed, Jul 29, 2020 at 4:11 AM Christian König
> > <ckoenig.leichtzumerken@gmail.com> wrote:
> >>
> >> Am 28.07.20 um 21:29 schrieb Peilin Ye:
> >>> Compiler leaves a 4-byte hole near the end of `dev_info`, causing
> >>> amdgpu_info_ioctl() to copy uninitialized kernel stack memory to userspace
> >>> when `size` is greater than 356.
> >>>
> >>> In 2015 we tried to fix this issue by doing `= {};` on `dev_info`, which
> >>> unfortunately does not initialize that 4-byte hole. Fix it by using
> >>> memset() instead.
> >>>
> >>> Cc: stable@vger.kernel.org
> >>> Fixes: c193fa91b918 ("drm/amdgpu: information leak in amdgpu_info_ioctl()")
> >>> Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
> >>> Suggested-by: Dan Carpenter <dan.carpenter@oracle.com>
> >>> Signed-off-by: Peilin Ye <yepeilin.cs@gmail.com>
> >>
> >> Reviewed-by: Christian König <christian.koenig@amd.com>
> >>
> >> I can't count how many of those we have fixed over the years.
> >>
> >> At some point we should probably document that using "= {}" or "= { 0 }"
> >> in the kernel is a really bad idea and should be avoided.
> >
> > Moreover, it seems like different compilers seem to behave relatively
> > differently with these and we often get reports of warnings with these
> > on clang.  When in doubt, memset.
>
> There are quite a few of those under drivers/gpu/drm, for "amd/", "scheduler/"
> drm*.c files,
>
> $find . \( -regex "./drm.*\.c" -or -regex "./amd/.*\.c" -or -regex "./scheduler/.*\.c" \) -exec egrep -n -- " *= *{ *(|NULL|0) *}" \{\} \+ | wc -l
> 374
> $_
>
> Out of which only 16 are of the non-ISO C variety, "= {}",
>
> $find . \( -regex "./drm.*\.c" -or -regex "./amd/.*\.c" -or -regex "./scheduler/.*\.c" \) -exec egrep -n -- " *= *{ *}" \{\} \+ | wc -l
> 16
> $_

That is an unrelated issue, those were introduced to deal with older compilers
that do not accept '{0}' as an initializer for an aggregate whose
first member is
another aggregate. Generally speaking, '= { }' is better to use in the
kernel than
'= { 0 }' because all supported compilers interpret that the same way for all
structures.

     Arnd
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Luben Tuikov <luben.tuikov@amd.com>
Cc: "David Airlie" <airlied@linux.ie>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Felix Kuehling" <Felix.Kuehling@amd.com>,
	LKML <linux-kernel@vger.kernel.org>,
	"amd-gfx list" <amd-gfx@lists.freedesktop.org>,
	"Nicholas Kazlauskas" <nicholas.kazlauskas@amd.com>,
	"Marek Olšák" <marek.olsak@amd.com>,
	"Hans de Goede" <hdegoede@redhat.com>,
	linux-kernel-mentees@lists.linuxfoundation.org,
	Trek <trek00@inbox.ru>,
	"Maling list - DRI developers" <dri-devel@lists.freedesktop.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"Peilin Ye" <yepeilin.cs@gmail.com>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Evan Quan" <evan.quan@amd.com>, "Leo Liu" <leo.liu@amd.com>,
	"Christian Koenig" <christian.koenig@amd.com>,
	"Dan Carpenter" <dan.carpenter@oracle.com>,
	"Xiaojie Yuan" <xiaojie.yuan@amd.com>
Subject: Re: [Linux-kernel-mentees] [PATCH] drm/amdgpu: Prevent kernel-infoleak in amdgpu_info_ioctl()
Date: Fri, 31 Jul 2020 09:34:13 +0200	[thread overview]
Message-ID: <CAK8P3a2+Vv5=bKDR=NU8jcNgAoZRk+EKG11NU7bQSetyVDvn=w@mail.gmail.com> (raw)
In-Reply-To: <8c5cf518-12d2-7495-7822-c7ebf8e61972@amd.com>

On Thu, Jul 30, 2020 at 11:09 PM Luben Tuikov <luben.tuikov@amd.com> wrote:
> On 2020-07-29 9:49 a.m., Alex Deucher wrote:
> > On Wed, Jul 29, 2020 at 4:11 AM Christian König
> > <ckoenig.leichtzumerken@gmail.com> wrote:
> >>
> >> Am 28.07.20 um 21:29 schrieb Peilin Ye:
> >>> Compiler leaves a 4-byte hole near the end of `dev_info`, causing
> >>> amdgpu_info_ioctl() to copy uninitialized kernel stack memory to userspace
> >>> when `size` is greater than 356.
> >>>
> >>> In 2015 we tried to fix this issue by doing `= {};` on `dev_info`, which
> >>> unfortunately does not initialize that 4-byte hole. Fix it by using
> >>> memset() instead.
> >>>
> >>> Cc: stable@vger.kernel.org
> >>> Fixes: c193fa91b918 ("drm/amdgpu: information leak in amdgpu_info_ioctl()")
> >>> Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
> >>> Suggested-by: Dan Carpenter <dan.carpenter@oracle.com>
> >>> Signed-off-by: Peilin Ye <yepeilin.cs@gmail.com>
> >>
> >> Reviewed-by: Christian König <christian.koenig@amd.com>
> >>
> >> I can't count how many of those we have fixed over the years.
> >>
> >> At some point we should probably document that using "= {}" or "= { 0 }"
> >> in the kernel is a really bad idea and should be avoided.
> >
> > Moreover, it seems like different compilers seem to behave relatively
> > differently with these and we often get reports of warnings with these
> > on clang.  When in doubt, memset.
>
> There are quite a few of those under drivers/gpu/drm, for "amd/", "scheduler/"
> drm*.c files,
>
> $find . \( -regex "./drm.*\.c" -or -regex "./amd/.*\.c" -or -regex "./scheduler/.*\.c" \) -exec egrep -n -- " *= *{ *(|NULL|0) *}" \{\} \+ | wc -l
> 374
> $_
>
> Out of which only 16 are of the non-ISO C variety, "= {}",
>
> $find . \( -regex "./drm.*\.c" -or -regex "./amd/.*\.c" -or -regex "./scheduler/.*\.c" \) -exec egrep -n -- " *= *{ *}" \{\} \+ | wc -l
> 16
> $_

That is an unrelated issue, those were introduced to deal with older compilers
that do not accept '{0}' as an initializer for an aggregate whose
first member is
another aggregate. Generally speaking, '= { }' is better to use in the
kernel than
'= { 0 }' because all supported compilers interpret that the same way for all
structures.

     Arnd
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Luben Tuikov <luben.tuikov@amd.com>
Cc: "Daniel Vetter" <daniel@ffwll.ch>,
	"David Airlie" <airlied@linux.ie>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Felix Kuehling" <Felix.Kuehling@amd.com>,
	LKML <linux-kernel@vger.kernel.org>,
	"amd-gfx list" <amd-gfx@lists.freedesktop.org>,
	"Nicholas Kazlauskas" <nicholas.kazlauskas@amd.com>,
	"Marek Olšák" <marek.olsak@amd.com>,
	"Hans de Goede" <hdegoede@redhat.com>,
	linux-kernel-mentees@lists.linuxfoundation.org,
	Trek <trek00@inbox.ru>,
	"Maling list - DRI developers" <dri-devel@lists.freedesktop.org>,
	"Thomas Zimmermann" <tzimmermann@suse.de>,
	"Peilin Ye" <yepeilin.cs@gmail.com>,
	"Alex Deucher" <alexdeucher@gmail.com>,
	"Alex Deucher" <alexander.deucher@amd.com>,
	"Evan Quan" <evan.quan@amd.com>, "Leo Liu" <leo.liu@amd.com>,
	"Christian Koenig" <christian.koenig@amd.com>,
	"Dan Carpenter" <dan.carpenter@oracle.com>,
	"Xiaojie Yuan" <xiaojie.yuan@amd.com>
Subject: Re: [Linux-kernel-mentees] [PATCH] drm/amdgpu: Prevent kernel-infoleak in amdgpu_info_ioctl()
Date: Fri, 31 Jul 2020 09:34:13 +0200	[thread overview]
Message-ID: <CAK8P3a2+Vv5=bKDR=NU8jcNgAoZRk+EKG11NU7bQSetyVDvn=w@mail.gmail.com> (raw)
In-Reply-To: <8c5cf518-12d2-7495-7822-c7ebf8e61972@amd.com>

On Thu, Jul 30, 2020 at 11:09 PM Luben Tuikov <luben.tuikov@amd.com> wrote:
> On 2020-07-29 9:49 a.m., Alex Deucher wrote:
> > On Wed, Jul 29, 2020 at 4:11 AM Christian König
> > <ckoenig.leichtzumerken@gmail.com> wrote:
> >>
> >> Am 28.07.20 um 21:29 schrieb Peilin Ye:
> >>> Compiler leaves a 4-byte hole near the end of `dev_info`, causing
> >>> amdgpu_info_ioctl() to copy uninitialized kernel stack memory to userspace
> >>> when `size` is greater than 356.
> >>>
> >>> In 2015 we tried to fix this issue by doing `= {};` on `dev_info`, which
> >>> unfortunately does not initialize that 4-byte hole. Fix it by using
> >>> memset() instead.
> >>>
> >>> Cc: stable@vger.kernel.org
> >>> Fixes: c193fa91b918 ("drm/amdgpu: information leak in amdgpu_info_ioctl()")
> >>> Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)")
> >>> Suggested-by: Dan Carpenter <dan.carpenter@oracle.com>
> >>> Signed-off-by: Peilin Ye <yepeilin.cs@gmail.com>
> >>
> >> Reviewed-by: Christian König <christian.koenig@amd.com>
> >>
> >> I can't count how many of those we have fixed over the years.
> >>
> >> At some point we should probably document that using "= {}" or "= { 0 }"
> >> in the kernel is a really bad idea and should be avoided.
> >
> > Moreover, it seems like different compilers seem to behave relatively
> > differently with these and we often get reports of warnings with these
> > on clang.  When in doubt, memset.
>
> There are quite a few of those under drivers/gpu/drm, for "amd/", "scheduler/"
> drm*.c files,
>
> $find . \( -regex "./drm.*\.c" -or -regex "./amd/.*\.c" -or -regex "./scheduler/.*\.c" \) -exec egrep -n -- " *= *{ *(|NULL|0) *}" \{\} \+ | wc -l
> 374
> $_
>
> Out of which only 16 are of the non-ISO C variety, "= {}",
>
> $find . \( -regex "./drm.*\.c" -or -regex "./amd/.*\.c" -or -regex "./scheduler/.*\.c" \) -exec egrep -n -- " *= *{ *}" \{\} \+ | wc -l
> 16
> $_

That is an unrelated issue, those were introduced to deal with older compilers
that do not accept '{0}' as an initializer for an aggregate whose
first member is
another aggregate. Generally speaking, '= { }' is better to use in the
kernel than
'= { 0 }' because all supported compilers interpret that the same way for all
structures.

     Arnd
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

  parent reply	other threads:[~2020-07-31  7:34 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-28 19:29 [Linux-kernel-mentees] [PATCH] drm/amdgpu: Prevent kernel-infoleak in amdgpu_info_ioctl() Peilin Ye
2020-07-28 19:29 ` Peilin Ye
2020-07-28 19:29 ` Peilin Ye
2020-07-28 19:29 ` Peilin Ye
2020-07-29  8:11 ` Christian König
2020-07-29  8:11   ` Christian König
2020-07-29  8:11   ` Christian König
2020-07-29  8:11   ` Christian König
2020-07-29  9:00   ` Daniel Vetter
2020-07-29  9:00     ` Daniel Vetter
2020-07-29  9:00     ` Daniel Vetter
2020-07-29  9:00     ` Daniel Vetter
2020-07-29 13:49   ` Alex Deucher
2020-07-29 13:49     ` Alex Deucher
2020-07-29 13:49     ` Alex Deucher
2020-07-29 13:49     ` Alex Deucher
2020-07-30 21:09     ` Luben Tuikov
2020-07-30 21:09       ` Luben Tuikov
2020-07-30 21:09       ` Luben Tuikov
2020-07-30 21:09       ` Luben Tuikov
2020-07-31  6:53       ` Greg Kroah-Hartman
2020-07-31  6:53         ` Greg Kroah-Hartman
2020-07-31  6:53         ` Greg Kroah-Hartman
2020-07-31  6:53         ` Greg Kroah-Hartman
2020-07-31  6:57         ` Christian König
2020-07-31  6:57           ` Christian König
2020-07-31  6:57           ` Christian König
2020-07-31  6:57           ` Christian König
2020-07-31  7:10           ` Greg Kroah-Hartman
2020-07-31  7:10             ` Greg Kroah-Hartman
2020-07-31  7:10             ` Greg Kroah-Hartman
2020-07-31  7:10             ` Greg Kroah-Hartman
2020-07-31  7:57             ` Christian König
2020-07-31  7:57               ` Christian König
2020-07-31  7:57               ` Christian König
2020-07-31  7:57               ` Christian König
2020-07-31  7:34       ` Arnd Bergmann [this message]
2020-07-31  7:34         ` Arnd Bergmann
2020-07-31  7:34         ` Arnd Bergmann
2020-07-31  7:34         ` Arnd Bergmann
2020-07-29 21:55   ` Alex Deucher
2020-07-29 21:55     ` Alex Deucher
2020-07-29 21:55     ` Alex Deucher
2020-07-29 21:55     ` 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='CAK8P3a2+Vv5=bKDR=NU8jcNgAoZRk+EKG11NU7bQSetyVDvn=w@mail.gmail.com' \
    --to=arnd@arndb.de \
    --cc=Felix.Kuehling@amd.com \
    --cc=airlied@linux.ie \
    --cc=alexander.deucher@amd.com \
    --cc=alexdeucher@gmail.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=christian.koenig@amd.com \
    --cc=dan.carpenter@oracle.com \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=evan.quan@amd.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hdegoede@redhat.com \
    --cc=leo.liu@amd.com \
    --cc=linux-kernel-mentees@lists.linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luben.tuikov@amd.com \
    --cc=marek.olsak@amd.com \
    --cc=nicholas.kazlauskas@amd.com \
    --cc=trek00@inbox.ru \
    --cc=tzimmermann@suse.de \
    --cc=xiaojie.yuan@amd.com \
    --cc=yepeilin.cs@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.