Driver signing

[fduraibi]

I have a laptop with secure boot enabled, everything under my Fedora 22 run fine except for Bumblebee with nvidia native drivers since the drivers need to be signed.
After every update of Bumblebee packages I need to modify "/usr/sbin/bumblebee-nvidia" and update the nvidia-installer part with the parameters for key signing to allow it to sign the new drivers.

The modification is simple, i need to add this only: "--module-signing-secret-key=/etc/kernel-keys/private_key.priv --module-signing-public-key=/etc/kernel-keys/public_key.der" but it is annoying to do manually every time

So it would be great if i can set these in the bumblebee config file and the driver installer will include these when they are enabled.

• I also need to sign bbswitch.ko, but I managed that by a script under "/etc/kernel/postinst.d/" which signs the driver after every new kernel. However, for nvidia drivers the installer will delete the compiled drivers if they failed to start.

[gsgatlin]

Email me your edited bumblebee-nvidia script and your script under /etc/kernel/postinst.d/ and I will see if I can make it work. My email address is in the changelog for these packages.

[fduraibi]

• The kernel script is simple: (from fedora)

perl /usr/src/kernels/$KVER/scripts/sign-file sha256 $KEYPATH/private_key.priv $KEYPATH/public_key.der /usr/lib/modules/$1/extra/bbswitch.ko

• The change to bumblebee-nvidia script is also simple since nvidia installer has support for driver signing:

Original:

 if [  -n "$forcedebug" ]; then
      ./nvidia-installer --accept-license --silent --no-x-check --no-nouveau-check --no-recursion --opengl-libdir=$bumblebee_libdir/nvidia-bumblebee --opengl-prefix=/usr --x-library-path=$bumblebee_libdir/nvidia-bumblebee --x-prefix=/usr --x-module-path=/usr/$bumblebee_libdir/nvidia-bumblebee/xorg/modules $bumblebee_lastarg
      vidcompile=$?
 else
      ./nvidia-installer --accept-license --silent --no-x-check --no-nouveau-check --no-recursion --opengl-libdir=$bumblebee_libdir/nvidia-bumblebee --opengl-prefix=/usr --x-library-path=$bumblebee_libdir/nvidia-bumblebee --x-prefix=/usr --x-module-path=/usr/$bumblebee_libdir/nvidia-bumblebee/xorg/modules $bumblebee_lastarg > /dev/null 2>&1
      vidcompile=$?
 fi

Change To:

 sign_driver="--module-signing-secret-key=/etc/kernel-keys/private_key.priv --module-signing-public-key=/etc/kernel-keys/public_key.der"
 if [  -n "$forcedebug" ]; then
      ./nvidia-installer --accept-license --silent --no-x-check --no-nouveau-check --no-recursion --opengl-libdir=$bumblebee_libdir/nvidia-bumblebee --opengl-prefix=/usr --x-library-path=$bumblebee_libdir/nvidia-bumblebee --x-prefix=/usr --x-module-path=/usr/$bumblebee_libdir/nvidia-bumblebee/xorg/modules $sign_driver $bumblebee_lastarg
      vidcompile=$?
 else
      ./nvidia-installer --accept-license --silent --no-x-check --no-nouveau-check --no-recursion --opengl-libdir=$bumblebee_libdir/nvidia-bumblebee --opengl-prefix=/usr --x-library-path=$bumblebee_libdir/nvidia-bumblebee --x-prefix=/usr --x-module-path=/usr/$bumblebee_libdir/nvidia-bumblebee/xorg/modules $sign_driver $bumblebee_lastarg > /dev/null 2>&1
      vidcompile=$?
 fi

So the variable sign_driver should gets its info from a configuration file instead.

[gsgatlin]

This would seem to indicate that every user is expected to create public private keys like you do. Is this correct?

If so, I am hesitant to make these changes since most people will not want to go to the trouble of doing that.. Here is a block that would probably be ok.

if [ -f /etc/kernel-keys/private_key.priv ] && [ -f /etc/kernel-keys/public_key.der ] ; then

sign_driver="--module-signing-secret-key=/etc/kernel-keys/private_key.priv --module-signing-public-key=/etc/kernel-keys/public_key.der"

else

sign_driver=""

fi

Does that look ok to you?

[fduraibi]

Yes, every user has to create his own public and private keys and also import the public key into the computer UEFI to be trusted by the secure boot. Unless that user has access to fedora (or whatever disto) signing keys.

Also the key path and name is user defined, and shouldn't be hard-coded into the script. However, I believe the best way is to have the settings under /etc/bumblebee-nvidia.conf something like this:

