All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Fix a potential integer overflow with framebuffers extending past 4 GiB
Date: Wed, 12 Sep 2018 19:05:22 +0300	[thread overview]
Message-ID: <20180912160522.GA5565@intel.com> (raw)
In-Reply-To: <153673998714.32749.16800681844186338661@skylake-alporthouse-com>

On Wed, Sep 12, 2018 at 09:13:07AM +0100, Chris Wilson wrote:
> Quoting Ville Syrjala (2018-09-11 17:54:57)
> > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > 
> > If we have framebuffers that are >= 4GiB in size we will overflow
> > the fb size check in intel_fill_fb_info().
> > 
> > Currently that is only possible with NV12 and CCS as offsets[1]
> > may be anything between 0 and 0xffffffff. ofsets[0] is currently
> > required to be 0 so we can't hit the overflow with any single
> > plane format (thanks to max fb size of 8kx8k and max stride of
> > 32 KiB).
> > 
> > In the future we may allow almost any framebuffer to exceed 4GiB
> > in size so we really should fix the overflow. Not that the overflow
> > is particularly dangerous. It's mostly just a sanity check against
> > insane userspace. The display engine can't write to memory anyway
> > so I suppose in the worst case we might anger the hw by attempting
> > scanout past the end of the ggtt, or we might scan out some data
> > that we're not supposed to see from other parts of the ggtt.
> > 
> > Note that triggering this overflow depends on the driver
> > aligning the fb height to the next tile boundary to push the
> > calculated size above 4GiB. With linear buffers the effective
> > tile height is one so that never happens, and the core already
> > has a check for 32bit overflow of offsets[]+pitches[]*height.
> > 
> > Testcase: igt/kms_big_fb/x-tiled-addfb-size-offset-overflow
> > Testcase: igt/kms_big_fb/y-tiled-addfb-size-offset-overflow
> > Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 7 ++++---
> >  1 file changed, 4 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> > index 2b77d9350a3a..2b474d049074 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -2636,9 +2636,10 @@ intel_fill_fb_info(struct drm_i915_private *dev_priv,
> >                 max_size = max(max_size, offset + size);
> >         }
> >  
> > -       if (max_size * tile_size > obj->base.size) {
> > -               DRM_DEBUG_KMS("fb too big for bo (need %u bytes, have %zu bytes)\n",
> > -                             max_size * tile_size, obj->base.size);
> > +       if (mul_u32_u32(max_size, tile_size) > obj->base.size) {
> > +               DRM_DEBUG_KMS("fb too big for bo (need %llu bytes, have %zu bytes)\n",
> > +                             (unsigned long long) mul_u32_u32(max_size, tile_size),
> 
> mul_u32_u32 returns u64 i.e. unsigned long long; %llu is the one true
> format specifier for u64 (Linus decree #103789)

Well whaddyaknow, so it is. Never realized that for some reason.

> 
> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
> -Chris

-- 
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2018-09-12 16:05 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-11 16:54 [PATCH] drm/i915: Fix a potential integer overflow with framebuffers extending past 4 GiB Ville Syrjala
2018-09-11 17:23 ` ✗ Fi.CI.CHECKPATCH: warning for " Patchwork
2018-09-11 17:24 ` ✗ Fi.CI.SPARSE: " Patchwork
2018-09-11 17:40 ` ✓ Fi.CI.BAT: success " Patchwork
2018-09-11 22:06 ` ✓ Fi.CI.IGT: " Patchwork
2018-09-12  8:13 ` [PATCH] " Chris Wilson
2018-09-12 16:05   ` Ville Syrjälä [this message]
2018-09-12 18:04 ` [PATCH v2] " Ville Syrjala
2018-09-12 18:10 ` ✗ Fi.CI.SPARSE: warning for drm/i915: Fix a potential integer overflow with framebuffers extending past 4 GiB (rev2) Patchwork
2018-09-12 18:29 ` ✓ Fi.CI.BAT: success " Patchwork
2018-09-13  1:23 ` ✓ Fi.CI.IGT: " Patchwork

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=20180912160522.GA5565@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.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.