Supervisor addon functionality lacks ability to allow usbip bind with home assistant os 9.0rc2

[irakhlin]

Describe the issue you are experiencing

Supervisor does now allow interacting with usbip /sys device with newest home assistant os (that includes usbip drivers).

What is the used version of the Supervisor?

2022.09.0

What type of installation are you running?

Home Assistant OS

Which operating system are you running on?

Home Assistant Operating System

What is the version of your installed operating system?

9.0rc2

What version of Home Assistant Core is installed?

2022.9.1

Steps to reproduce the issue

I had initially reported this issue to the home assistant OS repo here but it would seem more fitting here.

Home assistant OS 9.0 has added the kernel level usbip drivers to allow addon containers to mount usbip devices, unfortunately as it currently stands the addon config template does not provide enough functionality to fully implement this feature.

To test I created a basic addon container that has usbip binaries along with ssh to navigate inside the container, here.

After correctly loading the vhci-hcd drivers, inside the container run the following:

root@7cbb8c6e-usbipclient:/sys/devices/platform/vhci_hcd.0# usbip list -r 10.0.0.77
Exportable USB devices
======================
 - 10.0.0.77
      1-1.4: Realtek Semiconductor Corp. : unknown product (0bda:a725)
           : /sys/devices/platform/soc/20980000.usb/usb1/1-1/1-1.4
           : Wireless / Radio Frequency / Bluetooth (e0/01/01)
           :  0 - Wireless / Radio Frequency / Bluetooth (e0/01/01)
           :  1 - Wireless / Radio Frequency / Bluetooth (e0/01/01)