## Public and private keys to sing the drivers for systems with secure boot (full path)
## Note: the created public key must be imported into the UEFI.
Publickey=
Privatekey=

then bumblebee-nvidia will check if these variables are not set set sign_driver="" otherwise use them.

[gsgatlin]

Alright. I changed the name of the config file to /etc/bumblebee-nvidia-sign.conf (to avoid confusion with the other bumblebee-nvidia.conf) and marked it with a %config in the files section so it should not be overwritten with your changes to it.

bumblebee-nvidia-2.0-4.fc22.noarch.rpm (unmanaged) or
bumblebee-nvidia-352.55-4.fc22.x86_64.rpm (managed)

should fix your issue after you edit the configuration file. Both are set up in my yum repo as of now. Can you test it and let me know if that works?

If it works, I will slightly change my documentation here to make mention of its existence:

https://www.linux.ncsu.edu/bumblebee/#before-started

I put your name in the shell script as having come up with the idea for this.

[fduraibi]

Thanks, that was fast.

I can confirm that it works, but I have two suggestions:

• I made a mistake in my previous comment and forgot to include the bumblebee folder but I find it more trivial if bumblebee-nvidia-sign.conf is placed inside the bumblebee config folder /etc/bumblebee/.
• In the script replace or with and when checking for key files, since nvidia installer needs both.
  Change:
  if [ "$Publickey" == "" ] || [ "$Privatekey" == "" ] ; then
  To:
  if [ "$Publickey" == "" ] && [ "$Privatekey" == "" ] ; then

In the documentation you might want to include a reference to Signing Kernel Modules for Secure Boot which explains and includes the steps to create keys, import them into the UEFI and how to use them to sing drivers like bbswitch...etc.

[gsgatlin]

I am ok with moving the file to within /etc/bumblebee/

Question.

Shouldn't it be using "or" because both keys need to be defined for it to work? If I used "and" couldn't someone just set one and not the other and it would pass the arguments to the installer that could cause errors? (Just asking here)

[fduraibi]

My bad, you are right, 'or' is the right thing.

[gsgatlin]

Alright. I think bumblebee-nvidia-352.55-5 should have the file as /etc/bumblebee/bumblebee-nvidia-sign.conf instead of /etc/bumblebee-nvidia-sign.conf. I updated https://www.linux.ncsu.edu/bumblebee/#before-started with the new information. let me know if that is working. You should be able to dnf update it starting now.

[fduraibi]

Great work.

How about bbswitch?

there is a workaround different from the kernel post install script, which is with DKMS by setting a path to a script with POST_BUILD= or POST_INSTALL= in dkms config file, so it will run that script whenever it builds or installs a driver. I haven't tried it yet though.

BTW, what is the difference between "bbswitch" and "bbswitch-dkms" packages?

[gsgatlin]

Here is a super brief rundown of the rpm development process so you can get your vision of how it should work to be setup by default with a fresh install...

Before we start please read:

https://www.linux.ncsu.edu/bumblebee/#bbswitch

So make sure you are dealing with bbswitch-dkms rpm rather then "bbswitch" rpm.

as root run

# dnf -y install @development-tools
# dnf -y install fedora-packager

In your $HOME directory run:

$ yumdownloader --source bbswitch-dkms
$ rpm -ivh bbswitch-dkms-0.8.0-2.fc22.src.rpm
$ cd rpmbuild/SOURCES/
$ tar -xvzf bbswitch-0.8.tar.gz

edit bbswitch-0.8/dkms/dkms.conf add

POST_BUILD=/path/to/script

or

POST_INSTALL=/path/to/script

Tar it back up with your edited dkms.conf. Eventually this will need to be a "patch" but for now you can just alter the tar archive as you develop it.

Write a shell script. You shell script should be crafted in such a way so that it still works if someone doesn't want to make a private / public key similar to how the modified bumblebee-nvidia works. Leave your shell script in the rpmbuild/SOURCES directory at the same level as bbswitch-0.8.tar.gz.

$ cd ..
$ cd SPECS/

edit bbswitch-dkms.spec

you may need to add something in there in the %post part. I don't know. But you for sure will have to add your custom shell script in the %install section and as a Source1 near the top. Also add it to the %files section. If you shell script sources some config file then add it as a Source2 and also in the %install section and %files section.

next run:

$ rpmbuild -ba bbswitch-dkms.spec

