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

[James Hilliard]

On Thu, Sep 10, 2020 at 2:55 AM Greg Kroah-Hartman
<gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
>
> On Thu, Sep 10, 2020 at 02:17:44AM -0600, James Hilliard wrote:
> > On Thu, Sep 10, 2020 at 2:08 AM Johan Hovold <johan@xxxxxxxxxx> wrote:
> > >
> > > On Thu, Sep 10, 2020 at 12:33:55PM +0700, Lars Melin 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.
> > > >
> > > > The bricked PID is btw already supported by the linux ftdi driver so
> > > > there is no functionality gain in the patch.
> > >
> > > I fully agree. This doesn't belong in the kernel. If the Windows driver
> > > breaks someones device on purpose they should know about it, and *if*
> > > they want they can reprogram the device using the tools mentioned in the
> > > thread. But the kernel shouldn't be playing such games and reprogram
> > > eeproms behind people's backs.
> > One of the main issues is that this issue is very often not-obvious, FTDI
> > specifically designed their malicious driver to make it appear that the
> > hardware failed, they intentionally do not provide proper feedback to
> > the user when they soft-brick it. I assume this is because they want
> > to push the support costs related to their malicious driver onto the
> > integrator rather than themselves.
>
> That's fine, but why is it the Linux kernel's job to fix up this mess?
Well the kernel seems to be the place a fix would be most effective.
Not like it's unusual for the kernel to work around hardware issues in
general. :P
>
> There is already a userspace tool that can be run to resolve this for
> devices that wish to have this fixed up for.  Use that.  We want to keep
> things that can be done in userspace, in userspace, whenever possible.
So I'm having trouble coming up with a reliable way to fix this in userspace,
I've already got quite a few moving parts there as is and most of what I
come up with seems like it would not work reliably, at least for automatically
repairing the eeprom.
>
> And again, Linux runs just fine with these devices so why is it Linux's
>
> I'm with Johan here, reprogramming eeproms when people least expect it
> is not nice, and in a way, is much the same thing that the Windows
> drivers are doing.
Yeah, it does seem a bit sketchy at first, I went with this approach mostly
since I couldn't think of a practical scenario where fixing it automatically
would be a real issue, assuming we can reliably detect the preimage
attack.

So maybe identify the preimage attack and log a message instead? From
my understanding false positives should be nearly impossible with the
signature identification technique I'm using.

Maybe we could expose an interface that triggers the eeprom repair,
one which doesn't require userspace to implement low level USB handling?
>
> thanks,
>
> greg k-h