Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 447352 - linux-mod.eclass: add support for module signing
Summary: linux-mod.eclass: add support for module signing
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Eclasses (show other bugs)
Hardware: AMD64 Linux
: Normal enhancement with 4 votes (vote)
Assignee: Gentoo Kernel Bug Wranglers and Kernel Maintainers
Keywords: NeedPatch, PullRequest
: 447356 592170 599708 640216 881641 (view as bug list)
Depends on: 814344
  Show dependency tree
Reported: 2012-12-15 13:21 UTC by Stefan Trenker
Modified: 2023-08-11 22:28 UTC (History)
21 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Trenker 2012-12-15 13:21:06 UTC
app-laptop/tp_smapi-0.41 modules fail to load on 3.7 kernel with CONFIG_MODULE_CONFIG_MODULE_SIG_FORCE=y set.

gucky ~ # modprobe tp_smapi 
FATAL: Error inserting tp_smapi (/lib/modules/3.7.0-gentoo/extra/tp_smapi.ko): Required key not available
Comment 1 Stefan Trenker 2012-12-15 13:23:44 UTC
Appologies for the messed up Description

I meant:

Comment 2 Pacho Ramos gentoo-dev 2012-12-31 19:02:53 UTC
@kernel team, I guess all external modules will need to check for that kernel option being disabled, or is there a way to sign them?
Comment 3 Pacho Ramos gentoo-dev 2013-03-02 19:24:19 UTC
(In reply to comment #2)
> @kernel team, I guess all external modules will need to check for that
> kernel option being disabled, or is there a way to sign them?

kernel team, ping!
Comment 4 Markos Chandras (RETIRED) gentoo-dev 2013-03-12 17:54:05 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > @kernel team, I guess all external modules will need to check for that
> > kernel option being disabled, or is there a way to sign them?
> kernel team, ping!

This does not block 458736. It is a separate problem
Comment 5 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2013-06-08 12:06:12 UTC
(In reply to Pacho Ramos from comment #2)
> @kernel team, I guess all external modules will need to check for that
> kernel option being disabled, or is there a way to sign them?

We can't sign them, I think, unless Gentoo is to be the authority that blesses them. If we would go for such practice, how would we determine when we can appropriately sign something and make the kernel check against us? I'm not sure which authority is actually in charge in this case, but I do expect that any signing would have to come from upstream.

Under the assumption that so sign is available and upstream might not be willing to do this, it would have to indeed check that the relevant kernel options are unset to allow the unsigned module to be installed and used.
Comment 6 Andrew Savchenko gentoo-dev 2013-07-09 00:12:00 UTC
What about asking user or adding some ACCEPT_MODULES_TO_BE_LICENSED keyword?

I usually have a few to zero external modules, so I sign them manually after each installation. Of course this is annoying, but there is no better way ATM.
Comment 7 Andrew Savchenko gentoo-dev 2013-07-09 00:16:22 UTC
There is a good patch to start with here:
Comment 8 jannis 2013-07-09 05:28:40 UTC
Could you please modify the title to not include "app-laptop/tp_smapi-0.41"? This is a general issue for all externally compiled kernel modules.
Comment 9 Maxim Kammerer 2013-08-20 23:50:13 UTC
Note that the kernel build system ignores MODSECKEY / MODPUBKEY when building kernel/modsign_certificate.o, which contains the bundled verification certificate(s).

See kernel/Makefile:
  kernel/modsign_certificate.o: signing_key.x509 extra_certificates
  signing_key.priv signing_key.x509: x509.genkey

I have to do the following in order to use custom out-of-tree certificates:

if [ ! -e ${mainobj}/signing_key.x509 ]; then
    ln -s    ${sb_kmod}.der ${mainobj}/signing_key.x509
    ln -s    ${sb_kmod}.key ${mainobj}/signing_key.priv
    touch -d 1970-01-01     ${mainobj}/x509.genkey
    truncate -s 0           ${mainobj}/extra_certificates

(mainobj=kernel build dir, sb_kmod=out-of-tree cert prefix)

Note also that the following commit is probably necessary for using custom certificates in pre-3.10 kernels:
Comment 10 Ben Kohler gentoo-dev 2013-10-03 19:49:27 UTC
*** Bug 447356 has been marked as a duplicate of this bug. ***
Comment 11 Tom Wijsman (TomWij) (RETIRED) gentoo-dev 2014-04-04 12:51:18 UTC
(In reply to Andrew Savchenko from comment #7)

Has a revised version been posted since? CC'ing r3pek for comment.
Comment 12 Carlos Silva 2014-04-05 00:54:16 UTC
(In reply to Tom Wijsman (TomWij) from comment #11)
> (In reply to Andrew Savchenko from comment #7)
> >
> Has a revised version been posted since? CC'ing r3pek for comment.

No Tom, I did not work further on the patch.
Comment 13 Alex Xu (Hello71) 2016-08-31 02:01:03 UTC
*** Bug 592170 has been marked as a duplicate of this bug. ***
Comment 14 Mikhail Kurinnoi 2017-01-04 11:22:45 UTC
*** Bug 599708 has been marked as a duplicate of this bug. ***
Comment 15 Romain Perier 2018-04-20 06:33:13 UTC
Same as bug ?  (see the patch)
Comment 16 Georgy Yakovlev archtester gentoo-dev 2018-04-20 08:16:39 UTC
yup, working on it here:

hopefully it'll get approved sooner or later.
have been using it for a while now, it even works with forced signatures just fine.
Comment 17 Jeroen Roovers (RETIRED) gentoo-dev 2018-04-20 12:51:51 UTC
*** Bug 640216 has been marked as a duplicate of this bug. ***
Comment 18 Mike Pagano gentoo-dev 2023-01-01 18:39:35 UTC
*** Bug 881641 has been marked as a duplicate of this bug. ***
Comment 19 Larry the Git Cow gentoo-dev 2023-05-29 13:05:45 UTC
The bug has been referenced in the following commit(s):

commit d9687a4df038382187300d6f44230661ff5bc377
Author:     Ionen Wolkens <>
AuthorDate: 2023-05-23 09:25:02 +0000
Commit:     Ionen Wolkens <>
CommitDate: 2023-05-29 13:03:27 +0000

    linux-mod-r1.eclass: new eclass, rewrite of linux-mod.eclass
    Here's a rough overview of -r0 -> -r1 differences with occasional
    rationale behind them if felt relevant (for migrating, refer to
    the eclassdocs instead as this does not really document usage
    Features that did not exist in previous eclass (not exhaustive):
    * automatic modules signing support, been often requested and
      users would instead use messy bashrc hacks to accomplish this
     (enabled with USE=modules-sign)
    * modules (manual) stripping support to allow stripping *before*
      signing and compression
     (can be disabled with USE=-strip)
    * can auto-select toolchain to match kernel, e.g. if built with
      clang-15 then it won't use gcc nor clang-16 if possible
     (will warn if the matching compiler went missing)
    * helper functions to profit from the above 3 even if not using
      linux-mod-r1_src_compile+install (e.g. for zfs-kmod)
    * generic supported kernel version checks (min/max) which comes with
      an encouragement to use LTS kernels for out-of-tree modules
     (but max is not enforced, just makes a strong suggestion)
    * linux-mod-r1_src_install now does einstalldocs
    * can guess some common build targets rather than just 'module',
      largely removing the need for BUILD_TARGETS
    * user-oriented MODULES_EXTRA_EMAKE among other few variables
    * various additional sanity checks hopefully making issues
      clearer for users and ebuilds a bit harder to write wrong
    "Features" that existed but were not kept (not exhaustive):
    * support for <kernel-2.6(!) modules, eclass only tested with >=4.14.x
    * allowing doing all in global scope using variables ran through `eval`
     (this often led to all sort of variable misuse in global scope)
    * MODULESD_* support, originally meant to keep but it is used by only
      5 packages and holds very little meaning that I can see even in these
     (when needed, packages should write their own .conf)
    * moduledb, was being updated for nothing in postinst/postrm
      despite the tool that can use this (sys-kernel/module-rebuild)
      being gone from the tree since Feb 2014
    * convert_to_m(), only 1 in-tree ebuild uses this right now (svgalib)
    * various other functions with no consumers were dropped, some
      were likely meant to be @INTERNAL, get-KERNEL_CC was never used
      either and now there's ${KERNEL_CC}
    * running 'clean' by default, this sometime led to race conditions by
      attempting to clean and build at same time in e.g. nvidia-drivers
     (if an ebuild truly need this, it can be specified manually)
    * INSTALL_MOD_PATH support, this integrates badly with ebuilds that
      use it as DESTDIR with e.g. `make INSTALL_MOD_PATH="${ED}" install`
      or find "${ED}"/lib/modules, etc... requiring extra consideration
     (also feels inconsistent with how ebuilds normally work, the few
      concerned users may be interested by setting ROOT or manually moving
      files instead -- but support was missing until 2021 so it should
      have little impact)
    * BUILD_FIXES support, this is set by linux-info.eclass but has no
      real relevance that I can see (ebuilds have sometime wrongly used it)
    * undocumented feature CONFIG_CHECK="@CONFIG:modname" (or so?) meant
      for automagic based on kernel config is no longer supported, this
      also removes the also undocumented MODULE_IGNORE used by it (found
      0 ebuilds using these in the tree, can be done manually if needed)
    * converting CONFIG_CHECK to non-fatal for running again on binary
      merge when (while *possible*) it's rather unlikely would build
      modules for a different kernel than the one that will be used
    * having preinst and postrm exports, removed
      -> originally wanted to remove pkg_setup too but it complicated
         things with linux-info's own pkg_setup and made the eclass
         feel less convenient and error-prone with environment handling
    Dependency changes:
    * virtual/libelf DEPEND removed, building objtool (which uses this) is
      not handled by the eclass and does not seem auto-built by make if
      missing, as such the dependency is not used *here* but rather by
      dist-kernels and source packages which both already request it.
    * sys-apps/kmod[tools] BDEPEND+IDEPEND added, and removed from DEPEND
      (linux-mod-r0 uses it similarly but lacks the eapi7+8 adjustment)
    * modules-sign? ( dev-libs/openssl virtual/pkgconfig ) BDEPEND for
      building sign-file, unlike objtool it may need rebuilds for openssl
      and is handled here
    * dependencies are no longer guarded by "kernel_linux? ( )", it only
      served to silence pkgcheck and then give build failures (linux-only
      ebuilds should be masked on non-Linux profiles or, if mixed, use a
      masked MODULES_OPTIONAL_IUSE which *can* be kernel_linux).
    Tentative changes:
    * drop KERNEL_ABI support, (nowadays) kernel seems to append its own
      -m32/-m64 and should be no need for multilib.eclass complications
     (tested to work *at least* with x32[userland]+64bit[kernel])
    * ^ but add hppa2.0->64 kgcc64 switching like kernel-build.eclass
    * drop addpredict wrt bug #653286, assuming no longer relevant given
      unable to reproduce even with kernel-4.14.315+split-debug+some misc
      modules, perhaps would with spl but that (removed) ebuild is too
      broken to try
    Misc changes:
    * misc -> extra default install dir, to match the kernel's defaults
     (this is also where zfs-kmod already installs due to that default)
    Three bugs were addressed, but not closing given -r0 remains affected:
    * bug #447352: modules signing is supported
    * bug #759238: arguably not an issue anymore in -r0 either due to
      CHECKCONFIG_DONOTHING=1 (bug #862315) now existing, but -r1
      additionally makes it non-fatal if a whitelist exists in the kernel
    * bug #816024: trying to select toolchain better is a -r1 highlight
    Additionally, becomes WONTFIX in this version:
    * bug #642240: INSTALL_MOD_PATH support is reverted
    Signed-off-by: Ionen Wolkens <>

 eclass/linux-mod-r1.eclass | 1206 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 1206 insertions(+)
Comment 20 Mike Pagano gentoo-dev 2023-08-11 22:28:57 UTC
Signing is now supported in the linux-mod-r1.eclass