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 for Android: free password hash cracker in your pocket

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

Message-ID: <17A89C84-23A1-42DD-B541-F61BC7693560@marcansoft.com>
Date:   Thu, 10 Sep 2020 12:49:01 +0900
From:   "Hector Martin \"marcan\"" <hector@...cansoft.com>
To:     James Hilliard <james.hilliard1@...il.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 September 10, 2020 12:46:20 PM GMT+09:00, James Hilliard <james.hilliard1@...il.com> wrote:
>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.

Surely you can port the exact same algorithm to plain userspace C, as you did to kernel space C :)

>>
>> 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.

I'm not aware of any instances like this where nonvolatile memory is modified. At most you'll get things like resetting devices that a previous windows warm boot misconfigured, I think?

>>
>> >
>> >> +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

-- 
Hector Martin "marcan" (hector@...cansoft.com)
Public key: https://mrcn.st/pub