kernel modules in unprivileged container?

[anoo222]

Hello,

Recently i've started using proxmox on a optiplex as a homeserver, and i'm absolutely loving it!
Ran in several newbie issues, but was able to resolve them by searching, trail & error, and learning on the way.
My optiplex running proxmox is based in my basement.

I have one unpriviliged container for my hackrf, for example to receive ads-b and plot it live on a map.
The issue was, since my optiplex is in the basement,obviously verry bad reception of rf signals.
Since, i mounted my hackrf togheter with a raspberry pi in a bird house outside my house.
The plan was to use usbip to mount my hackrf on the raspberry pi to the proxmox host.
So far so good, i can mount my hackrf to my proxmox host with usbip.

I can use my hackrf in my unprivileged container by including lxc.mount.entry /dev/bus/usb/xxx/xxx in the container conf file, and then to chown 100000:100000 /dev/bus/usb/xxx/xxx.
Each time i have to this manually, like before when the hackrf was directly connected to the proxmox host.
(udev rules don't seem to work with hackrf, i can find the device in the container using udev rules, but libhackrf can't 'talk' to the device.)

Now my question, usbip uses 2 kernel modules on the client (proxmox host) side, usbip-core and vhci-hcd.
I've tried to mount the hackrf directly in the unprivileged container with usbip, but ran into issues with both above mentioned modules.
Is there any way i can let the unprivileged container uses these exact 2 modules, so i can mount my hackrf directly in the container with usbip?

Thank u

 

[t.lamprecht]

Hi,

I've tried to mount the hackrf directly in the unprivileged container with usbip, but ran into issues with both above mentioned modules.
Is there any way i can let the unprivileged container uses these exact 2 modules, so i can mount my hackrf directly in the container with usbip?

As (unlike VMs) all Container share the host (Proxmox VE) kernel the modules need to be also loaded there, as there are no module namespaces or the like.

The simplest way would be to tell Proxmox VE to always load those two modules on boot, e.g. by adding them to the /etc/modules file (one per line).

