Add scripts that sign the module for Secure Boot

[flodavid]

I created scripts to automate the signing and installation steps required on systems with Secure Boot enabled

[kakra]

Thanks, this look useful. I'll first let Copilot do a review. I'll look into this soon, I hope. I'm currently lacking some time.

[flodavid]

I addressed Copilot feedback and did some small improvements

[flodavid]

I am no expert on this topic so I am not really sure about anything to be honest. I did not do a ton of research. The installation failed for me so I adapted a script that I found for another project and figured that it could be useful for other people too

[kakra]

Given the discussion, I'm guessing this script is mainly used for manual installation, not for the module being managed by dkms? Tho, your doc patches say "if you use dkms...". I think we should check how other dkms-managed modules handle that.

[flodavid]

Given the discussion, I'm guessing this script is mainly used for manual installation, not for the module being managed by dkms? Tho, your doc patches say "if you use dkms...". I think we should check how other dkms-managed modules handle that.

It turns out I was doing it wrong. I was signing AFTER dkms has installed the module, using custom MOK, which prevented auto rebuilds. But in the build output, there is these lines:

Sign command: /usr/bin/kmodsign
Signing key: /var/lib/shim-signed/mok/MOK.priv

Indeed dkms uses shim-signed, which already creates MOK for the machine, they just need to be enrolled. I updated the script to handle that, and removed the custom signing step (I kept the one creating the MOK if it is missing). There is now this additional log during the build, if the shim-signedkey is enrolled:

Signing module /var/lib/dkms/hid-xpadneo/v0.9-228-g2d516d3-dirty/build/src/hid-xpadneo.ko

[kakra]

Sounds promising, I really appreciate it but will need to find some spare time to test it in a VM.

[flodavid]

I simplified the script and improved the process again, by using update-secureboot-policy which manages key generation and enrolment. I also added the set -e option

[flodavid]

Thank you for your feedback and advices, that’s appreciated.

If think the dkms process is almost complete.

I am still working on the generic install. I am not sure about the use of the PEM certificate and its password. I will also try to have good signing rules in the makefile and maybe remove some bash functions to use those instead.

I have a problem on my system though. I guess I have firmware 5.x since the module is not working without uhid. Since the scripts try to load it, it works when I’m running them, but I have to run modprobe uhid on every restart for the driver to work. Do you know if it would be possible to solve this using modprobe softdep, weakdep, or something else ?

[kakra]

I have a problem on my system though. I guess I have firmware 5.x since the module is not working without uhid

I'm not sure how we should properly handle that. It is expected that bluez loads uhid if it is needed. xpadneo is not responsible to do that, we are a HID user, not a HID provider. So I think you should report it to your distribution, maybe they should link uhid statically into the kernel, or add a dependency.

Until then, you could just run:

# always load uhid on boot (requires systemd)
echo "uhid" | sudo tee -a /etc/modules-load.d/99-local.conf

# OR: load uhid with xpadneo (untested)
echo "softdep hid-xpadneo pre: uhid" | sudo tee -a /etc/modprobe.d/99-xpadneo-local.conf

# ALTERNATIVE: load uhid with bluetooth (untested, probably preferred)
echo "softdep bluetooth pre: uhid" | sudo tee -a /etc/modprobe.d/99-bluetooth-uhid.conf

If uhid-related reports keep popping up, we might need to add the latter into xpadneo, tho, I still think, distributions should add that to the standard kernel if they provide bluez with BLE support (or make the bluez service load the module). BLE input devices cannot be used without uhid. Thus, there's no point in adding a softdep to each driver which in theory might maybe support a Bluetooth HID device...

EDIT: I added another alternative.

[flodavid]

Thanks. I tried softdep hid-xpadneo in "99-xpadneo-local.conf" and I had already tried in "/etc/modprobe.d/xpadneo.conf", but it did not work. The one who does is softdep bluetooth in "99-bluetooth-uhid.conf".

