USB Sees Many Changes For Linux 3.18 Kernel

[phoronix]

Phoronix: USB Sees Many Changes For Linux 3.18 Kernel

Many USB subsystem changes are present for this newly-started Linux kernel merge window...

http://www.phoronix.com/vr.php?view=MTgwNzM

[grndzro]

I got a feeling 3.18 will be huge.

[Junix]

Everytime I read about USB changes I hope that they have fixed the USB 3.0/xhci ath3k Bluetooth bugs, but again doesn't look like so... :'(

[uid313]

But nothing can be done about Bad USB?

Cant the kernel raise a warning or intercept USB Device Firmware Upgrade (SFU) commands?

Cant the kernel raise a warning when a USB device registers itself as more than one USB device class?

Cant the kernel raise a warning when a USB device tries to change its USB device class?
Example you plugin a flash drive, that first identifies as a USB mass storage device, then later tries to switch to a USB human input device.

[Lekensteyn]

But nothing can be done about Bad USB?

Cant the kernel raise a warning or intercept USB Device Firmware Upgrade (SFU) commands?

Cant the kernel raise a warning when a USB device registers itself as more than one USB device class?

Cant the kernel raise a warning when a USB device tries to change its USB device class?
Example you plugin a flash drive, that first identifies as a USB mass storage device, then later tries to switch to a USB human input device.

The kernel already prints the USB device type when a new one gets inserted (kernel config option).

Changing device class is a feature. I got a HP laserprinter which first advertises itself as storage device ("Driver CD") which can be changed to a printer devices. See also the usb_modeswitch program.

As for counter measures, you could use udev to block devices which you do not trust (see this Security.SE post). The infrastructure is already in place, but you need to enable it yourself. Most people would feel annoyed when they insert a keyboard and then need to edit some file to enable it (without having a different input device..)

[uid313]

The kernel already prints the USB device type when a new one gets inserted (kernel config option).

Changing device class is a feature. I got a HP laserprinter which first advertises itself as storage device ("Driver CD") which can be changed to a printer devices. See also the usb_modeswitch program.

As for counter measures, you could use udev to block devices which you do not trust (see this Security.SE post). The infrastructure is already in place, but you need to enable it yourself. Most people would feel annoyed when they insert a keyboard and then need to edit some file to enable it (without having a different input device..)

I see.
Yes, switching USB device class is a feature. But it could be a feature that is intercepted and required authorization.
Like "The USB device is attempting to change its device class. Allow or deny?"

Also if you plugged in a USB human input device and there were no existing HID connected then it would allow it without authorization since you do not have any input to accept/deny.

However, if you plugged in a USB human input device and you already had a HID device connected (mouse or keyboard) then it would it would say "Do you want to authorize this human input device. Allow or deny?". Then you could chose deny if it was a printer or camera or a storage device.

[Lekensteyn]

I see.
Yes, switching USB device class is a feature. But it could be a feature that is intercepted and required authorization.
Like "The USB device is attempting to change its device class. Allow or deny?"

Devices will probably just run into a timeout and assume that the host is broken.

Also if you plugged in a USB human input device and there were no existing HID connected then it would allow it without authorization since you do not have any input to accept/deny.

What if a USB receiver is already attached, but has no nearby device? Then you need to remove that first before inserting a new one.

However, if you plugged in a USB human input device and you already had a HID device connected (mouse or keyboard) then it would it would say "Do you want to authorize this human input device. Allow or deny?". Then you could chose deny if it was a printer or camera or a storage device.

This could work, reject at first but then reset the device when access is granted.

[steveriley]

How many here run the various rc kernel releases on a regular basis? Usually I wait until the finished product is available. But if the rc's are of decent enough quality, it seems reasonble not to wait until the shipped version. Thoughts?

[uid313]

How many here run the various rc kernel releases on a regular basis? Usually I wait until the finished product is available. But if the rc's are of decent enough quality, it seems reasonble not to wait until the shipped version. Thoughts?

Well, it depends on.
If you're geeky and experimental and want to live on the bleeding edge and know how to fix your system, have backups and know how to report bugs and want to help out testing, then sure go for the release candidates.
But if you're running a production system, or don't know how to report stuff, or fix stuff, or don't keep have backups and do serious work on your computer then stay with the stable versions.

Back in the days when I was a kid, I used to run the release candidates, also the daily versions.
It was fun and I experimented with different kernel configurations and learned a lot.
But now that I am an adult, and have a job, and less time, and is less eager to experiment and learn, I don't use release candidates anymore. These days its more important with a stable and reliable system.

[steveriley]

Well, it depends on.
If you're geeky and experimental and want to live on the bleeding edge and know how to fix your system, have backups and know how to report bugs and want to help out testing, then sure go for the release candidates.
But if you're running a production system, or don't know how to report stuff, or fix stuff, or don't keep have backups and do serious work on your computer then stay with the stable versions.

Back in the days when I was a kid, I used to run the release candidates, also the daily versions.
It was fun and I experimented with different kernel configurations and learned a lot.
But now that I am an adult, and have a job, and less time, and is less eager to experiment and learn, I don't use release candidates anymore. These days its more important with a stable and reliable system.

I am all of these things: geeky, experimental, know how to fix, have backups, report bugs. Also running production systems (my work laptops), am an adult, have a day job, not a lot of free time. But I still like learning. Maybe I'll add the 3.18 rc's and keep 3.17 around, too. Can always fall back if something goes south.