Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp917382pxk; Thu, 10 Sep 2020 01:59:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwKjdEZaceh/CJJrz41cGZ/0Tah4qigBgTL8rlpmo6JTdivEUYa1P0spV43NjPdI+a4BhiG X-Received: by 2002:a50:c019:: with SMTP id r25mr8422382edb.285.1599728350597; Thu, 10 Sep 2020 01:59:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1599728350; cv=none; d=google.com; s=arc-20160816; b=AOyPOw8h8r6ueitufa89lpqjJv3/mFDhul402CBvNNEnEzeCJhdvP4vqxsj+EGRppN vBYz3bh7sPO+j/bwHPLGeR4BfwWkoD4ThO7z/9CfELYldDlgKJWohz31T8TYLxj6sr5V q6ogm+ItqLigmrx8NRr+cxJHRkxe36Edh6/wWwgvnR5TuWSGwQg1zv7qs7IwZGbogOlN TtP7dyDMqFk5y2gdMBEjbzihd73IBjxcG7oXUWyNCTtpKNldqfRrXnKjCQo6etO9b5f9 fofCwdNuzXtuRBmD/DckqvV3v9AW/ZnPh9DIcOuCw1s1fq7YFKj3cUdLYZRse3CaOskK feMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=bxTT8JicJ0kYZbqhF3QDJi6lgx9doAGQA1fpY6AqWFA=; b=pEWBEORN8ix/NSf4FINmKvvaAIhA0kwKUCgszBJYgyQhtltztmUUeMkTiTGoky/b7/ ZCSNsskFnxZiEC1DpvydZPi8GM/ncivy3TXqXhSvqTtsa91Bnfy5KCUXDKiJZWPZufqh LnjXfeJDHjxPbEoysmY6y9A0PgwsslxQYjj8HqtpvhGnF9frxZflU67WTiyYdwRi7XyO YmGDExmlSAhQRQidoXP5Fos42JCFQ71rgqx7kJPU6UYVjEwcFCh1Aamu7n2Bp1KWqccA He+tA9Ts4SeDHwD0GZPugQY9S2JoCs7Ux9VxUGAZAAJ+ytz6NkkKFSH3oDTHAdsLfQa4 ge/w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=VaYGy1DG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p4si3026393ejj.664.2020.09.10.01.58.47; Thu, 10 Sep 2020 01:59:10 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=VaYGy1DG; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730211AbgIJI5D (ORCPT + 99 others); Thu, 10 Sep 2020 04:57:03 -0400 Received: from mail.kernel.org ([198.145.29.99]:37058 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730400AbgIJIze (ORCPT ); Thu, 10 Sep 2020 04:55:34 -0400 Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 5DA2D206A1; Thu, 10 Sep 2020 08:55:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599728134; bh=Sw3cSgiiRVB7WjdtgUzZk4fAw77GoTjxM0/fy6CX2UQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=VaYGy1DGNz7YN5SG68MnqqzLWdNriwbjMQ5P5LsPml47jMyrueTtPJK9N4uvEJKvL nlDlIV9BHCB629AE3/7hHlSrrgov2Z+N4dr2ZS5/gZ1ZPZrtHthGSvJLhMUKQOuOJw J9az9zqi3guXQPR7Oh/HlzGZzv+FCRNKi24CcDWY= Date: Thu, 10 Sep 2020 10:55:41 +0200 From: Greg Kroah-Hartman To: James Hilliard Cc: Johan Hovold , Lars Melin , Oliver Neukum , linux-usb@vger.kernel.org, Linux Kernel Mailing List , Russ Dill , Hector Martin Subject: Re: [PATCH v2] usb: serial: Repair FTDI FT232R bricked eeprom Message-ID: <20200910085541.GA1099591@kroah.com> References: <20200909193419.2006744-1-james.hilliard1@gmail.com> <1599706954.10822.3.camel@suse.de> <20200910080850.GD24441@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 10, 2020 at 02:17:44AM -0600, James Hilliard wrote: > On Thu, Sep 10, 2020 at 2:08 AM Johan Hovold 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? 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. 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. thanks, greg k-h