Kein /dev/raw-uart

[ccvca]

Hallo zusammen,

auf meinem System wird /dev/raw-uart nicht angelegt.

Systeminfo: Nuc 10 Debian 11 HmIP-RFUSB

Installationsschritte nach dieser Anleitung durchgeführt: https://github.com/alexreinert/debmatic/blob/master/docs/setup/otheros.md#installation

Aufgrund eines standardmäßig aktivierten SecureBoot, musste der der Treiber eq3_char_loop nach der Installation noch signiert werden. Anleitung von hier verwendet: https://askubuntu.com/questions/760671/could-not-load-vboxdrv-after-upgrade-to-ubuntu-16-04-and-i-want-to-keep-secur/768310#768310 Hinweis für etwaige Nachahmer: Beim Eintragen des SecureBoot Passwortes nach dem neustart, war bei mir das englische Tastaturlayout aktive => z und y sowie die Sonderzeichen sind woanders auf der Tastatur. Besser also Sonderzeichen und 'y'/ 'z' im Passwort vermeiden.

Der USB-Stick wird erkannt.

$ lsusb
[...]
Bus 001 Device 002: ID 1b1f:c020 eQ-3 Entwicklung GmbH HmIP-RFUSB
[...]

Ebenso ist der Kerneltreiber eq3_char_loop nach dem Eintrag in die Module geladen:

$ cat /etc/modules-load.d/eq3_char_loop.conf
eq3_char_loop

$ lsmod | grep eq3
eq3_char_loop          20480  0

Nach der dmesg-Ausgabe macht der Treiber aber leider nichts außer laden:

$ sudo dmesg | grep eq3
[    3.940955] eq3_char_loop: loading out-of-tree module taints kernel.

Gibt es hier noch weitere Kerneltreiber, die ebenfalls signiert werden müssen? Auf was wartet der Kerneltreiber genau, bevor er das raw-uart Device erstellt?

PS: Der USB-Stick hat in einerm RaspberryPi 3 ohne Probleme funktioniert.

[alexreinert]

raw-uart besteht aus mehreren Kernel Modulen und je nach Funkmodul kommen weitere dazu, siehe /kernel hier im Repo.

[ccvca]

Vielen Dank für die schnelle Hilfe. Nachdem alle Kerneltreiber digital signiert sind, funktioniert es.

Hier noch das Skript dazu, falls es nochmal jemand braucht:

#!/bin/bash

mkdir -p /tmp/k
chmod 700 /tmp/k
# Assume, that the keys are ~/MOK.priv and ~/MOK.der

# Temporary remove encryption, as sign-file does not like my password
# TODO set password in $KBUILD_SIGN_PIN environment variable
# like described here: https://www.kernel.org/doc/html/v4.15/admin-guide/module-signing.html#manually-signing-modules

openssl rsa -in ~/MOK.priv -out /tmp/k/MOK_u.priv

# Kernel drivers of pivccu, see:
# ls -la /lib/modules/$(uname -r)/updates/dkms/*.ko
declare -a koArray=(
"dummy_rx8130"
"dw_apb_raw_uart"
"eq3_char_loop"
"fake_hmrf"
"generic_raw_uart"
"hb_rf_eth"
"hb_rf_usb_2"
"hb_rf_usb"
"led_trigger_timer"
"meson_raw_uart"
"pl011_raw_uart"
"plat_eq3ccu2"
"rpi_rf_mod_led"
"rtc-rx8130"
)

for koMod in "${koArray[@]}" ; do
  echo $koMod
  sudo /usr/src/linux-headers-$(uname -r)/scripts/sign-file sha256 /tmp/k/MOK_u.priv ~/MOK.der $(/sbin/modinfo -n $koMod) -p
done

# Remove directory with unencrypted key
rm -rf /tmp/k

Da das Problem mit den signierten Kerneltreibern in Zukunft vermutlich noch öfters auftreten könnte. Wäre es technisch möglich, statt eines Kerneltreibers auf CUSE (https://lwn.net/Articles/308445/) aufzubauen? (nur mal die technische Frage, mir ist klar, dass das ziemlich viel Aufwand bedeutet)

Zumindest der Treiber cp210x der für den HMIP-RFUSB ein ttyUSB erstellt ist ja der bei Debian 11 bereits signiert mitgeliefert.

[alexreinert]

An sich bringt DKMS alles mit, was man für Secure Boot braucht und signiert gebaute Module auch gleich passend. Allerdings nur, wenn man den kompletten Debian Way nutzt, welcher auch bedeutet, dass man den Key nicht selbst erstellt, sondern von der Infrastruktur erstellen lässt.