root@7cbb8c6e-usbipclient:/sys/devices/platform/vhci_hcd.0# usbip --debug attach -r 10.0.0.77 -b 1-1.4
usbip: debug: usbip.c:129:[run_command] running command: `attach'
libusbip: debug: vhci_driver.c:269:[usbip_vhci_driver_open] available ports: 16
libusbip: debug: vhci_driver.c:281:[usbip_vhci_driver_open] available controllers: 1
libusbip: debug: vhci_driver.c:128:[refresh_imported_device_list] controller 0
libusbip: debug: vhci_driver.c:67:[parse_status] hub hs port 0 status 4 speed 0 devid 0
libusbip: debug: vhci_driver.c:69:[parse_status] sockfd 0 lbusid 0-0
libusbip: debug: vhci_driver.c:67:[parse_status] hub hs port 1 status 4 speed 0 devid 0
libusbip: debug: vhci_driver.c:69:[parse_status] sockfd 0 lbusid 0-0
libusbip: debug: vhci_driver.c:67:[parse_status] hub hs port 2 status 4 speed 0 devid 0
libusbip: debug: vhci_driver.c:69:[parse_status] sockfd 0 lbusid 0-0
libusbip: debug: vhci_driver.c:67:[parse_status] hub hs port 3 status 4 speed 0 devid 0
libusbip: debug: vhci_driver.c:69:[parse_status] sockfd 0 lbusid 0-0
libusbip: debug: vhci_driver.c:67:[parse_status] hub hs port 4 status 4 speed 0 devid 0
libusbip: debug: vhci_driver.c:69:[parse_status] sockfd 0 lbusid 0-0
libusbip: debug: vhci_driver.c:67:[parse_status] hub hs port 5 status 4 speed 0 devid 0
libusbip: debug: vhci_driver.c:69:[parse_status] sockfd 0 lbusid 0-0
libusbip: debug: vhci_driver.c:67:[parse_status] hub hs port 6 status 4 speed 0 devid 0
libusbip: debug: vhci_driver.c:69:[parse_status] sockfd 0 lbusid 0-0
libusbip: debug: vhci_driver.c:67:[parse_status] hub hs port 7 status 4 speed 0 devid 0
libusbip: debug: vhci_driver.c:69:[parse_status] sockfd 0 lbusid 0-0
libusbip: debug: vhci_driver.c:67:[parse_status] hub ss port 8 status 4 speed 0 devid 0
libusbip: debug: vhci_driver.c:69:[parse_status] sockfd 0 lbusid 0-0
libusbip: debug: vhci_driver.c:67:[parse_status] hub ss port 9 status 4 speed 0 devid 0
libusbip: debug: vhci_driver.c:69:[parse_status] sockfd 0 lbusid 0-0
libusbip: debug: vhci_driver.c:67:[parse_status] hub ss port 10 status 4 speed 0 devid 0
libusbip: debug: vhci_driver.c:69:[parse_status] sockfd 0 lbusid 0-0
libusbip: debug: vhci_driver.c:67:[parse_status] hub ss port 11 status 4 speed 0 devid 0
libusbip: debug: vhci_driver.c:69:[parse_status] sockfd 0 lbusid 0-0
libusbip: debug: vhci_driver.c:67:[parse_status] hub ss port 12 status 4 speed 0 devid 0
libusbip: debug: vhci_driver.c:69:[parse_status] sockfd 0 lbusid 0-0
libusbip: debug: vhci_driver.c:67:[parse_status] hub ss port 13 status 4 speed 0 devid 0
libusbip: debug: vhci_driver.c:69:[parse_status] sockfd 0 lbusid 0-0
libusbip: debug: vhci_driver.c:67:[parse_status] hub ss port 14 status 4 speed 0 devid 0
libusbip: debug: vhci_driver.c:69:[parse_status] sockfd 0 lbusid 0-0
libusbip: debug: vhci_driver.c:67:[parse_status] hub ss port 15 status 4 speed 0 devid 0
libusbip: debug: vhci_driver.c:69:[parse_status] sockfd 0 lbusid 0-0
libusbip: debug: vhci_driver.c:104:[parse_status] exit
usbip: debug: usbip_attach.c:100:[import_device] got free port 0
libusbip: debug: vhci_driver.c:367:[usbip_vhci_attach_device2] writing: 0 3 65541 2
libusbip: debug: vhci_driver.c:372:[usbip_vhci_attach_device2] attach attribute path: /sys/devices/platform/vhci_hcd.0/attach
usbip: debug: sysfs_utils.c:18:[write_sysfs_attribute] error opening attribute /sys/devices/platform/vhci_hcd.0/attach
libusbip: debug: vhci_driver.c:376:[usbip_vhci_attach_device2] write_sysfs_attribute failed
usbip: error: import device

While I do see /sys/devices/platform/vhci_hcd.0/attach mounted in the container:

oot@7cbb8c6e-usbipclient:/sys/devices/platform/vhci_hcd.0# ls -l
total 0
--w------- 1 root root 4096 Sep 12 16:00 attach
--w------- 1 root root 4096 Sep 12 16:06 detach
lrwxrwxrwx 1 root root    0 Sep 12 16:06 driver -> ../../../bus/platform/drivers
-rw-r--r-- 1 root root 4096 Sep 12 16:06 driver_override
-r--r--r-- 1 root root 4096 Sep 12 16:06 modalias
-r--r--r-- 1 root root 4096 Sep 12 16:00 nports
drwxr-xr-x 2 root root    0 Sep 12 16:06 power
-r--r--r-- 1 root root 4096 Sep 12 16:00 status
lrwxrwxrwx 1 root root    0 Sep 12 16:06 subsystem -> ../../../bus/platform
-rw-r--r-- 1 root root 4096 Sep 12 16:00 uevent
drwxr-xr-x 5 root root    0 Sep 12 16:06 usb3
drwxr-xr-x 5 root root    0 Sep 12 16:06 usb4
-rw-r--r-- 1 root root 4096 Sep 12 16:06 usbip_debug

My understanding is that /sys is mounted as read only:

root@7cbb8c6e-usbipclient:/sys/devices/platform/vhci_hcd.0# cat attach
cat: attach: Permission denied
root@7cbb8c6e-usbipclient:/sys/devices/platform/vhci_hcd.0# echo 'test' > attach
-bash: attach: Read-only file system

I was able to manually modify the addon containers mount points by adding:

/sys/devices/platform/vhci_hcd.0:/sys/devices/platform/vhci_hcd.0 rw
/sys/bus/platform/drivers/vhci_hcd:/sys/bus/platform/drivers/vhci_hcd rw

However I do not see a way to accomplish this via the addon config template. My understanding is that we would want to be able to mount
/sys/devices/platform/vhci_hcd.0:/sys/devices/platform/vhci_hcd.[x] as the number would increase with each additional usbip device.

Anything in the Supervisor logs that might be useful for us?

Nothing of interest

Additional information

No response

[irakhlin]

@mdegat01 Would a pull request adding this functionality be entertained or is this something you guys already had/have planned? Looking at existing implementation there are a few ways I could see this being added, the one that jumps to mind would be a very clean modified copy of how gpio switch works.

I would propose a bool switch named either "usbip_bus" or "usbip" which when enabled would mount:
/sys/devices/platform/vhci_hcd.0 -> /sys/devices/platform/vhci_hcd.0
/sys/bus/platform/drivers/vhci_hcd -> /sys/bus/platform/drivers/vhci_hcd
/sys/module/vhci_hcd -> /sys/module/vhci_hcd

all with rw, additional may make sense to enable SYS_RAWIO as part of the single switch, although argument can be made that may not be needed and should be up to the addon developer to add in "privileged".

[mdegat01]

@irakhlin we definitely welcome a PR here. I added it to my list but no I have gotten to it yet. Would greatly appreciate it if you know how to tackle it 👍

[irakhlin]

@mdegat01 Apologies if this is not the best place to ask this, but can you verify if its still possible to use this functionality? https://www.home-assistant.io/more-info/unsupported/content_trust/

I have started to test my chances on a test hass os machine but when using my supervisor image I am unable to get passed the content-trust issue. The instructions at https://developers.home-assistant.io/docs/supervisor/development also yield the same results.

found it, if anyone comes across this the option is moved to

ha security options --content-trust=False

[github-actions]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

[OptimusGREEN]

has this been implemented yet?

[github-actions]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.