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:   Thu, 10 Sep 2020 02:01:39 -0600
From:   James Hilliard <james.hilliard1@...il.com>
To:     Lars Melin <larsm17@...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>,
        Hector Martin <hector@...cansoft.com>
Subject: Re: [PATCH v2] usb: serial: Repair FTDI FT232R bricked eeprom

On Thu, Sep 10, 2020 at 12:48 AM James Hilliard
<james.hilliard1@...il.com> wrote:
>
> On Wed, Sep 9, 2020 at 11:34 PM Lars Melin <larsm17@...il.com> wrote:
> >
> > On 9/10/2020 10:02, Oliver Neukum 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?
> > >
> >
> > My answer to both of those question is a strong NO.
> >
> > The patch author tries to justify the patch with egoistical arguments
> > (easier for him and his customers) without thinking of all other users
> > of memory constrained embedded hardware that doesn't need the patch code
> > but have to carry it.
> If that's a concern it would not be difficult to add a kconfig option to allow
> disabling it.
I should maybe add that the reason I'm trying to upstream this is because
I have been repeatedly bitten by this issue for years over many totally
unrelated projects, as have many people I know. If this was a one-off
issue I would not have spent the time writing a kernel patch to fix
it. The supply
chains must be heavily contaminated with counterfeits with how often I've
personally run into this problem.

The damage done by FTDI with their malicious drivers really is hard to quantify,
both in terms of wasted man hours working around this issue and in the
inevitable mountains of e-waste they create by bricking end user hardware.
Most of these customers have likely never even heard of FTDI, they even
intentionally designed their malicious drivers to make it non-obvious that
the failures are due to counterfeits, completely unethical behavior IMO.

FTDI may very well be one of the least environmentally friendly companies
in terms of environmental damage per dollar of revenue.
> >
> > The bricked PID is btw already supported by the linux ftdi driver so
> > there is no functionality gain in the patch.
> By the kernel driver sure, but userspace is where things get messed up
> without something like this.
> >
> > br
> > Lars
> >
> >
> >