User: Password:
Subscribe / Log in / New account

Preparing the kernel for UEFI secure boot

Preparing the kernel for UEFI secure boot

Posted Sep 11, 2012 8:46 UTC (Tue) by jpfrancois (subscriber, #65948)
Parent article: Preparing the kernel for UEFI secure boot

So if you are developping an out of tree module, you have to tell the user of your hardware to disable secure boot ? Not every out of tree module distributor is a big corp shipping binary blobs. We are making 'custom webcam' and distributing a GPL out of tree module.

With UEFI enabled, it will be easier to ship a closed source signed binary driver for windows, than a open source out of tree module for Linux.

I hope ther will be a mechanism to :
- add a key to the trusted key set of a UEFI firmware
- have a module signed with said key added to a kernel signed with a different key.

Or get a "build farm + review mechanism" that allows you to ship a signed module for a particular distro.

Going mainline is not an option for low volume independent hardware vendor.

(Log in to post comments)

Preparing the kernel for UEFI secure boot

Posted Sep 11, 2012 10:22 UTC (Tue) by intgr (subscriber, #39733) [Link]

> Going mainline is not an option for low volume independent hardware vendor.

I'm surprised to hear this from an LWN reader. Surely the cost of maintaining an out-of-tree driver for years to come is greater than spending the one-time effort to get it merged, and then minimal QA in the future to make sure it still works?

Greg Kroah-Hartman has been trying hard to dispel this myth for more than half a decade. Linux contains support for lots of exotic devices and that have maybe a dozen users worldwide.

See for example

> "My driver is only for an obscure piece of hardware, it would never be accepted

> This just is not true at all. We have a whole sub-architecture that only has 2 users in the world out there. We have drivers that I know have only one user, as there was only one piece of hardware ever made for it. It just isn't true, we will take drivers for anything into our tree, as we really want it.

Preparing the kernel for UEFI secure boot

Posted Sep 11, 2012 11:21 UTC (Tue) by jpfrancois (subscriber, #65948) [Link]

This is not the cost of mainlining, but :
overlap with existing driver.
inclusion of features that do not belong in the hardware.

For instance, I doubt you could convince a V4L2 maintainer that a driver doing BGGR to UYVY (ie format conversion) inside the driver is appropriate, and they would be right, this is not a good technical solution, the right thing to do is do the postprocessing in userspace.

However we have a customer with a lot of existing code using UYVY format, and for some reason, they don't think they can introduce soft debayering in these existing tools. So we provide a hack that as legitimately no place in mainline

Even without this unusual use case, not an option does not mean "won't be accepeted in mainline" but not interesting because :
-not flexible enough
-time to market (and time to bugfix / new feature)
-uncertain cost / benefice ratio.

In fact, distro balkanization is a problem that can be easily avoided by distributing the source instead of the binary. UEFI is potentially a huge hurdle to module source distribution. However according to M Garett :

"We're planning on using Suse's approach of permitting local key management at the shim level, and I spent some time discussing this with Vojtech last week. In combination with the above, this should provide a workable mechanism for permitting the end-user to install module signing keys. "

So it seems out of tree module will remain a possibility.

Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds