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: <X/cn3N4yk+A66pX0@kroah.com>
Date:   Thu, 7 Jan 2021 16:25:16 +0100
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Mychaela Falconia <mychaela.falconia@...il.com>
Cc:     Johan Hovold <johan@...nel.org>,
        Maarten Brock <m.brock@...mierlo.com>,
        Jiri Slaby <jirislaby@...nel.org>,
        "Mychaela N . Falconia" <falcon@...ecalypso.org>,
        linux-serial@...r.kernel.org, linux-usb@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 0/7] tty: add flag to suppress ready signalling on open

On Fri, Dec 18, 2020 at 10:03:59AM -0800, Mychaela Falconia wrote:
> Greg K-H wrote:
> 
> > We see devices that are "obviously" not the real vid/pid all the time in
> > the wild.  There's nothing "illegal" about another company using your
> > vid/pid, look at all of the ones out there already that use the FTDI
> > vendor id yet are "clones", same with pl2303 devices.
> 
> But are those reusers of someone else's VID or PID coming to Linux
> kernel maintainers with requests to modify ftdi_sio or pl2303 drivers
> to work with their clones?  Do you ever see LKML posts along the lines
> of "Hi, I am so and so from such and such company, we are not FTDI but
> we reuse FTDI's VID and PIDs, but our clone chip does not match the
> original and we need to modify the ftdi_sio driver to work with our
> poor man's clone chip" - do reusers of someone else's VID or PID come
> here with such requests?

Users of devices with cloned ids come to us asking why their devices do
not work on Linux and how to fix them.  Happens all the time, and as the
job of a kernel is to enable hardware, we work to make this happen.

The vendors who do this are no where to be found, of course, and telling
people that the device they just purchased is "counterfit" doesn't
really fall in our job description.  We have all sorts of work-arounds
in Linux drivers to support "fake" devices, our job is to make Linux
work for everyone.

Anyway, this is far off-topic for this thread, sorry, just letting you
know why trying to rely on vid/pid is not the "final solution" people
might think it is.

I wish someone else would have weighed in on the different api options
here, oh well, let me think about this over the next week or so...

thanks,

greg k-h

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