Recently, I ported a personal ebuild to use the kernel-build and kernel-install eclasses, instead of kernel-2. For my first ever build, I arranged for my existing .config, which has module signing enabled, to be imported by way of the savedconfig mechanism. After first booting the installed kernel, I was surprised to find the virtual console seemingly ignoring keyboard input and that I was unable to log in via sshd, but soon realised that no kernel modules had been loaded. The cause of this is that portage is allowed to strip the modules. As the help text for CONFIG_MODULE_SIG notes, this must not be allowed to happen. No doubt, electing to enable compressed modules would have allowed for them to escape the clutches of portage but there is no reason that a user should have to do so. For now, I elected to work around the problem by defining this in my ebuild: RESTRICT+=" preserve-libs splitdebug strip" The rationale there is that, for one thing, I do not want portage meddling with the binaries in any way and, for another, preserved-libs cannot serve any purpose for dist kernels (that I am aware of). Anyway, can the eclass please be fixed to allow for everyone to make use of signed, uncompressed modules?
I don't see how I could do that without disabling stripping that is desirable in the majority of cases. Given that the eclass doesn't support signing modules out of the box and you're creating your own ebuild anyway, I don't see why you find it so disagreeable to RESTRICT=strip in your own ebuild.
With all due respect, I found your response to be obtuse. It remains unexplained as to why stripping in-tree modules is desirable. What's genuinely disappointing, though, is the seizing of the fact that I produced my own ebuild as a means by which to dismiss the issue out of hand. Firstly, I don't just file bugs for my own benefit (it would be easier if I did). Secondly, and as should require no explaining, this issue could just as well affect anyone that wants to switch, say, from gentoo-sources [1] to gentoo-kernel while continuing to use a custom config. Given that you're the project lead, there is no need for me to explain the myriad benefits in doing so, as far as kernel management and deployment is concerned. Thirdly, enabling module signing without necessarily wanting to retain the key is a perfectly valid use case. Ultimately, what does it amount to? That a user cannot expect to be able to take a .config that was employed in the context of building a kernel in the old way, and be assured of a working kernel and modules in the context of the new way. If If that be your standpoint, I truly have to wonder what the point of offering USE=savedconfig is in the first place. [1] Speaking of which, if stripping in-tree modules outside the auspices of the kernel build system is so desirable, why are users of sys-kernel/*-sources not being directed to do so?
I'd appreciate a second opinion.
Reopening. As for second opinion on stripping overall - we should definitely strip by default. there are mechanisms to opt out for users and eclass consumers from that that are well known and work. no need to change. without stripping by default initrd sizes grow way way too large and can lead to quick size exhaustion if ESP partition is used to store kernel/initrd. On some systems (dual boot) users have no easy control over ESP partition and it's usually sized 500M or less. avg stripped kernel + initrd takes 40-80MB per kernel+initrd. unstripped it can be well over 200Mb, up to 300. so it may be not possible to install 2 kernels simultaneously. note, that dracut simply skips strip if modules are signed. we do not clean kernels by default, and can run into situation where users can not install kernel properly if another one is already installed. As for signing: We need to revisit this one as if we want to implement module signatures from being stripped then we need to sign AFTER stripping. Basically i wanted strip first, sign after So controlled callable strip can do it. Currently it’s unconditional after src_install fired(unless nostrip or dostrip -x) The latter just alters the list of files to strip, not actually prevents invoking strips on files) And signing after src_install ruins vdb checksums. I don't know any solution yet. it kinda works in post_src_install. portage strips things after src_install fired, then fires post_src_install (which we can't use in eclass) and then records checksums. so checksums in vdb are correct for signed files. so I believe if portage behavior is tuned to allow running something like post-strip - when we will just need to re-sign all modules in post-strip after being stripped. or alter kernel Kbuild to do stripping similar situation discussed for OE: https://lore.kernel.org/all/5e8c54728e6990907fa60f2454ab7961c7561a93.camel@linuxfoundation.org/T/
kernel has a Kbuild option INSTALL_MOD_STRIP https://github.com/torvalds/linux/blob/master/scripts/Makefile.modinst#L42 it does stripping before signing/compressing. if we use that instead of portage strip whole thing might work. it should definitely emulate support FEATURES=nostrip tho. it will not be able to support dostrip -x. currently we only rely on dostrip -x to prevent ppc64le vmlinux kernel from being stripped. but it's not installed by scripts/Makefile.modinst hence not subject to INSTALL_MOD_STRIP. WDYT?
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=09a8adc582e55ffc4521376c17ee8ad745a1fda0 commit 09a8adc582e55ffc4521376c17ee8ad745a1fda0 Author: Andrew Ammerlaan <andrewammerlaan@gentoo.org> AuthorDate: 2023-06-15 09:50:10 +0000 Commit: Andrew Ammerlaan <andrewammerlaan@gentoo.org> CommitDate: 2023-06-20 18:57:33 +0000 kernel-build.eclass: add IUSE="strip", install generated keys - Let the kernel build system handle stripping of the modules. This is necessary for successfully signing and compressing modules. Inspired by linux-mod-r1.eclass. - If the build system has generated keys or certificates, install them. This is required to successfully sign external kernel modules. Closes: https://bugs.gentoo.org/814344 Closes: https://bugs.gentoo.org/881651 Signed-off-by: Andrew Ammerlaan <andrewammerlaan@gentoo.org> eclass/kernel-build.eclass | 26 +++++++++++++++++++++++--- 1 file changed, 23 insertions(+), 3 deletions(-) Additionally, it has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=bcd3103426971497f634ddf12d535b3010e9138b commit bcd3103426971497f634ddf12d535b3010e9138b Author: Andrew Ammerlaan <andrewammerlaan@gentoo.org> AuthorDate: 2023-06-15 19:10:02 +0000 Commit: Andrew Ammerlaan <andrewammerlaan@gentoo.org> CommitDate: 2023-06-20 18:57:34 +0000 kernel-build.eclass: add IUSE="modules-sign" - Enable module signing configure options if requested by the user. - Define the user variables MODULES_SIGN_HASH and MODULES_SIGN_KEY. For controlling the used hashing algorithm and allowing the use of external keys. These variables are the same as in linux-mod-r1.eclass - Warn the user if we are letting the kernel build system generate the signing key. This key will end up binary packages. Plus external modules will have to be resigned if gentoo-kernel is re-emerged (i.e. a new key was generated). Bug: https://bugs.gentoo.org/814344 Bug: https://bugs.gentoo.org/881651 Signed-off-by: Andrew Ammerlaan <andrewammerlaan@gentoo.org> eclass/kernel-build.eclass | 90 +++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 89 insertions(+), 1 deletion(-)
Thank you for making this possible.
