• 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
usb hotplug
#1
Dear netpi users,

I'm starting to grow grey hear from the attempt to hotplug usb devices.
At the moment it is impossible to have in running container usb devices taken off and reattached after a while.

the easiest way to test this is by
-privileged mode
-device /dev/bus

lsusb -vd XXXX:XXXX
XXXX for example the vendor and product id of a hid-device (keyboard)

now remove the keyboard
reattach it
run lsusb again
now you see "Couldn't open device, some information will be missing" at the beginning of the output.
and you can't access it anymore

Same for tty devices
-device /dev/ttyACM0

start container
everything fine
run "udevadm monitor"
remove and attach the device again
now you see the device is not connected back to the device path /dev/ttyACM0 instead it takes /dev/ttyACM1

an easy solution would be if the restrictions of the netpi wouldn't be this restrictive
-device /dev
now the tty would get connected again

-volume bind /dev/bus/usb:/dev/bus/usb
now the usb hid-device could reconnect

I hope anybody has a solution to this problem of the missing USB hotplug functionality or we have to buy other devices for our customers with over 100 devices just in one production system, more would follow.

Thank you very much in advance
Sven
  Reply
#2
Dear Sven,

when we started with netPI two years ago we defined to make it as secure as possible. One aim was that even a customer would load an unsecure application in a container into it in no way this container is able to compromise the host Linux.

We identified two weaknesses in standard Docker daemon one could configure to undermine the security:

* priviledged mode - that by default maps all /dev into a container and hence with /dev/mmcblk0 also netPI's SD card also and /dev/mem
* volume bind mappings of host volumes into the container that would allow to map the boot partition into a container too

This is why privileged mode and volume mapping as you stated correctly is restricted on netPI.

I agree that one or the other application is not possible at all with this security structure, but gives maybe all other 90% of customers a good feeling.

Just a minute ago I posted this thread here https://forum.hilscher.com/thread-380.html. I think this might be helping you.

Thx
Armin
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply
#3
First examinations revealed the following fact

The devices in /dev/bus/usb/XXX/YYY follow naming policies in the Linux kernel. XXX is the bus number which is quite stable (001 in our case), but YYY changes (increased by 1) every time the USB device gets enumerated when a device just got inserted or reset. This cannot be changed and is part of the Linux kernel. So a device that initially was shown under /dev/bus/usb/001/006 for example will get /dev/bus/usb/001/007 after it is inserted back.

Now to the problem. When mapping a /dev/ into a container Docker makes a "snapshot" of the host /dev/ folder at the time the container is created and use it as reference when accessing it in a container. The problem is now that this folder structure it is not updated any more. So if a USB device is removed and inserted back the host /dev/ folder gets updated and shows the changes, but within a container the folder structure remains untouched. Hence it is not possible for the device's driver to find the device any more in a container and denies access.

We need more investigations how to solve this problem on netPI
You never fail until you stop trying.“, Albert Einstein (1879 - 1955)

  Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)