What's strange is that I have no vibration when the controller is connected, even though there is ff_connect_notify=1 in "/etc/modprobe.d/99-xpadneo-options.conf". It worked before. EDIT: retried it and it worked this time. Strange

[kakra]

What's strange is that I have no vibration when the controller is connected, even though there is ff_connect_notify=1

This can happen if xpadneo needs to bind lazily to the device via udev rules - it may not have worked during the first connection, and then only on second connect, it will work (and that means, also uhid is present, because we need that to speak to the controller). If xpadneo is already loaded, it will bind immediately and automatically.

You should see a difference in dmesg for both tries - if you can still replicate it...

The one who does is softdep bluetooth in "99-bluetooth-uhid.conf".

Which proves that the driver providing the HID bus has to load it - which is bluez. xpadneo is only a HID consumer. It doesn't even know about BT. Most likely, bluez user-space should probably trigger loading uhid as soon as an BLE input device connects, loading just a bluetooth module isn't technically the correct trigger to load uhid.

Actually, there's a race condition with softdep hid-xpadneo: When loading of xpadneo is triggered by udev, the device has already been enumerated on the HID bus by bluez - so loading uhid now will miss the initial HID handshake of the controller, and thus it probably doesn't work properly (or only on second try). That is, if xpadneo is triggered at all by udev... Without uhid, the udev rules may not even see the HID device.

If you asked me, uhid should be built statically into the kernel by your distribution. It's a needed core driver, not optional. And not only needed by bluez but also by some input device emulators (tho, I think Steam Input uses uinput instead).

[Bulbyzarr]

Hello,

i tried your work because i didn't know that secureboot was enabled on my machine (https://github.com/atar-axis/xpadneo/issues/569)

So, i patched xpadneo with this patch and i have this error : "[error] missing shim-signed, unable to enrol MOK"

Because the script check if "/var/lib/shim-signed" exist in the system. But on Debian Stable, this folder does not exist.

[flodavid]

Oh interesting. I check if this folder exists to detect if shim is installed, as I rely on it for enrollment. Maybe it’s not created by default though. Could you remove line 13 in sign_and_install.sh and relaunch the script to check if it succeeds ?

[Bulbyzarr]

Oh interesting. I check if this folder exists to detect if shim is installed, as I rely on it for enrollment. Maybe it’s not created by default though. Could you remove line 13 in sign_and_install.sh and relaunch the script to check if it succeeds ?

Which files are present in /var/lib/shim ? Because Debian's package shim-signed install shimx64.efi.signed and shim-unsigned package install BOOTX64.CSV, fbx64.efi, mmx64.efi and shimx64.efi in /usr/lib/shim

And if i delete the line 13, i have this log in console :

ezkymoe@debian-desktop:~/Projets/xpadneo$ sudo ./sign_and_install.sh [warn] no need to sign module! [info] Secure boot is enabled and you have to setup signing [info] No Private key found. Generating one No DKMS packages installed: not changing Secure Boot validation state. No DKMS packages installed: not changing Secure Boot validation state.

And nothing else, it's very strange because DKMS is installed ... I use it to install xpadneo after to disable secureboot.

[flodavid]

So I did a fresh install of Debian, and I found out that update-secureboot-policy is not installed by default. I guess it must be misconfigured on your machine or something and that’s what giving you the two errors. I will reimplement the key creation and enrollment without it and retry it. I also noticed that my gamepad was working using Bluetooth out-of-the-box, but vibration did not seem to work

[flodavid]

@Bulbyzarr I was kind of wrong. update-secureboot-policy IS installed on debian, but not with the same version I used. I updated the PR to detect that and fallback on using mokutil. The installation succeeded on debian. I had to install the kernel headers and dkms. I also had to manually create a VERSION file at the root of the project, since git describe failed to retrieve the tags of this repository.

[Bulbyzarr]

@flodavid Sorry, I haven't had time to test it these last few days. i'll test it later. :)