larixer / hid-asus-dkms

ASUS HID FTE100* DKMS Driver
GNU General Public License v2.0
68 stars 10 forks source link

Kernel Module Signing - Idea? #30

Closed maheshsundaram closed 7 years ago

maheshsundaram commented 7 years ago

I somehow have the understanding that secure boot is needed for some third party drivers - I guess this is for the same reason that they must be signed?

I thought that that meant I couldn't use VirtualBox, because it too requires secure boot disabled, but I have it enabled for other drivers.

However I was able to find a way to self-sign the module, following this guide here: https://gorka.eguileor.com/vbox-vmware-in-secureboot-linux-2016-update/

I wanted to bring it up here because I thought maybe the same method could be used here. I will give it a try myself but I don't yet follow what all the scripts here do, so if you're motivated and capable, I'd be very grateful.

larixer commented 7 years ago

We need to investigate driver signing and what we can do to help DKMS driver users. I'm not sure when we will have time for this, no promises though, but hints are welcome. Pull requests are welcome even more.

maheshsundaram commented 7 years ago

Thanks for your reply! Ah ok, I didn't notice a difference that this is for a driver and not a module? I'd be glad to submit a PR if I can sort this out. Feel free to close this issue, too.

mirh commented 7 years ago

Can't you use the normal PreLoader to add the module hash to UEFI sign store and all?

larixer commented 7 years ago

@mirh I don't see in the link you provided any mentions of UEFI loaders or preloaders, neither mentions about UEFI sign store. I'm not sure what do you mean at all. Anyways pull requests are welcome.

larixer commented 7 years ago

@mirh I suspect you are talking about Linux Foundation PreLoader: http://www.rodsbooks.com/efi-bootloaders/secureboot.html#preloader

mirh commented 7 years ago

Yes, I'm talking about that (and I mean, it's not like other preloaders exist), which in turn leads you to what I linked.

Latest sources are here then, for as much afaik the majority of distro images already ship with binaries.

redmcg commented 7 years ago

It does look like there are a number of alternatives to disabling secure boot out there - none look possible to script though (particular this option). I think the best we can do is note that there are alternatives and leave it to the reader/user to choose the option that best suits them.

Commit 6f0979a0b50eb320962b8adf34d7ad892903b458 closes this issue.

mirh commented 7 years ago

It does look like there are a number of alternatives to disabling secure boot out there - none look possible to script though (particular this option)

There are. See Bumblebee-Project/Bumblebee#692 and this. The only thing I'm unsure is the one-time addition of your signature to the keystore, although you might want to check sbsigntools

redmcg commented 7 years ago

@mirh That modification to the Bumblebee install script is to have DKMS automatically sign the installed module on each kernel upgrade (as a DKMS module needs to be rebuilt with each kernel upgrade).

The generation of the keys and the configuration of your firmware to accept these new keys all have to be done manually and by a person physically at the machine. It can not be scripted. Which is a good thing for secure boot - because if it could be scripted - an attacker would use this avenue to circumvent secure boot.

mirh commented 7 years ago

Well, I'd already find acceptable what Bumblebee already achieved tbh.

That aside, sbkeysync seems quite suspiciously interesting.