Install your package. (may want to remove the old one first or bump the Release: number higher then 2%{?dist} so you could "upgrade it"

See if it works like how you want it to.

Once its working, paste all the files you modified to a site such as http://pastebin.com/ or http://www.fpaste.org/

Link to your modified files in this issue. (Or open a new issue if you like)

If I can test it and it still works for my setup, I will add your changes and make a patch for the dkms.conf provided by the bumblebee project. Perhaps you will also want to do a "pull request" at
https://github.com/Bumblebee-Project/bbswitch to get your changes merged "upstream" so that it could benefit other distros. If you do that, then put your shell script and config file within the git archive you clone.

Good luck.

[gsgatlin]

Oh, and every line after

dnf -y install fedora-packager

should be run as a regular user account. not as root. You only need root for those two lines.

[gsgatlin]

After thinking about it, it may not appropriate to do a pull request because I'm thinking the way kernels are handled on different distros might be pretty different from how fedora does it...

[Lekensteyn]

I think that module signing is a task for the integrator, distros likely have different methods to do that. Maybe it should be done by a global dkms config? When DKMS was created, there was no module signing.

[fduraibi]

@gsgatlin I will do that when I get time, kinda busy with some work these days.
I have also sent an email to dkms development list 4 days ago but haven't received a response yet.

@Lekensteyn I don't understand what do you mean by it being a task of the integrator? modules that gets compiled by the user, like nvidia drivers, have to be signed by the user's keys. Also the signing script scripts/sign-file that I use to sign the module is not Fedora specific, it comes from the kernel mainstream https://www.kernel.org/doc/Documentation/module-signing.txt

---

I think secure boot is something that some linux communities/distros is avoiding for no reason. Most responses online are advising people to disable secure boot, but I think we should implement a solution since we can. I tried searching to see how other distros do it or if they have documentations and couldn't find much. I would love to see people from other distros contributing to this thread, but I think what we do here is generic and should work with all. Correct me if I am wrong.

[gsgatlin]

@fduraibi He means its a distro specific problem I think. So whatever you make work in fedora will probably not be applicable for say, arch linux or gentoo or debian for example.

I will be happy to try to include a fix if you can figure it out but its not something I'm very familiar with. I think he is saying that I am the integrator for the fedora distro since bbswitch is forbidden from being in the fedora distro because of policy:

https://fedoraproject.org/wiki/Packaging:Guidelines?rd=Packaging/Guidelines#No_External_Kernel_Modules

[gsgatlin]

Also, if you do figure it out, I have a kmod for bbswitch lying around. I might be persuaded to submit it for a review request at http://rpmfusion.org/ If I ever get more free time. But I'm not sure how kernel signing works there.

So far dkms has worked out really well for me as a solution.

[fduraibi]

I also prefer dkms over kmod/akmod, it easier to use and very flexible specially for advance users.

I don't think rpmfusion kmod packages works with signed kernels. I just tested Virtualbox kmod and it failed to load the drivers. simply because the key creation and importing into UEFI need to be done by the system admin. And unfortunately I don't see an easy solution that works for all. In addition to the problem of having the signing keys installed on the same system, since that will also allow malware to sign themselves, and the only convenient solution is to keep the keys in a special folder with root only access and that is still not very secure.

[gsgatlin]

Ah. Ok. I guess they must expect you to turn off secureboot for out of tree modules from http://rpmfusion.org/ then. Thanks for testing that out with virtualbox. Well, if you can figure it out I'll be happy to package up your shell script and changes to the dkms.conf. There is no rush. Cheers.

[qlixed]

Can we reopen this? I see that the bbswitch module is still not signed using the rpm install instructions from:
https://fedoraproject.org/wiki/Bumblebee
That instructions AFAIK are official, but with a new kernel install the bbswitch is not signed, I try to add to the dkms a script to sign the file, but apparently dkms POST_BUILD and PRE_INSTALL is not working as expected.
So I want to know if we can review this to check if we can integrate a definitive solution.

[gsgatlin]

Yes. I would be open to changing the bbswitch rpm to facilitate this. I am just not sure how to go about it since I don't sign my "out of tree" modules myself up to this point.

[qlixed]

Ok, I will work on this options and put a PR ASAP.

[gsgatlin]

Ok. The package is not officially supported in fedora. The rpms are something I made back in fedora 16 because I needed bbswitch. The rpm spec is not in github. Perhaps I can add it to my area.

But here is what the spec file looks like. There are 3 problems I know about.

https://paste.fedoraproject.org/549951/48639718/

1. If we need to update it without also updating the "version" It breaks. :( I just found out about that recently. Perhaps people on the dkms mailing list would have some ideas about how to fix that?

2. It does not "autoload" correctly. So I guess we need to add a thing to modprobe it at boot time.

3. It does not work with signing which is what you wanted to add.

Sorry it has so many issues. But it is what it is.