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:   Thu, 10 Sep 2020 12:17:13 +0900
From:   "Hector Martin \"marcan\"" <hector@...cansoft.com>
To:     Oliver Neukum <oneukum@...e.de>,
        James Hilliard <james.hilliard1@...il.com>,
        linux-usb@...r.kernel.org
CC:     Johan Hovold <johan@...nel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel@...r.kernel.org, Russ Dill <Russ.Dill@...il.com>
Subject: Re: [PATCH v2] usb: serial: Repair FTDI FT232R bricked eeprom



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.

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.

>
>> +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