linux-kernel - Re: [PATCH 3/4] USB: serial: ftdi

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] [day] [month] [year] [list]

Message-ID: <X9EL6SwjutCHTPO+@localhost>
Date:   Wed, 9 Dec 2020 18:39:53 +0100
From:   Johan Hovold <johan@...nel.org>
To:     Linus Walleij <linus.walleij@...aro.org>
Cc:     Johan Hovold <johan@...nel.org>, Marc Zyngier <maz@...nel.org>,
        linux-usb <linux-usb@...r.kernel.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        kernel-team@...roid.com
Subject: Re: [PATCH 3/4] USB: serial: ftdi_sio: Log the CBUS GPIO validity

On Wed, Dec 09, 2020 at 06:05:58PM +0100, Johan Hovold wrote:
> On Wed, Dec 09, 2020 at 10:35:53AM +0100, Linus Walleij wrote:

> > It sounds like we agree that this patch sans prints is acceptable.
> > 
> > It makes things better so let's go with that.
> 
> Sounds good.
> 
> I'm about to apply patches 2, 3 and 4 with some smaller changes like
> demoting the printk messages to KERN_DEBUG and dropping the ftx-progs
> warning.
>
> > The problem for the user is that the line looks to be
> > "used by the kernel" (true in some sense) but they have no
> > idea what to do about it and that the ftx-prog will solve
> > their hacking problem.
> 
> Right, it's not ideal, but the datasheets for these devices clearly
> states that the configuration of the CBUS pins is done in EEPROM and the
> vendor provides some tool to do that. Then there's a bunch of open
> source implementations for the same including ftx-progs (which can only
> be used for a subset of these devices).
> 
> I'd be fine with a dev_err() on the first request that fails saying that
> the CBUS pin is not configured for GPIO use (perhaps even on every
> request if its not something that a non-root user can trigger). But we
> cannot have both that and have the line marked in-use through the
> chardev interface currently.
> 
> I'm admittedly a bit torn on which is preferable.

I've applied the patches now. Having this reported through the chardev
interface must be better than having to match up a failed request with
something in the system log.

Johan