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]

Date:   Wed, 9 Sep 2020 22:39:56 -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:49 PM Hector Martin "marcan"
<hector@...cansoft.com> wrote:
>
>
>
> 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 :)
Sure, but it would be significantly more complex, require a lot more code
and testing since there can be other userspace apps interacting with the
hardware, in addition to being less reliable and potentially difficult
to install
for some setups. Detecting and dealing with this issue in the kernel is
very simple and reliable in comparison. There's also potentially permissions
issues if one wants to do this from userspace from my understanding.
>
> >>
> >> 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?
Yeah, I think it's mostly nonvolatile memory, I've seen this issue quite a bit
with some of the Realtek ethernet drivers.

I think user experience for devices should be that one can move
a USB device from Linux to Windows and back without having to manually
reprogram an eeprom. The sheer amount of resources FTDI has wasted
with their malicious Windows driver is crazy and likely far exceeds any losses
from counterfeiting. I think due to how widespread this issue is it makes sense
to aggressively and automatically mitigate the damages wherever possible, it's
also likely a major source of ewaste since people may throw out perfectly
functional hardware without knowing it can be fixed easily.
>
> >>
> >> >
> >> >> +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