USB Type-C Port Manager Coming To Linux 4.12

[phoronix]

Phoronix: USB Type-C Port Manager Coming To Linux 4.12

Another feature to look forward to with the Linux 4.12 kernel for those using newer hardware featuring USB Type-C is a port manager...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-4.12-USB-Type-C-TCPM

[uid313]

But USB is insecure.
A device can act as a keyboard and execute commands as if they were typed by a user.

FireWire and Thunderbolt are even worse, they have DMA and can read the RAM.

[Vistaus]

But USB is insecure.
A device can act as a keyboard and execute commands as if they were typed by a user.

FireWire and Thunderbolt are even worse, they have DMA and can read the RAM.

Wy don't you tell us what technology would be better instead?

[FastCode]

ofcourse it's USART
and manually cat /dev/ttyS0 > /dev/kbd

[CrystalGamma]

But USB is insecure.
A device can act as a keyboard and execute commands as if they were typed by a user.

FireWire and Thunderbolt are even worse, they have DMA and can read the RAM.

Unless you plan on using asymmetric cryptography to sign every keyboard (assuming you have a useful trust model sorted out, organizations who would regularly use such hardware attacks will be able to get certified as a keyboard mfgr quite easily with a CA system), that is going to stay that way, regardless of which bus system you use. Remember, you can plug in hw attacks into a PS/2 port as well …

[starshipeleven]

FireWire and Thunderbolt are even worse, they have DMA and can read the RAM.

This is not an issue anymore with modern systems that have VT-d or IOMMU enabled as each device can see only its own allotted RAM space, not everything.

[carewolf]

But USB is insecure.
A device can act as a keyboard and execute commands as if they were typed by a user.

FireWire and Thunderbolt are even worse, they have DMA and can read the RAM.

Hopefully we could make an application solving some of that if we have proper API (such as not enabling keyboards beyond the first one automatically until okayed by the user)

[starshipeleven]

Wy don't you tell us what technology would be better instead?

Having it work kinda like Bluetooth where you need to pair the devices would solve most of the issues. Of course this should be required only by input devices. I don't think there is massive need to encrypt the communication over the wire to avoid hardware keyloggers, but that might be cool to have too.

When you connect a HID device you get a popup saying "hey I detected keyboard with serial number 536827474, authorize its use with your root password" (and you can write your root password with it but it cannot do anything else like using desktop shortcuts or whatever to try to break into your system)

With mice it can show an on-screen keyboard and limit mouse input from that device on that part.

But something like this is not exactly trivial to implement and would break compatibility with most HID devices around. It would be a slaughter the same as the "free upgrade" to Win10.

Fun fact: when pairing bluetooth keyboards they ask you to write the keyboard's own password by typing on it, and it's plain retarded for a security standpoint, but we all know Bluetooth is unsafe anyway.

[starshipeleven]

Hopefully we could make an application solving some of that if we have proper API (such as not enabling keyboards beyond the first one automatically until okayed by the user)

Yeah, a partial solution but would add some protection regardless.

[GI_Jack]

Having it work kinda like Bluetooth where you need to pair the devices would solve most of the issues. Of course this should be required only by input devices. I don't think there is massive need to encrypt the communication over the wire to avoid hardware keyloggers, but that might be cool to have too.

Not only that, but adding HID classes like BT, with specific access only allowed for certain classes. a keyboard can only be a keyboard, storage can only act as storage. It works great. You can even half multiple roles, and at least in android you can limit what profile a device uses, and it shows what profiles a device asks for.