linux-kernel - Re: [PATCH v2] drm/bridge: dw-hdmi: Refuse DDC/CI transfers on the internal I2C controller

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190722205419.GY250418@google.com>
Date:   Mon, 22 Jul 2019 13:54:19 -0700
From:   Matthias Kaehlcke <mka@...omium.org>
To:     Doug Anderson <dianders@...omium.org>
Cc:     Andrzej Hajda <a.hajda@...sung.com>,
        Laurent Pinchart <Laurent.pinchart@...asonboard.com>,
        David Airlie <airlied@...ux.ie>,
        Daniel Vetter <daniel@...ll.ch>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Jose Abreu <Jose.Abreu@...opsys.com>,
        Neil Armstrong <narmstrong@...libre.com>,
        Adam Jackson <ajax@...hat.com>
Subject: Re: [PATCH v2] drm/bridge: dw-hdmi: Refuse DDC/CI transfers on the
 internal I2C controller

On Mon, Jul 22, 2019 at 01:12:40PM -0700, Doug Anderson wrote:
> Hi,
> 
> On Mon, Jul 22, 2019 at 11:19 AM Matthias Kaehlcke <mka@...omium.org> wrote:
> >
> > The DDC/CI protocol involves sending a multi-byte request to the
> > display via I2C, which is typically followed by a multi-byte
> > response. The internal I2C controller only allows single byte
> > reads/writes or reads of 8 sequential bytes, hence DDC/CI is not
> > supported when the internal I2C controller is used. The I2C
> > transfers complete without errors, however the data in the response
> > is garbage. Abort transfers to/from slave address 0x37 (DDC) with
> > -EOPNOTSUPP, to make it evident that the communication is failing.
> >
> > Signed-off-by: Matthias Kaehlcke <mka@...omium.org>
> > ---
> > Changes in v2:
> > - changed DDC_I2C_ADDR to DDC_CI_ADDR
> > ---
> >  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 8 ++++++++
> >  1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > index 045b1b13fd0e..28933629f3c7 100644
> > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
> > @@ -35,6 +35,7 @@
> >
> >  #include <media/cec-notifier.h>
> >
> > +#define DDC_CI_ADDR            0x37
> >  #define DDC_SEGMENT_ADDR       0x30
> >
> >  #define HDMI_EDID_LEN          512
> > @@ -322,6 +323,13 @@ static int dw_hdmi_i2c_xfer(struct i2c_adapter *adap,
> >         u8 addr = msgs[0].addr;
> >         int i, ret = 0;
> >
> > +       if (addr == DDC_CI_ADDR)
> > +               /*
> > +                * The internal I2C controller does not support the multi-byte
> > +                * read and write operations needed for DDC/CI.
> > +                */
> > +               return -EOPNOTSUPP;
> > +
> 
> In theory we could also solve this by detecting (in other parts of the
> function) the bad multi-byte read/write operations.  That would maybe
> be more generic (AKA it would more properly handle random userspace
> tools fiddling with i2c-dev) but add complexity to the code.

But how do you know it's an unsupported operation, and not the driver
knowing the wacky limitations doing something valid.

E.g. you get the sequence:

0x01 0x0a 0x0b 0x0c 0x0d

This could be interpreted as "send the above bytes to the slave" or
as "send 0x0a to address 0x01, 0x0b to 0x02, 0x0c to 0x03 and 0x0d to
0x04" (at least by this driver ;-) . The latter could be intended.

> ...possibly a better long-term solution is to just totally stop
> emulating a regular i2c adapter when the hardware just doesn't support
> that.  In theory we could remove the "drm_get_edid()" call in
> dw_hdmi_connector_get_modes() and replace it with a direct call to
> drm_do_get_edid() if we're using the built-in adapter.  Possibly
> "tda998x_drv.c" would be a good reference.  If we did that, we could
> remove all the weird / hacky i2c code in this driver.

yes, that would be another and probably better option than trying to
detect unsupported transaction.

> Since the bigger cleanup seems like a bit much to ask, I'm OK with
> this as a stopgap to at least prevent userspace tools from getting
> confused.  Thus:
> 
> Reviewed-by: Douglas Anderson <dianders@...omium.org>

Thanks!