For completeness' sake:
If you need to set specific module options you would do that by adding respective options modulename option... line in a /etc/modprobe.d/*.conf file.

 

[anoo222]

Hi,

Thank u for your response.

First of all, apologies for my bad english, after reading my post again, it isn't very clear what i really want to accomplish.

I know containers use the host kernel and it isn't possible to load any modules in the container which aren't running on the kernel itself for obvious security reasons. My setup right now works, by using my raspberry pi as a usbip server, and the proxmox host as a usbip client. The client is dependant on 2 kernel modules (usbip-core & vhci-hcd).

I've loaded those 2 modules on the proxmox host and was able to mount the usb device on my raspberry pi to my proxmox host using usbip.
To mount the usb device from the proxmox host to my unprivileged container, i've changed the lxc conf & device permissions accordingly.

Essentially i want to bypass those last 2 steps, and use the unprivileged container as the usbip client.

In the container, using usbip, the container can 'talk' to the usbip server;

root@Hackrf:/dump1090_sdrplus# usbip list -r 192.168.1.50
Exportable USB devices
======================
 - 192.168.1.50
      1-1.5: OpenMoko, Inc. : Great Scott Gadgets HackRF One SDR (1d50:6089)
           : /sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.5
           : (Defined at Interface level) (00/00/00)
           :  0 - Vendor Specific Class / Vendor Specific Subclass / Vendor Specific Protocol (ff/ff/ff)

Trying to attach it to the container: (This does work on the host)

root@Hackrf:/dump1090_sdrplus# usbip attach -r 192.168.1.50 -b 1-1.5
usbip: error: import device

Modules are running on the host (command on container)

root@Hackrf:/dump1090_sdrplus# lsmod | grep vhci
vhci_hcd               57344  0
usbip_core             36864  1 vhci_hcd

Trying modinfo in the container:

root@Hackrf:/dump1090_sdrplus# modinfo vhci-hcd
modinfo: ERROR: Module alias vhci-hcd not found.

root@Hackrf:/dump1090_sdrplus# modinfo usbip-core
modinfo: ERROR: Module alias usbip-core not found.

So, in the container i can see both modules are loaded on the host, but usbip can't use them in the container.
Maybe a permission problem? Is it even possible to use kernel modules in a container?
Is there any way i can make this work?

I'll replicate above steps on the proxmox host;

root@proxmox:~# usbip list -r 192.168.1.50
Exportable USB devices
======================
 - 192.168.1.50
      1-1.5: OpenMoko, Inc. : Great Scott Gadgets HackRF One SDR (1d50:6089)
           : /sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.5
           : (Defined at Interface level) (00/00/00)
           :  0 - Vendor Specific Class / Vendor Specific Subclass / Vendor Specific Protocol (ff/ff/ff)

root@proxmox:~# usbip attach -r 192.168.1.50 -b 1-1.5

Attach gave no output but was succesful;

root@proxmox:~# usbip port
Imported USB devices
====================
Port 00: <Port in Use> at High Speed(480Mbps)
       OpenMoko, Inc. : Great Scott Gadgets HackRF One SDR (1d50:6089)
       3-1 -> usbip://192.168.1.50:3240/1-1.5
           -> remote bus/dev 001/005

root@proxmox:~# lsusb | grep HackRF
Bus 003 Device 003: ID 1d50:6089 OpenMoko, Inc. Great Scott Gadgets HackRF One SDR

lsmod

root@proxmox:~# lsmod | grep vhci
vhci_hcd               57344  0
usbip_core             36864  1 vhci_hcd

modinfo

root@proxmox:~# modinfo vhci-hcd
filename:       /lib/modules/5.15.85-1-pve/kernel/drivers/usb/usbip/vhci-hcd.ko
license:        GPL
description:    USB/IP 'Virtual' Host Controller (VHCI) Driver
author:         Takahiro Hirofuchi
srcversion:     8D5569137A4FED6EC22B5AD
depends:        usbip-core
retpoline:      Y
intree:         Y
name:           vhci_hcd
vermagic:       5.15.85-1-pve SMP mod_unload modversions

root@proxmox:~# modinfo usbip-core
filename:       /lib/modules/5.15.85-1-pve/kernel/drivers/usb/usbip/usbip-core.ko
license:        GPL
description:    USB/IP Core
author:         Takahiro Hirofuchi <hirofuchi@users.sourceforge.net>
srcversion:     8A0F4D74D9D1EC3AD16FAF4
depends:       
retpoline:      Y
intree:         Y
name:           usbip_core
vermagic:       5.15.85-1-pve SMP mod_unload modversions
parm:           usbip_debug_flag:debug flags (defined in usbip_common.h) (ulong)

Hoping someone could help.

Thanks in advance

 

[t.lamprecht]

I've loaded those 2 modules on the proxmox host and was able to mount the usb device on my raspberry pi to my proxmox host using usbip.
To mount the usb device from the proxmox host to my unprivileged container, i've changed the lxc conf & device permissions accordingly.

Essentially i want to bypass those last 2 steps, and use the unprivileged container as the usbip client.

Hmm, for that to work the CT would need to get uevents forwarded so that udev can see them, but with the user namespace of the CT that is not trivial.

Might either want to try privileged CTs, if you fully trust the CT and only use it as software encapsulation you could also try to use the unconfined profile then.

Please note also that you can host lxc.* entries also directly in the Proxmox VE CT config in /etc/pve/nodes/NODE/lxc/VMID.conf, so that you do not need to alter the /var/lib/lxc/VMID/config after every CT restart.

With that you'd could setup a (system) service that is ordered before the pve-guests.service and starts the usb-ip client and then sets the correct device owner.

 

[anoo222]

Thank u,

i will have to do some more research on the directions u mentioned and i will go from there.

 

[t.lamprecht]

Are you expecting to load a kernel module only within the container (not on the host)? This is not possible. Containers don't have their own kernel - they run on the host's kernel. If you need an isolated environment for kernel modules, use a VM instead.

I think that's known here, as they write:

I know containers use the host kernel and it isn't possible to load any modules in the container which aren't running on the kernel itself