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]
Message-ID: <20200910080850.GD24441@localhost>
Date:   Thu, 10 Sep 2020 10:08:50 +0200
From:   Johan Hovold <johan@...nel.org>
To:     Lars Melin <larsm17@...il.com>
Cc:     Oliver Neukum <oneukum@...e.de>,
        James Hilliard <james.hilliard1@...il.com>,
        linux-usb@...r.kernel.org, Johan Hovold <johan@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        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: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.

Johan

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