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