[BRLTTY] [PATCH] don't steal abused USB ids

Tue May 15 16:53:11 EDT 2018

Dave Mielke wrote:
> [quoted lines by Stanislav Brabec on 2018/05/14 at 21:26 +0200]
> 
>>> Mightn't it be possible, if not fairly probable, that a system with a lot of 
>>> those devices already connected to it is being reinstalled? I suppose, though, 
>>> that what you mean is that it'd be okay to assume a braille device since those 
>>> other devices, even if connected, wouldn't be useful when installing.
>>
>> System is installed: We can assume Braille device. We can live with
>> non-Braille UART devices being not responding, at least for initial
>> stage of installation. (The risk still exists, but it is pretty low, for
>> example those serial UPSes with one character commands that can shut
>> down the system immediately.)
> 
> I hope that's true. I'm very uncomfortable with serial probing when we really 
> have no idea regarding what the device actually is.

Me too. But probers actually exist on serial devices. Such probers test e. g. AT protocol support and do AT inquiry.

>> System is upgraded: Braille device is already configured, and no
>> additional detection is needed 
> 
> Assuming that it being a braille device during the install was somehow properly 
> verified by the installer itself.

Yes.

>> (with exception of the introduction of new rules).
> 
> And this can't be written off quite so easily. Let's say that I let my sighted 
> friend borrow my computer to do the install at his place. Then he brings it 
> back to me on his way somewhere else and doesn't have any extra time to hang 
> around. Now I need to get my braille device up and running with no sighted 
> assistance. This is a very probable scenario, and there are others.

When the new rules will be introduced, one-time breakage could happen.

In case of SUSE and openSUSE, some type of upgrade that makes problem to poorly made Braille USB devices will happen nearly for sure. In the current state, brltty makes USB serial devices completely broken.
https://bugzilla.opensuse.org/show_bug.cgi?id=1092839

I am not sure, how to reduce harm to owners of these devices on upgrade.
But once the upgrade happens, then new smart rules can solve the problem forever.

Well made USB Braille devices will not be affected.

> Note, also, that even if a sighted person is around, it may well be that that 
> person has no technical computer skills. So, even if sighted assistance is 
> available, that doesn't mean that it's all that helpful.

Problem already appears. Person with no technical skills is unable to use USB serial devices that are not Braille devices.

>>> I assume you mean that the installer would use the rules that include all of 
>>> the devices (not just the non-generic ones).
>>
>> Yes. But in case of well made Braille devices, you know that for sure.
>> No need for guesses, no need for detection nor questions.
> 
> I can't afford to have that perspective. We provide software without having any 
> knowledge of the zillions of ways how and environments within which it's used. 
> In other words, we need to code for the worst case, which, in this case, means 
> a poorly designed USB braille device, a poorly designed other kind of device 
> which looks like it might be a braille device, etc.

Well made USB devices: They have unique USB id. You know that they are Braille devices, and no problem appears.

Poorly made devices:

Installer can suppose, that unidentified devices (USB serial or old-style serial) are Braille device, and then prepare correct configuration files.

On the installed system, we cannot suppose that unidentified devices are Braille devices, as it breaks support of wide range of peripherals.

>>> Would it be sufficient if the number is high enough to be after the rules for 
>>> the other devices? We currently recommend 90. I don't know if distributions are 
>>> using it or picking their own number. I also don't know if 90 is high enough.
>>
>> As long as there is no conflicting rule, numbers don't really matter.
> 
> But I'm assuming that this discussion is taking place because there must be 
> conflicting rules.
> 
>> Most hardware devices use 65 to 90.
> 
> Should we increase our number to, say, 95?

95 defines default rules, even higher numbers a fallback.

But in our case, priority change is not a solution, as each rule attempts to handle different device. If you don't know, which of 5 device types was connected, it will always break for 80% of devices.

We need to go in a different way: Disable all rules for special USB serial devices, and then perform selective user-assisted enabling.

>>> This would be a problem because a braille user wouldn't be able to read the 
>>> prompt until his braille device is working.
>>
>> Well, it would be no problem:
> 
> Really? I completely disagree.
> 
>> If a generic serial USB device that can be Braille device appears, send
>> the prompt to the visual console and all generic USB serial devices, and
>> read a response from visual console and all generic USB serial devices.
> 
> And how, exactly, would we write the prompt to, and read the response from, a 
> braille device? They use complex protocols, and it's different for each model. 
> Just because it's using a generic serial adapter doesn't mean that 
> communicating with it as anywhere near as simple as merely writing/reading 
> characters.

