linux-kernel - Re: [PATCH v2] usb: serial: Repair FTDI FT232R bricked eeprom

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]

Date:   Wed, 9 Sep 2020 21:46:20 -0600
From:   James Hilliard <james.hilliard1@...il.com>
To:     Hector Martin marcan <hector@...cansoft.com>
Cc:     Oliver Neukum <oneukum@...e.de>, linux-usb@...r.kernel.org,
        Johan Hovold <johan@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Russ Dill <Russ.Dill@...il.com>
Subject: Re: [PATCH v2] usb: serial: Repair FTDI FT232R bricked eeprom

On Wed, Sep 9, 2020 at 9:17 PM Hector Martin "marcan"
<hector@...cansoft.com> wrote:
>
>
>
> On September 10, 2020 12:02:34 PM GMT+09:00, Oliver Neukum <oneukum@...e.de> wrote:
> >Am Mittwoch, den 09.09.2020, 13:34 -0600 schrieb James Hilliard:
> >> This patch detects and reverses the effects of the malicious FTDI
> >> Windows driver version 2.12.00(FTDIgate).
> >
> >Hi,
> >
> >this raises questions.
> >Should we do this unconditionally without asking?
> >Does this belong into kernel space?
>
> I agree; this is very cute, but does it really need to be an automatic Linux feature? Presumably someone looking to fix a bricked FTDI chip can just run my script, and those who just want to use those chips with Linux already can since the driver binds to the zero PID.
Well for one your script is not easily useable with embedded platforms
like mine where I ran into this issue, I have no python2 interpreter
available in my production builds.
>
> I am deeply amused by the idea of Linux automatically fixing problems caused by malicious Windows drivers, but thinking objectively, I'm not sure if that's the right thing to do.
>From my understanding Linux fixing up hardware issues caused
by faulty/weird Windows drivers isn't exactly unusual.
>
> >
> >> +static int ftdi_repair_brick(struct usb_serial_port *port)
> >> +{
> >> +    struct ftdi_private *priv = usb_get_serial_port_data(port);
> >> +    int orig_latency;
> >> +    int rv;
> >> +    u16 *eeprom_data;
> >> +    u16 checksum;
> >> +    int eeprom_size;
> >> +    int result;
> >> +
> >> +    switch (priv->chip_type) {
> >> +    case FT232RL:
> >> +            eeprom_size = 0x40;
> >> +            break;
> >> +    default:
> >> +            /* Unsupported for brick repair */
> >> +            return 0;
> >> +    }
> >> +
> >> +    /* Latency timer needs to be 0x77 to unlock EEPROM programming */
> >> +    if (priv->latency != 0x77) {
> >> +            orig_latency = priv->latency;
> >> +            priv->latency = 0x77;
> >> +            rv = write_latency_timer(port);
> >> +            priv->latency = orig_latency;
> >> +            if (rv < 0)
> >> +                    return -EIO;
> >> +    }
> >
> >Do you really want to change this without returning to the original?
> >
> >       Regards
> >               Oliver
>
> --
> Hector Martin "marcan" (hector@...cansoft.com)
> Public key: https://mrcn.st/pub