[Intel-gfx] [PATCH 01/12] drm/edid: use struct edid * in drm_do_get_edid()
Ville Syrjälä
ville.syrjala at linux.intel.com
Wed Mar 30 16:50:29 UTC 2022
On Wed, Mar 30, 2022 at 07:28:56PM +0300, Jani Nikula wrote:
> On Wed, 30 Mar 2022, Ville Syrjälä <ville.syrjala at linux.intel.com> wrote:
> > On Wed, Mar 30, 2022 at 06:16:17PM +0300, Jani Nikula wrote:
> >> On Wed, 30 Mar 2022, Ville Syrjälä <ville.syrjala at linux.intel.com> wrote:
> >> > On Tue, Mar 29, 2022 at 09:42:08PM +0300, Jani Nikula wrote:
> >> >> Mixing u8 * and struct edid * is confusing, switch to the latter.
> >> >>
> >> >> Cc: Ville Syrjälä <ville.syrjala at linux.intel.com>
> >> >> Signed-off-by: Jani Nikula <jani.nikula at intel.com>
> >> >> ---
> >> >> drivers/gpu/drm/drm_edid.c | 31 +++++++++++++++----------------
> >> >> 1 file changed, 15 insertions(+), 16 deletions(-)
> >> >>
> >> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> >> >> index d79b06f7f34c..0650b9217aa2 100644
> >> >> --- a/drivers/gpu/drm/drm_edid.c
> >> >> +++ b/drivers/gpu/drm/drm_edid.c
> >> >> @@ -1991,29 +1991,28 @@ struct edid *drm_do_get_edid(struct drm_connector *connector,
> >> >> void *data)
> >> >> {
> >> >> int i, j = 0, valid_extensions = 0;
> >> >> - u8 *edid, *new;
> >> >> - struct edid *override;
> >> >> + struct edid *edid, *new, *override;
> >> >>
> >> >> override = drm_get_override_edid(connector);
> >> >> if (override)
> >> >> return override;
> >> >>
> >> >> - edid = (u8 *)drm_do_get_edid_base_block(connector, get_edid_block, data);
> >> >> + edid = drm_do_get_edid_base_block(connector, get_edid_block, data);
> >> >> if (!edid)
> >> >> return NULL;
> >> >>
> >> >> /* if there's no extensions or no connector, we're done */
> >> >> - valid_extensions = edid[0x7e];
> >> >> + valid_extensions = edid->extensions;
> >> >> if (valid_extensions == 0)
> >> >> - return (struct edid *)edid;
> >> >> + return edid;
> >> >>
> >> >> new = krealloc(edid, (valid_extensions + 1) * EDID_LENGTH, GFP_KERNEL);
> >> >> if (!new)
> >> >> goto out;
> >> >> edid = new;
> >> >>
> >> >> - for (j = 1; j <= edid[0x7e]; j++) {
> >> >> - u8 *block = edid + j * EDID_LENGTH;
> >> >> + for (j = 1; j <= edid->extensions; j++) {
> >> >> + void *block = edid + j;
> >> >>
> >> >> for (i = 0; i < 4; i++) {
> >> >> if (get_edid_block(data, block, j, EDID_LENGTH))
> >> >> @@ -2026,13 +2025,13 @@ struct edid *drm_do_get_edid(struct drm_connector *connector,
> >> >> valid_extensions--;
> >> >> }
> >> >>
> >> >> - if (valid_extensions != edid[0x7e]) {
> >> >> - u8 *base;
> >> >> + if (valid_extensions != edid->extensions) {
> >> >> + struct edid *base;
> >> >
> >> > This one points to extension blocks too so using
> >> > struct edid doesn't seem entirely appropriate.
> >>
> >> So I've gone back and forth with this. I think I want to get rid of u8*
> >> no matter what, because it always requires casting. I've used void* here
> >> and there to allow mixed use, internally in drm_edid.c while
> >> transitioning, and in public interfaces due to usage all over the place.
> >>
> >> OTOH I don't much like arithmetics on void*. It's a gcc extension.
> >>
> >> struct edid * is useful for e.g. ->checksum and arithmetics. In many
> >> places I've named it struct edid *block to distinguish. We could have a
> >> struct edid_block too, which could have ->tag and ->checksum members,
> >> for example, but then it would require casting or a function for "safe"
> >> typecasting.
> >>
> >> I've also gone back and forth with the helpers for getting a pointer to
> >> a block. For usage like this, kind of need both const and non-const
> >> versions. And, with the plans I have for future, I'm not sure I want to
> >> promote any EDID parsing outside of drm_edid.c, so maybe they should be
> >> static.
> >>
> >> Undecided. C is a bit clunky here.
> >>
> >> >
> >> >>
> >> >> - connector_bad_edid(connector, edid, edid[0x7e] + 1);
> >> >> + connector_bad_edid(connector, (u8 *)edid, edid->extensions + 1);
> >> >>
> >> >> - edid[EDID_LENGTH-1] += edid[0x7e] - valid_extensions;
> >> >> - edid[0x7e] = valid_extensions;
> >> >> + edid->checksum += edid->extensions - valid_extensions;
> >> >> + edid->extensions = valid_extensions;
> >> >>
> >> >> new = kmalloc_array(valid_extensions + 1, EDID_LENGTH,
> >> >> GFP_KERNEL);
> >> >> @@ -2040,21 +2039,21 @@ struct edid *drm_do_get_edid(struct drm_connector *connector,
> >> >> goto out;
> >> >>
> >> >> base = new;
> >> >> - for (i = 0; i <= edid[0x7e]; i++) {
> >> >> - u8 *block = edid + i * EDID_LENGTH;
> >> >> + for (i = 0; i <= edid->extensions; i++) {
> >> >> + void *block = edid + i;
> >> >
> >> > Hmm. This code seems very broken to me. We read each block
> >> > into its expected offset based on the original base block extension
> >> > count, but here we only iterate up to the new ext block count. So
> >> > if we had eg. a 4 block EDID where block 2 is busted, we set
> >> > the new ext count to 2, copy over blocks 0 and 1, skip block 2,
> >> > and then terminate the loop. So instead of copying block 3 from
> >> > the orignal EDID into block 2 of the new EDID, we leave the
> >> > original garbage block 2 in place.
> >>
> >> Ugh. I end up fixing this in the series, in "drm/edid: split out invalid
> >> block filtering to a separate function", but I don't mention it
> >> anywhere.
> >>
> >> Looks like it's been broken for 5+ years since commit 14544d0937bf
> >> ("drm/edid: Only print the bad edid when aborting").
> >>
> >> Which really makes you wonder about the usefulness of trying to "fix"
> >> the EDID by skipping extension blocks. It was added in commit
> >> 0ea75e23356f ("DRM: ignore invalid EDID extensions").
> >>
> >> > Also this memcpy() business seems entirely poinless in the sense
> >> > that we could just read each ext block into the final offset
> >> > directly AFAICS.
> >>
> >> This is how it was before commit 14544d0937bf.
> >
> > Hmm. This is actually even a bit worse than I though since it
> > looks like we can leak uninitialized stuff from kmalloc_array().
> > I originally thought it was a krealloc()+memmove() but that is
> > not the case.
> >
> >> I guess the point is if
> >> we decide the EDID is garbage, we want to print the original EDID, once,
> >> not something we've already changed. I also kind of like the idea of
> >> hiding the broken EDID path magic in a separate function.
> >
> > I'm wondering we should just stop with this bad block filtering
> > entirely? Just let the block be all zeroes/crap if that is really
> > what we got from the sink. And we could still skip known broken
> > blocks during parsing to avoid getting too confused I guess.
>
> I think by far the most common extension count must be 1. Especially
> with older displays I think anything beyond 256 bytes is virtually
> non-existent. Agreed?
More than one extension block is certainly pretty rare.
edid-decode has a few with 3 (base + CTA + DispID), and my
edid.tv dump seems to have two with 4 blocks (one has base +
CTA + 2 DispID blocks, the other has base + block map +
2 CTA blocks).
>
> With that, going from 1 to 0 extensions, it actually works by
> coincidence, no leaks, no uninitialized stuff. (Looks like maybe any
> scenario where it's the last N extensions that are invalid works just
> fine, and it's the broken extensions in the middle that make this go
> haywire.)
>
> So maybe it's not so scary after all. I could fix that bit first, and
> then proceed with the rest of the series.
I'd fix this up front so we don't end having to backport the whole
thing if/when some security scan gizmo stumbles on this.
> I'm a bit hesitant to make big
> functional changes now, like stopping the filtering entirely, because
> it's not just drm_edid.c parsing the returned EDIDs, parsing is all over
> the place.
Sure. Just threw it out there as a future idea.
> And on that note, my idea (also for HF-EEODB, my end goal) is to move
> towards an opaque struct drm_edid, which is 1) generated and parsed
> exclusively within drm_edid.c, nowhere else, 2) always valid to be
> passed to drm_edid.c (i.e. always be able to handle what we've
> generated, whatever that is). If you want the benefits of HF-EEODB or
> new DisplayID 2.0 features or whatever, you switch your driver to struct
> drm_edid. But you can keep rolling with the legacy struct edid crap ad
> infinitum.
Hopefully we can shame enough people to fix their stuff eventually :P
But yeah, trying to fix it all right now is a bit much.
--
Ville Syrjälä
Intel
More information about the Intel-gfx
mailing list