I don't know details of these devices, but if such problem exists, then brltty already has to solve that problem. And if these devices work now, brltty has a solution. Looking at rules, 10C4:EA60 and 0403:6001 are already abused by more Braille devices, and you are able to discriminate the protocol somehow.

So if brltty is able to handle 10C4:EA60 and 0403:6001 USB devices out of the box, then installer could ask Braille users without any configuration.

>>> Yes. As mentioned above, I don't like serial probing.
>>
>> Me too. But serial probing is still better than random sending of serial
>> data.
> 
> Which is exactly what a textual prompt would look like to a braille device - 
> entirely random data.

I mean textual prompt using brltty driver.

Just assume during the early installation, that all FT232 and CP210x devices are Braille devices.

If the Braille device itself has no inquiry, then "human assisted probe" is the best we can do. If it has an inquiry and brltty can discriminate the Braille device, then utility e. g. brltty-probe can easily return specific error code meaning "Not a Braille device". (It can return 3 codes: yes, no, maybe; maybe = ask user.)

Currently, openSUSE brltty udev rules assume that all FT232 and CP210x devices are Braille devices, and it does not work.

>>> How would a user specify the port, and how would we find out which port the 
>>> device is on?
>>
>> Kernel has some support, see "lsusb -t". But it seems that udev
>> currently cannot create rules "USB device with id A:B connected to
>> leftmost rear port.
> 
> I don't think it'd be possible since ports are laid out in many different 
> physical ways, and those ports can be connected to the motherboard in different 
> ways, too. There are no standards for mapping physical placement to software 
> references.

Yes, you are true, Linux distros don't contain port layout maps. But in our case, we only need a way to recognize particular USB port across reboots. That is possible, but currently not yet supported by udev.

My intention is simple: Braille user connects the device to a particular port. Linux will know, that this particular port should be used by brltty, but devices with the same USB id connected to other ports should not be passed to brltty.

If something like this could be implemented, Braille users can use GPSes, AVR programmers and Arduinos, even if these devices have the same USB id.

> Let's consider my own computer as an example. It has two ports, side-by-side, 
> near the top. About half way down it has four ports in a "square". At the 
> bottom it has four ports in a row. And that's only the back. On the front it 
> has a plate with two USB ports, along with a microphone and a speaker port. Up 
> near the top is another plate with four more, along with card slots of various 
> types.

As long as "lsusb -t" numbers these ports consistently across reboots, suggested method can work.

>>> This is a device that brltty creates with uinput. How can we create it 
>>> differently so that it won't cause a problem?
>>
>> Confirming. After commenting out udev rules AND killing of brltty
>> daemon, GPS can be used again.
> 
> That doesn't help me. In fact, I don't even understand why that device causes 
> any problems. It's a uinput-created device that emulates a keyboard. Maybe, in 
> that case, Linux is creating something like a USB HID interface to it, but 
> that's well beyond our control. We write input events to it, and have no need 
> for USB access.

Probably something unregisters the serial device. Maybe ioctl(, USBDEVFS_CONTROL,), or even a race condition with other fighting processes.

Actually, system log says, that more applications are fighting to get control over 10c4:ea60 USB device. Bad race conditions can happen.

I created an openSUSE bug covering more:
https://bugzilla.opensuse.org/show_bug.cgi?id=1093378

>> Some daemons use udev helpers to notify new matching devices, so the
>> detection is implemented only once, by udev.
> 
> But I wouldn't even know what it's matching since, when we create it, we aren't 
> able to supply any USB data.

There is no need for such changes. You already have udev helper that starts the brltty daemon on demand. So there is no need to monitor devices. You can simply handle a single device passed by udev and quit when the device disappears. Now the device disappears, and the daemon still runs. When it re-appears, udev calls brltty_usb_run, but brltty also scans for the device (even if the udev rule is disabled).

-- 
Best Regards / S pozdravem,

Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o.                         e-mail: sbrabec at suse.com
Křižíkova 148/34 (Corso IIa)                  tel: +49 911 7405384547
186 00 Praha 8-Karlín                          fax:  +420 284 084 001
Czech Republic                                    http://www.suse.cz/
PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76