atar-axis
commented
5 years ago Your bug reports are just awesome, precise and rich of useful information - thanks!
I will dig a bit deeper and let you know when I found the problem.
Closed CommunicationAnimale closed 5 years ago
atar-axis
commented
5 years ago Your bug reports are just awesome, precise and rich of useful information - thanks!
I will dig a bit deeper and let you know when I found the problem.
atar-axis
commented
5 years ago Could you please give me the output of modinfo hid_xpadneo on your system?
atar-axis
commented
5 years ago Btw, have you tried to self-sign it (as a temporary workaround)? Like described here in these articles:
atar-axis
commented
5 years ago Here is a more automatic solution: https://computerlinguist.org/make-dkms-sign-kernel-modules-for-secure-boot-on-ubuntu-1604.html
I am not yet sure if this is something I can fix on the source-side. Using DKMS the module is built on the users system, it is as a result not signed as long as you do not sign it yourself afterwards. I guess that this is a general DKMS / lockdown problem.
What I can do is adding a hook that automatically executes a sign-script (as documented in the link above). The script could look for a MOK (machine owners key) in your home directory, if there is one, it signs the module - if not, it leaves it unsigned. So it would be up to you to create such a key as described here.
What do you think about that solution?
edit: Hum, in theory it should be possible to create the MOK automatically too, right?
CommunicationAnimale
commented
5 years ago ❯ modinfo hid_xpadneo
filename: /lib/modules/4.19.12-301.fc29.x86_64/extra/hid-xpadneo.ko.xz
version: 0.5.0
description: Linux kernel driver for Xbox ONE S+ gamepads (BT), incl. FF
author: Florian Dollinger <dollinger.florian@gmx.de>
license: GPL
srcversion: 04A1F39FFF1D6D706299382
alias: hid:b0005g*v0000045Ep000002E0
alias: hid:b0005g*v0000045Ep000002FD
depends: ff-memless
name: hid_xpadneo
vermagic: 4.19.12-301.fc29.x86_64 SMP mod_unload
parm: debug_level:(u8) Debug information level: 0 (none) to 3+ (most verbose). (byte)
parm: disable_ff:(bool) Disable all force-feedback effects (rumble). 1: disable ff, 0: enable ff. (bool)
parm: trigger_rumble_damping:(u8) Damp the trigger: 1 (none) to 2^8+ (max) (byte)
parm: fake_dev_version:(u16) Fake device version # to hide from SDL's mappings. 0x0001-0xFFFF: fake version, others: keep original (ushort)Self-signing seems to be the natural solution. It seems that Ubuntu (almost) completely automates the process of generating keys and signing modules when installing dkms modules with apt. It also provides a script to automatically generate the keys and sign modules. The script is called update-secureboot-policy (although it seems that it cannot update the secure boot policy...). It can be found in the source of the shim-signed package.
Click arrows to reveal:
update-secureboot-policyopenssl.cnfThis script is not portable (dpkg, ubuntu-specific paths...) and is far too generic, but show that automating the process is certainly doable.
After writing this, I tried manually signing the modules using the instructions from the Fedora documentation, and automating it using the link you provided (https://computerlinguist.org/make-dkms-sign-kernel-modules-for-secure-boot-on-ubuntu-1604.html). However, it failed because the module is compressed.
I found this gist which extends the scripts from the previous link to support compressed modules. Additionaly, it provides a script for the initial setup.
I deleted the keys I previously enrolled in the shim, and followed the procedure detailed in the gist. It was extremely simple, and worked out of the box!
Notes:
-nodes to the openssl command and remove the functions dealing with $KBUILD_SIGN_PIN (whose role is explained here).Here are some logs:
dmesgSecure boot is enabled, Xpadneo is loaded and will automatically be signed every time I update!
atar-axis
commented
5 years ago Thanks for your research! I will dig around a bit to see if there are any drawbacks, but I think this is a good solution :+1:
atar-axis
commented
5 years ago Unfortunately the script is not compatible with ARCH (since there is no mokutil), which is the linux distribution I am using. That's at least a hint that the script is not as portable as the maintainer hoped.
I cannot test the script therefore and cannot (and don't want to) add it to the driver, not as long as we haven't found a solution which works on (at least nearly) every distribution.
Furthermore, I never used secure boot or kernel_lockdown, I am therefore not experienced in this field - but what I found is that it somehow looks like there is not even a consistent opinion on how good or evil those techniques really are.
I think that the best way at the moment is to add some instructions to the README and hope for the future that Dell, who maintains DKMS, is going to add some signing functionality (https://github.com/dell/dkms/issues/72).
I am sorry for all your research and efforts but I absolutely cannot add something that is not distribution independent. What do you think?
edit
The only trade-off that comes to my mind is that I could integrate the automated signing script only, which means that the user has to generate and enroll the keys himself (running the one-time-setup or anything else that is necessary). The driver installation script will check for /root/MOK.priv and /root/MOK.der, it they exist, then the module gets signed - otherwise signing is skipped.
CommunicationAnimale
commented
5 years ago Personally, I'm not even using Secure Boot anymore as I discovered yesterday that disabling it fixes a longstanding issue I had with hibernation... And you're completely right, feelings are mixed regarding Secure Boot.
I'm not sure that enabling auto-signing by default is a good idea, since it will be poorly tested. Once someone overcomes the hurdle of generating and enrolling the keys, enabling auto-signing is as simple as creating "/etc/dkms/hid-xpadneo.conf".
I think the least we can do is point out that Xpadneo will not work with Secure Boot OOTB in the README.md (especially considering that Secure Boot cannot be disabled on some computers, e.g. on "Windows 8 Ready" ARM computers), and add a link to dop3j0e's gist. My only gripes are:
-nodes to the openssl incantation, and auto-signing is now passwordless.<module-name> should be replaced with hid-xpadneo in the case of Xpadneo.Final thoughts: maybe we should let ditributions handle this. I stated earlier that DKMS modules installed with apt on Ubuntu would be automatically signed, but it seems that any DKMS module will be automatically signed. From Ubuntu wiki:
Simply install the package you need. Packages that make use of DKMS should prompt you to create a new Machine-Owner key (it will be done for you), and will guide you through the steps to enroll that key in your system's firmware.
atar-axis
commented
5 years ago I'm not sure that enabling auto-signing by default is a good idea, since it will be poorly tested. Once someone overcomes the hurdle of generating and enrolling the keys, enabling auto-signing is as simple as creating "/etc/dkms/hid-xpadneo.conf".
Yeah, right. I was just trying to meet halfway ;) I'm happy you see it that realistic.
I think the least we can do is point out that Xpadneo will not work with Secure Boot OOTB in the README.md (especially considering that Secure Boot cannot be disabled on some computers, e.g. on "Windows 8 Ready" ARM computers), and add a link to dop3j0e's gist. My only gripes are:
- It does not support signing without password. On my computer, I removed the lines related to '$PROMPT', the function 'read_passphrase', the line where this function is called and added
-nodesto the openssl incantation, and auto-signing is now passwordless.- It was not immediately clear to me that
<module-name>should be replaced withhid-xpadneoin the case of Xpadneo.- It does not point out that the keyboard layout used when enrolling MOKs is QWERTY.
Perfect, that's the way we go then. Would you mind modifying the README? I think you are more experienced when it comes to those features.
Final thoughts: maybe we should let ditributions handle this. I stated earlier that DKMS modules installed with apt on Ubuntu would be automatically signed, but it seems that any DKMS module will be automatically signed. From Ubuntu wiki:
Simply install the package you need. Packages that make use of DKMS should prompt you to create a new Machine-Owner key (it will be done for you), and will guide you through the steps to enroll that key in your system's firmware.
Hum, interesting!
atar-axis
commented
5 years ago I am still confused by this...
SecureBoot and Kernel_Lockdown is not the same as we all know now (at least after the heated public dicussion).
Linus Torvalds said that he won't accept a patch that "automatically locks down the kernel" when SecureBoot is on
As far as I know Kernel_Lockdown is the mechanism that prevents loading unsigned modules, access to files like /dev/kmem and so on.
So why the heck is your kernel locked down when you enable SecureBoot? And is the lockdown even yet merged to the official kernel? Couldn't find anything in elixir.bootlin.com
Describe the bug When kernel_lockdown is enabled Xpadneo fails to start with the error
Lockdown: systemd-udevd: Loading of unsigned module is restricted; see man kernel_lockdown.7indmesg. Kernel_lockdown is enabled by default when secure boot is enabled.To Reproduce Steps to reproduce the behavior: 1.a Enable secure boot 1.b Connect gamepad with bluetoothctl, it is recognised as a generic device
2.a Disable kernel_lockdown.
echo "1" > /proc/sys/kernel/sysrqto enable temporarily Sysrq key combinations, then presssysrq + alt + x. This will printLifting lockdownindmesg2.b Connect gamepad with bluetoothctl, it rumbles and xpadneo shows up in dmesg
Expected behavior Xpadneo should be used whether lockdown is enabled or not.
System information Note: when kernel_lockdown is enables, debugfs is unavailable. For instance, it is not possible to
catin /sys/kernel/debug:Lockdown: cat: debugfs is restricted; see man kernel_lockdown.7shows up indmesg.uname -aoutputdmesgoutputThe following command need superuser privileges. I recommend to run it as root directly (not using-key will work as expected.
sudo), since this way thehead -1 "/sys/kernel/debug/hid/0005:045E:<TAB>/rdesc" | tee /dev/tty | cksumAdditional context
There are other reports of dkms modules failing to load when lockdown is enabled: e.g. https://bugzilla.redhat.com/show_bug.cgi?id=1599197. I don't understand everything in this bug report, but it seems that the maintainer says that this is not a bug in the kernel.