Re: [gentoo-dev] [PATCH] linux-mod.eclass: support module signing

2022-07-05 Thread Mike Gilbert
On Tue, Jul 5, 2022 at 3:02 PM Georgy Yakovlev  wrote:
>
> ...snip
> >
> > > In that case, I think the only viable way to make this work is to
> > > disable automatic stripping and handle stripping via custom code in
> > > the ebuild/eclass.
> > >
> > might work indeed if we do something like (pseudo-bash)
> >
> > if [[ module_sign == yes ]]; then
> > dostrip -x /lib/modules # to stop portage stripping .ko objects
> > manual-strip-respecting-features-nostrip -r /lib/modules
> > sign-all-modules -r /lib/modules
> > fi
> > [[ compress_modules == yes ]] && compress-modules -r /lib/modules
> >
> >
> > this will equire eapi-bumping couple of packages
> > https://qa-reports.gentoo.org/output/eapi-per-eclass/linux-mod.eclass/6.txt
> > and restricting linux-mod.eclass to eapi7 or later.
> >
> >
> >
> started playing with my old code and got blocked right away:
>
> looks like dostrip just creates a list of files/directories to strip
> and processed at the very end of install phase.
>
> so skipping strip and doing manual one might be problematic.
> internally portage uses estrip
> https://github.com/gentoo/portage/blob/master/bin/estrip
> which contains quite a lot of logic and code and I don't think
> partially re-implementing this in eclass code is appropriate.
>

Looking at the kernel build system, it looks like modules don't get
stripped by default anyway: you have to explicitly pass
INSTALL_MOD_STRIP=1 to make modules_install.

I don't think it would be a major problem to just disable stripping
entirely for out-of-tree modules when module signing is enabled.

Alternatively, forget about trying to reimplement estrip and just
strip the files by calling ${STRIP} --strip-debug, as is done in
scripts/Makefile.modinst in the kernel sources. That will conflict
with FEATURES=splitdebug, but I doubt that's very useful for kernel
developers anyway.



Re: [gentoo-dev] [PATCH] linux-mod.eclass: support module signing

2022-07-05 Thread Kenton Groombridge
On 22/07/05 12:02PM, Georgy Yakovlev wrote:
> started playing with my old code and got blocked right away:
> 
> looks like dostrip just creates a list of files/directories to strip
> and processed at the very end of install phase.
> 
> so skipping strip and doing manual one might be problematic.
> internally portage uses estrip
> https://github.com/gentoo/portage/blob/master/bin/estrip
> which contains quite a lot of logic and code and I don't think
> partially re-implementing this in eclass code is appropriate.
> 

I agree I don't think it's appropriate. Would it make sense to be able
to provide an extra argument to dostrip in order to strip an object
*now* using the existing logic (and skip later stripping)? i.e.:

dostrip --now my_module.ko



Re: [gentoo-dev] [PATCH] linux-mod.eclass: support module signing

2022-07-05 Thread Georgy Yakovlev
...snip
> 
> > In that case, I think the only viable way to make this work is to
> > disable automatic stripping and handle stripping via custom code in
> > the ebuild/eclass.
> > 
> might work indeed if we do something like (pseudo-bash)
> 
> if [[ module_sign == yes ]]; then
>     dostrip -x /lib/modules # to stop portage stripping .ko objects
>     manual-strip-respecting-features-nostrip -r /lib/modules
>     sign-all-modules -r /lib/modules
> fi
> [[ compress_modules == yes ]] && compress-modules -r /lib/modules
> 
> 
> this will equire eapi-bumping couple of packages
> https://qa-reports.gentoo.org/output/eapi-per-eclass/linux-mod.eclass/6.txt
> and restricting linux-mod.eclass to eapi7 or later.
> 
> 
> 
started playing with my old code and got blocked right away:

looks like dostrip just creates a list of files/directories to strip
and processed at the very end of install phase.

so skipping strip and doing manual one might be problematic.
internally portage uses estrip
https://github.com/gentoo/portage/blob/master/bin/estrip
which contains quite a lot of logic and code and I don't think
partially re-implementing this in eclass code is appropriate.



Re: [gentoo-dev] [PATCH] linux-mod.eclass: support module signing

2022-06-27 Thread Georgy Yakovlev
On Mon, 2022-06-27 at 17:50 -0400, Mike Gilbert wrote:
> On Mon, Jun 27, 2022 at 5:11 PM Georgy Yakovlev
>  wrote:
> > 
> > On Mon, 2022-06-27 at 15:49 -0400, Mike Gilbert wrote:
> > > On Mon, Jun 27, 2022 at 3:42 PM Georgy Yakovlev
> > >  wrote:
> > > > 
> > > > On Mon, 2022-06-27 at 14:56 -0400, Mike Gilbert wrote:
> > > > > On Mon, Jun 27, 2022 at 2:35 PM Kenton Groombridge
> > > > >  wrote:
> > > > > > > so looks like we need to combine both methods and do the
> > > > > > > following:
> > > > > > >  - if signing requested without compression - sign in
> > > > > > > pkg_preinst.
> > > > > > >  - if signing requested with compression - sign in
> > > > > > > src_install
> > > > > > > 
> > > > > > 
> > > > > > Why can't we do both in pkg_preinst? I am thinking it would
> > > > > > be
> > > > > > best
> > > > > > if
> > > > > > we drop the current compression implementation and rework
> > > > > > your
> > > > > > old
> > > > > > code
> > > > > > to handle both compression and signing since the signing
> > > > > > code
> > > > > > is
> > > > > > more or
> > > > > > less already complete.
> > > > > 
> > > > > Signing modules in pkg_preinst seems like a bad idea to me.
> > > > > That
> > > > > means
> > > > > you need to copy your private keys around to every host where
> > > > > the
> > > > > package might be installed.
> > > > > 
> > > > > If you sign in src_compile or src_install, you only need
> > > > > private
> > > > > keys
> > > > > on the system building your binpkg.
> > > > > 
> > > > 
> > > > unfortunately portage will unconditionally strip .ko objects,
> > > > rendering
> > > > modules unloadable by stripping signature,  unless we do
> > > > dostrip -x
> > > > (requires EAPI7+, which should not be a problem nowadays, but
> > > > was a
> > > > problem back in 2018), which can be quite unfortunate on debug
> > > > enabled
> > > > kernels.
> > > 
> > > Sounds like something to fix/change in Portage. It could probably
> > > be
> > > updated to not strip the signature. However, I would guess the
> > > signature needs to be updated after the binary is modified in any
> > > case.
> > > 
> > > Or as a workaround you could disable automatic striping via
> > > dostrip -
> > > x
> > > and run the proper commands to strip the modules in src_install
> > > as
> > > well.
> > > 
> > I think even strip itself does not have proper options not to break
> > module. Several years back it was the case, basically one has to
> > strip
> > first, sign second, otherwise module will be unloadable.
> > 
> > "Signed modules are BRITTLE as the signature is outside of the
> > defined
> > ELF container. Thus they MAY NOT be stripped once the signature is
> > computed and attached. Note the entire module is the signed
> > payload,
> > including any and all debug information present at the time of
> > signing."
> > 
> > https://www.kernel.org/doc/html/v4.15/admin-guide/module-signing.html#signed-modules-and-stripping
> > 
> 
> In that case, I think the only viable way to make this work is to
> disable automatic stripping and handle stripping via custom code in
> the ebuild/eclass.
> 
might work indeed if we do something like (pseudo-bash)

if [[ module_sign == yes ]]; then
dostrip -x /lib/modules # to stop portage stripping .ko objects
manual-strip-respecting-features-nostrip -r /lib/modules
sign-all-modules -r /lib/modules
fi
[[ compress_modules == yes ]] && compress-modules -r /lib/modules


this will equire eapi-bumping couple of packages
https://qa-reports.gentoo.org/output/eapi-per-eclass/linux-mod.eclass/6.txt
and restricting linux-mod.eclass to eapi7 or later.





Re: [gentoo-dev] [PATCH] linux-mod.eclass: support module signing

2022-06-27 Thread Mike Gilbert
On Mon, Jun 27, 2022 at 5:11 PM Georgy Yakovlev  wrote:
>
> On Mon, 2022-06-27 at 15:49 -0400, Mike Gilbert wrote:
> > On Mon, Jun 27, 2022 at 3:42 PM Georgy Yakovlev
> >  wrote:
> > >
> > > On Mon, 2022-06-27 at 14:56 -0400, Mike Gilbert wrote:
> > > > On Mon, Jun 27, 2022 at 2:35 PM Kenton Groombridge
> > > >  wrote:
> > > > > > so looks like we need to combine both methods and do the
> > > > > > following:
> > > > > >  - if signing requested without compression - sign in
> > > > > > pkg_preinst.
> > > > > >  - if signing requested with compression - sign in
> > > > > > src_install
> > > > > >
> > > > >
> > > > > Why can't we do both in pkg_preinst? I am thinking it would be
> > > > > best
> > > > > if
> > > > > we drop the current compression implementation and rework your
> > > > > old
> > > > > code
> > > > > to handle both compression and signing since the signing code
> > > > > is
> > > > > more or
> > > > > less already complete.
> > > >
> > > > Signing modules in pkg_preinst seems like a bad idea to me. That
> > > > means
> > > > you need to copy your private keys around to every host where the
> > > > package might be installed.
> > > >
> > > > If you sign in src_compile or src_install, you only need private
> > > > keys
> > > > on the system building your binpkg.
> > > >
> > >
> > > unfortunately portage will unconditionally strip .ko objects,
> > > rendering
> > > modules unloadable by stripping signature,  unless we do dostrip -x
> > > (requires EAPI7+, which should not be a problem nowadays, but was a
> > > problem back in 2018), which can be quite unfortunate on debug
> > > enabled
> > > kernels.
> >
> > Sounds like something to fix/change in Portage. It could probably be
> > updated to not strip the signature. However, I would guess the
> > signature needs to be updated after the binary is modified in any
> > case.
> >
> > Or as a workaround you could disable automatic striping via dostrip -
> > x
> > and run the proper commands to strip the modules in src_install as
> > well.
> >
> I think even strip itself does not have proper options not to break
> module. Several years back it was the case, basically one has to strip
> first, sign second, otherwise module will be unloadable.
>
> "Signed modules are BRITTLE as the signature is outside of the defined
> ELF container. Thus they MAY NOT be stripped once the signature is
> computed and attached. Note the entire module is the signed payload,
> including any and all debug information present at the time of
> signing."
>
> https://www.kernel.org/doc/html/v4.15/admin-guide/module-signing.html#signed-modules-and-stripping
>

In that case, I think the only viable way to make this work is to
disable automatic stripping and handle stripping via custom code in
the ebuild/eclass.



Re: [gentoo-dev] [PATCH] linux-mod.eclass: support module signing

2022-06-27 Thread Georgy Yakovlev
On Mon, 2022-06-27 at 16:02 -0400, Kenton Groombridge wrote:
> > > Why can't we do both in pkg_preinst? I am thinking it would be
> > > best
> > > if
> > > we drop the current compression implementation and rework your
> > > old
> > > code
> > > to handle both compression and signing since the signing code is
> > > more
> > > or
> > > less already complete.
> > 
> > i'm not sure if sign-file can sign compressed modules.
> 
> sign-file will not error when signing a compressed module, but the
> kernel will not be able to load it.

so we pretty much HAVE to strip->sign->compress, strictly in this
order. nothing else will work.

> 
> > if we let kernel build handle compression - we have to sign prior
> > to
> > compression.
> > if we compress modules ourselves then yes, we could sign first
> > indeed.
> > 
> > but preinst has it's own issues, you've already seen floppym's
> > remark.
> > 




Re: [gentoo-dev] [PATCH] linux-mod.eclass: support module signing

2022-06-27 Thread Georgy Yakovlev
On Mon, 2022-06-27 at 15:49 -0400, Mike Gilbert wrote:
> On Mon, Jun 27, 2022 at 3:42 PM Georgy Yakovlev
>  wrote:
> > 
> > On Mon, 2022-06-27 at 14:56 -0400, Mike Gilbert wrote:
> > > On Mon, Jun 27, 2022 at 2:35 PM Kenton Groombridge
> > >  wrote:
> > > > > so looks like we need to combine both methods and do the
> > > > > following:
> > > > >  - if signing requested without compression - sign in
> > > > > pkg_preinst.
> > > > >  - if signing requested with compression - sign in
> > > > > src_install
> > > > > 
> > > > 
> > > > Why can't we do both in pkg_preinst? I am thinking it would be
> > > > best
> > > > if
> > > > we drop the current compression implementation and rework your
> > > > old
> > > > code
> > > > to handle both compression and signing since the signing code
> > > > is
> > > > more or
> > > > less already complete.
> > > 
> > > Signing modules in pkg_preinst seems like a bad idea to me. That
> > > means
> > > you need to copy your private keys around to every host where the
> > > package might be installed.
> > > 
> > > If you sign in src_compile or src_install, you only need private
> > > keys
> > > on the system building your binpkg.
> > > 
> > 
> > unfortunately portage will unconditionally strip .ko objects,
> > rendering
> > modules unloadable by stripping signature,  unless we do dostrip -x
> > (requires EAPI7+, which should not be a problem nowadays, but was a
> > problem back in 2018), which can be quite unfortunate on debug
> > enabled
> > kernels.
> 
> Sounds like something to fix/change in Portage. It could probably be
> updated to not strip the signature. However, I would guess the
> signature needs to be updated after the binary is modified in any
> case.
> 
> Or as a workaround you could disable automatic striping via dostrip -
> x
> and run the proper commands to strip the modules in src_install as
> well.
> 
I think even strip itself does not have proper options not to break
module. Several years back it was the case, basically one has to strip
first, sign second, otherwise module will be unloadable.

"Signed modules are BRITTLE as the signature is outside of the defined
ELF container. Thus they MAY NOT be stripped once the signature is
computed and attached. Note the entire module is the signed payload,
including any and all debug information present at the time of
signing."

https://www.kernel.org/doc/html/v4.15/admin-guide/module-signing.html#signed-modules-and-stripping



Re: [gentoo-dev] [PATCH] linux-mod.eclass: support module signing

2022-06-27 Thread Kenton Groombridge
> > Why can't we do both in pkg_preinst? I am thinking it would be best
> > if
> > we drop the current compression implementation and rework your old
> > code
> > to handle both compression and signing since the signing code is more
> > or
> > less already complete.
> 
> i'm not sure if sign-file can sign compressed modules.

sign-file will not error when signing a compressed module, but the
kernel will not be able to load it.

> if we let kernel build handle compression - we have to sign prior to
> compression.
> if we compress modules ourselves then yes, we could sign first indeed.
> 
> but preinst has it's own issues, you've already seen floppym's remark.
> 


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] linux-mod.eclass: support module signing

2022-06-27 Thread Mike Gilbert
On Mon, Jun 27, 2022 at 3:42 PM Georgy Yakovlev  wrote:
>
> On Mon, 2022-06-27 at 14:56 -0400, Mike Gilbert wrote:
> > On Mon, Jun 27, 2022 at 2:35 PM Kenton Groombridge
> >  wrote:
> > > > so looks like we need to combine both methods and do the
> > > > following:
> > > >  - if signing requested without compression - sign in
> > > > pkg_preinst.
> > > >  - if signing requested with compression - sign in src_install
> > > >
> > >
> > > Why can't we do both in pkg_preinst? I am thinking it would be best
> > > if
> > > we drop the current compression implementation and rework your old
> > > code
> > > to handle both compression and signing since the signing code is
> > > more or
> > > less already complete.
> >
> > Signing modules in pkg_preinst seems like a bad idea to me. That
> > means
> > you need to copy your private keys around to every host where the
> > package might be installed.
> >
> > If you sign in src_compile or src_install, you only need private keys
> > on the system building your binpkg.
> >
>
> unfortunately portage will unconditionally strip .ko objects, rendering
> modules unloadable by stripping signature,  unless we do dostrip -x
> (requires EAPI7+, which should not be a problem nowadays, but was a
> problem back in 2018), which can be quite unfortunate on debug enabled
> kernels.

Sounds like something to fix/change in Portage. It could probably be
updated to not strip the signature. However, I would guess the
signature needs to be updated after the binary is modified in any
case.

Or as a workaround you could disable automatic striping via dostrip -x
and run the proper commands to strip the modules in src_install as
well.



Re: [gentoo-dev] [PATCH] linux-mod.eclass: support module signing

2022-06-27 Thread Georgy Yakovlev
On Mon, 2022-06-27 at 14:35 -0400, Kenton Groombridge wrote:
> On 22/06/26 04:15AM, Georgy Yakovlev wrote:
> > On Sun, 2022-06-26 at 03:52 -0700, Georgy Yakovlev wrote:
> > > On Tue, 2022-06-21 at 14:19 -0400, Kenton Groombridge wrote:
> > > > eee74b9fca1 adds support for module compression, but this
> > > > breaks
> > > > loading
> > > > out of tree modules when module signing is enforced because
> > > > modules
> > > > must
> > > > be signed before they are compressed. Additionally, the
> > > > recommended
> > > > Portage hook[1] no longer works with this change.
> > > > 
> > > > Add module signing support in linux-mod.eclass which more or
> > > > less
> > > > does
> > > > exactly what the aforementioned Portage hook does. If the
> > > > kernel
> > > > configuration has CONFIG_MODULE_SIG_ALL=y, then read the hash
> > > > and
> > > > keys
> > > > from the kernel configuration and call the sign_file tool to
> > > > sign
> > > > the
> > > > module before it is compressed.
> > > > 
> > > > Bug: https://bugs.gentoo.org/show_bug.cgi?id=447352
> > > > Signed-off-by: Kenton Groombridge 
> > > > ---
> > > >  eclass/linux-mod.eclass | 16 
> > > >  1 file changed, 16 insertions(+)
> > > > 
> > > > diff --git a/eclass/linux-mod.eclass b/eclass/linux-mod.eclass
> > > > index b7c13cbf7e7..fd40f6d7c6c 100644
> > > > --- a/eclass/linux-mod.eclass
> > > > +++ b/eclass/linux-mod.eclass
> > > > @@ -712,6 +712,22 @@ linux-mod_src_install() {
> > > > cd "${objdir}" || die "${objdir} does not
> > > > exist"
> > > > insinto
> > > > "${INSTALL_MOD_PATH}"/lib/modules/${KV_FULL}/${libdir}
> > > >  
> > > > +   # check here for CONFIG_MODULE_SIG_ALL and sign
> > > > the
> > > > module being built if enabled.
> > > > +   # modules must be signed before they are
> > > > compressed.
> > > > +
> > > > +   if linux_chkconfig_present MODULE_SIG_ALL; then
> > > > +   local
> > > > module_sig_hash="$(linux_chkconfig_string MODULE_SIG_HASH)"
> > > > +   local
> > > > module_sig_key="$(linux_chkconfig_string MODULE_SIG_KEY)"
> > > > +   module_sig_key="${module_sig_key:-
> > > > certs/signing_key.pem}"
> > > > +   if [[ "${module_sig_key#pkcs11:}" ==
> > > > "${module_sig_key}" && "${module_sig_key#/}" ==
> > > > "${module_sig_key}"
> > > > ]]; then
> > > > +   local
> > > > key_path="${KERNEL_DIR}/${module_sig_key}"
> > > > +   else
> > > > +   local
> > > > key_path="${module_sig_key}"
> > > > +   fi
> > > > +   local
> > > > cert_path="${KERNEL_DIR}/certs/signing_key.x509"
> > > > +   "${KERNEL_DIR}"/scripts/sign-file
> > > > ${module_sig_hash//\"} ${key_path//\"} ${cert_path}
> > > > ${modulename}.${KV_OBJ}
> > > > +   fi
> > > > +
> > > > # check here for
> > > > CONFIG_MODULE_COMPRESS_ > > > option> (NONE, GZIP, XZ, ZSTD) 
> > > > # and similarily compress the module being
> > > > built if
> > > > != NONE.
> > > >  
> > > 
> > > 
> > > Hi,
> > > 
> > > I've spent some time in the past ( circa 2018 ) to get this in,
> > > but 
> > > gave up due to various reasons, I was not a gentoo dev yet at the
> > > time.
> > > 
> > > I can't see how posted implementation will work tbh.
> > > portage will strip signature out of the module, unless you
> > > prevent
> > > stripping completely or package uses EAPI>=7, and omits stripping
> > > modules via dostrip -x on the ko object.
> > > kernel will NOT load module with stripped signature.
> > > 
> > > so either you have to sign in pkg_postinst phase, or prevent
> > > stripping.
> > > signing in postinst is not ideal, because if breaks recorded file
> > > checksums in vdb.
> > > 
> > > here's old fork of eclass I made, maybe you can find some helpful
> > > code
> > > in there
> > > 
> > > https://github.com/gyakovlev/linux-mod.eclass/blob/master/linux-mod.eclass
> > > 
> > > old ML discussion we had:
> > > https://archives.gentoo.org/gentoo-dev/message/4b15b1c851f379a1f802e2f2895cdfa8
> > > 
> > > You will also need a dependency on openssl, since sign-file uses
> > > it.
> > > 
> > > lmk if you need more info, I might remember more details, but for
> > > now
> > > that's all I have. I'll try to help get it done, but my
> > > availability
> > > is
> > > spotty due to limited time.
> > 
> > after reading my old code again and thinking more I think I know
> > what's
> > going on.
> >  1. I've actually solved checksum/strip problem by signing in pkg-
> > preinst
> >  2. my method will likely fail with compressed modules.
> >  3. your method likely works only if modules are compressed -
> > because
> > portage does not strip those I think.
> > 
> 
> This is exactly what I was thinking. I'm pretty sure I wasn't seeing
> the
> problematic signature stripping behavior 

Re: [gentoo-dev] [PATCH] linux-mod.eclass: support module signing

2022-06-27 Thread Georgy Yakovlev
On Mon, 2022-06-27 at 14:56 -0400, Mike Gilbert wrote:
> On Mon, Jun 27, 2022 at 2:35 PM Kenton Groombridge
>  wrote:
> > > so looks like we need to combine both methods and do the
> > > following:
> > >  - if signing requested without compression - sign in
> > > pkg_preinst.
> > >  - if signing requested with compression - sign in src_install
> > > 
> > 
> > Why can't we do both in pkg_preinst? I am thinking it would be best
> > if
> > we drop the current compression implementation and rework your old
> > code
> > to handle both compression and signing since the signing code is
> > more or
> > less already complete.
> 
> Signing modules in pkg_preinst seems like a bad idea to me. That
> means
> you need to copy your private keys around to every host where the
> package might be installed.
> 
> If you sign in src_compile or src_install, you only need private keys
> on the system building your binpkg.
> 

unfortunately portage will unconditionally strip .ko objects, rendering
modules unloadable by stripping signature,  unless we do dostrip -x
(requires EAPI7+, which should not be a problem nowadays, but was a
problem back in 2018), which can be quite unfortunate on debug enabled
kernels.



Re: [gentoo-dev] [PATCH] linux-mod.eclass: support module signing

2022-06-27 Thread Kenton Groombridge
On 22/06/27 02:56PM, Mike Gilbert wrote:
> On Mon, Jun 27, 2022 at 2:35 PM Kenton Groombridge  wrote:
> > > so looks like we need to combine both methods and do the following:
> > >  - if signing requested without compression - sign in pkg_preinst.
> > >  - if signing requested with compression - sign in src_install
> > >
> >
> > Why can't we do both in pkg_preinst? I am thinking it would be best if
> > we drop the current compression implementation and rework your old code
> > to handle both compression and signing since the signing code is more or
> > less already complete.
> 
> Signing modules in pkg_preinst seems like a bad idea to me. That means
> you need to copy your private keys around to every host where the
> package might be installed.
> 
> If you sign in src_compile or src_install, you only need private keys
> on the system building your binpkg.
> 

Ah that makes sense. I think the question then is whether or not
building binpkgs for kernel modules where the target system has its own
signing keys is something we want to support.

With that in mind I realize that doing compression in pkg_preinst means
that target systems can use different compression methods (or no
compression at all) if desired without much complication.


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] linux-mod.eclass: support module signing

2022-06-27 Thread Mike Gilbert
On Mon, Jun 27, 2022 at 2:35 PM Kenton Groombridge  wrote:
> > so looks like we need to combine both methods and do the following:
> >  - if signing requested without compression - sign in pkg_preinst.
> >  - if signing requested with compression - sign in src_install
> >
>
> Why can't we do both in pkg_preinst? I am thinking it would be best if
> we drop the current compression implementation and rework your old code
> to handle both compression and signing since the signing code is more or
> less already complete.

Signing modules in pkg_preinst seems like a bad idea to me. That means
you need to copy your private keys around to every host where the
package might be installed.

If you sign in src_compile or src_install, you only need private keys
on the system building your binpkg.



Re: [gentoo-dev] [PATCH] linux-mod.eclass: support module signing

2022-06-27 Thread Kenton Groombridge
On 22/06/26 04:15AM, Georgy Yakovlev wrote:
> On Sun, 2022-06-26 at 03:52 -0700, Georgy Yakovlev wrote:
> > On Tue, 2022-06-21 at 14:19 -0400, Kenton Groombridge wrote:
> > > eee74b9fca1 adds support for module compression, but this breaks
> > > loading
> > > out of tree modules when module signing is enforced because modules
> > > must
> > > be signed before they are compressed. Additionally, the recommended
> > > Portage hook[1] no longer works with this change.
> > > 
> > > Add module signing support in linux-mod.eclass which more or less
> > > does
> > > exactly what the aforementioned Portage hook does. If the kernel
> > > configuration has CONFIG_MODULE_SIG_ALL=y, then read the hash and
> > > keys
> > > from the kernel configuration and call the sign_file tool to sign
> > > the
> > > module before it is compressed.
> > > 
> > > Bug: https://bugs.gentoo.org/show_bug.cgi?id=447352
> > > Signed-off-by: Kenton Groombridge 
> > > ---
> > >  eclass/linux-mod.eclass | 16 
> > >  1 file changed, 16 insertions(+)
> > > 
> > > diff --git a/eclass/linux-mod.eclass b/eclass/linux-mod.eclass
> > > index b7c13cbf7e7..fd40f6d7c6c 100644
> > > --- a/eclass/linux-mod.eclass
> > > +++ b/eclass/linux-mod.eclass
> > > @@ -712,6 +712,22 @@ linux-mod_src_install() {
> > > cd "${objdir}" || die "${objdir} does not exist"
> > > insinto
> > > "${INSTALL_MOD_PATH}"/lib/modules/${KV_FULL}/${libdir}
> > >  
> > > +   # check here for CONFIG_MODULE_SIG_ALL and sign the
> > > module being built if enabled.
> > > +   # modules must be signed before they are
> > > compressed.
> > > +
> > > +   if linux_chkconfig_present MODULE_SIG_ALL; then
> > > +   local
> > > module_sig_hash="$(linux_chkconfig_string MODULE_SIG_HASH)"
> > > +   local
> > > module_sig_key="$(linux_chkconfig_string MODULE_SIG_KEY)"
> > > +   module_sig_key="${module_sig_key:-
> > > certs/signing_key.pem}"
> > > +   if [[ "${module_sig_key#pkcs11:}" ==
> > > "${module_sig_key}" && "${module_sig_key#/}" == "${module_sig_key}"
> > > ]]; then
> > > +   local
> > > key_path="${KERNEL_DIR}/${module_sig_key}"
> > > +   else
> > > +   local key_path="${module_sig_key}"
> > > +   fi
> > > +   local
> > > cert_path="${KERNEL_DIR}/certs/signing_key.x509"
> > > +   "${KERNEL_DIR}"/scripts/sign-file
> > > ${module_sig_hash//\"} ${key_path//\"} ${cert_path}
> > > ${modulename}.${KV_OBJ}
> > > +   fi
> > > +
> > > # check here for
> > > CONFIG_MODULE_COMPRESS_ > > option> (NONE, GZIP, XZ, ZSTD) 
> > > # and similarily compress the module being built if
> > > != NONE.
> > >  
> > 
> > 
> > Hi,
> > 
> > I've spent some time in the past ( circa 2018 ) to get this in, but 
> > gave up due to various reasons, I was not a gentoo dev yet at the
> > time.
> > 
> > I can't see how posted implementation will work tbh.
> > portage will strip signature out of the module, unless you prevent
> > stripping completely or package uses EAPI>=7, and omits stripping
> > modules via dostrip -x on the ko object.
> > kernel will NOT load module with stripped signature.
> > 
> > so either you have to sign in pkg_postinst phase, or prevent
> > stripping.
> > signing in postinst is not ideal, because if breaks recorded file
> > checksums in vdb.
> > 
> > here's old fork of eclass I made, maybe you can find some helpful
> > code
> > in there
> > 
> > https://github.com/gyakovlev/linux-mod.eclass/blob/master/linux-mod.eclass
> > 
> > old ML discussion we had:
> > https://archives.gentoo.org/gentoo-dev/message/4b15b1c851f379a1f802e2f2895cdfa8
> > 
> > You will also need a dependency on openssl, since sign-file uses it.
> > 
> > lmk if you need more info, I might remember more details, but for now
> > that's all I have. I'll try to help get it done, but my availability
> > is
> > spotty due to limited time.
> 
> after reading my old code again and thinking more I think I know what's
> going on.
>  1. I've actually solved checksum/strip problem by signing in pkg-
> preinst
>  2. my method will likely fail with compressed modules.
>  3. your method likely works only if modules are compressed - because
> portage does not strip those I think.
> 

This is exactly what I was thinking. I'm pretty sure I wasn't seeing the
problematic signature stripping behavior because I have module
compression enabled.

Also good point about the OpenSSL dependency. That's something I didn't
consider.

> so looks like we need to combine both methods and do the following:
>  - if signing requested without compression - sign in pkg_preinst.
>  - if signing requested with compression - sign in src_install
> 

Why can't we do both in pkg_preinst? I am thinking it would be best if
we drop the 

Re: [gentoo-dev] [PATCH] linux-mod.eclass: support module signing

2022-06-26 Thread Georgy Yakovlev
On Sun, 2022-06-26 at 03:52 -0700, Georgy Yakovlev wrote:
> On Tue, 2022-06-21 at 14:19 -0400, Kenton Groombridge wrote:
> > eee74b9fca1 adds support for module compression, but this breaks
> > loading
> > out of tree modules when module signing is enforced because modules
> > must
> > be signed before they are compressed. Additionally, the recommended
> > Portage hook[1] no longer works with this change.
> > 
> > Add module signing support in linux-mod.eclass which more or less
> > does
> > exactly what the aforementioned Portage hook does. If the kernel
> > configuration has CONFIG_MODULE_SIG_ALL=y, then read the hash and
> > keys
> > from the kernel configuration and call the sign_file tool to sign
> > the
> > module before it is compressed.
> > 
> > Bug: https://bugs.gentoo.org/show_bug.cgi?id=447352
> > Signed-off-by: Kenton Groombridge 
> > ---
> >  eclass/linux-mod.eclass | 16 
> >  1 file changed, 16 insertions(+)
> > 
> > diff --git a/eclass/linux-mod.eclass b/eclass/linux-mod.eclass
> > index b7c13cbf7e7..fd40f6d7c6c 100644
> > --- a/eclass/linux-mod.eclass
> > +++ b/eclass/linux-mod.eclass
> > @@ -712,6 +712,22 @@ linux-mod_src_install() {
> > cd "${objdir}" || die "${objdir} does not exist"
> > insinto
> > "${INSTALL_MOD_PATH}"/lib/modules/${KV_FULL}/${libdir}
> >  
> > +   # check here for CONFIG_MODULE_SIG_ALL and sign the
> > module being built if enabled.
> > +   # modules must be signed before they are
> > compressed.
> > +
> > +   if linux_chkconfig_present MODULE_SIG_ALL; then
> > +   local
> > module_sig_hash="$(linux_chkconfig_string MODULE_SIG_HASH)"
> > +   local
> > module_sig_key="$(linux_chkconfig_string MODULE_SIG_KEY)"
> > +   module_sig_key="${module_sig_key:-
> > certs/signing_key.pem}"
> > +   if [[ "${module_sig_key#pkcs11:}" ==
> > "${module_sig_key}" && "${module_sig_key#/}" == "${module_sig_key}"
> > ]]; then
> > +   local
> > key_path="${KERNEL_DIR}/${module_sig_key}"
> > +   else
> > +   local key_path="${module_sig_key}"
> > +   fi
> > +   local
> > cert_path="${KERNEL_DIR}/certs/signing_key.x509"
> > +   "${KERNEL_DIR}"/scripts/sign-file
> > ${module_sig_hash//\"} ${key_path//\"} ${cert_path}
> > ${modulename}.${KV_OBJ}
> > +   fi
> > +
> > # check here for
> > CONFIG_MODULE_COMPRESS_ > option> (NONE, GZIP, XZ, ZSTD) 
> > # and similarily compress the module being built if
> > != NONE.
> >  
> 
> 
> Hi,
> 
> I've spent some time in the past ( circa 2018 ) to get this in, but 
> gave up due to various reasons, I was not a gentoo dev yet at the
> time.
> 
> I can't see how posted implementation will work tbh.
> portage will strip signature out of the module, unless you prevent
> stripping completely or package uses EAPI>=7, and omits stripping
> modules via dostrip -x on the ko object.
> kernel will NOT load module with stripped signature.
> 
> so either you have to sign in pkg_postinst phase, or prevent
> stripping.
> signing in postinst is not ideal, because if breaks recorded file
> checksums in vdb.
> 
> here's old fork of eclass I made, maybe you can find some helpful
> code
> in there
> 
> https://github.com/gyakovlev/linux-mod.eclass/blob/master/linux-mod.eclass
> 
> old ML discussion we had:
> https://archives.gentoo.org/gentoo-dev/message/4b15b1c851f379a1f802e2f2895cdfa8
> 
> You will also need a dependency on openssl, since sign-file uses it.
> 
> lmk if you need more info, I might remember more details, but for now
> that's all I have. I'll try to help get it done, but my availability
> is
> spotty due to limited time.

after reading my old code again and thinking more I think I know what's
going on.
 1. I've actually solved checksum/strip problem by signing in pkg-
preinst
 2. my method will likely fail with compressed modules.
 3. your method likely works only if modules are compressed - because
portage does not strip those I think.

so looks like we need to combine both methods and do the following:
 - if signing requested without compression - sign in pkg_preinst.
 - if signing requested with compression - sign in src_install

Do I make sense? I still haven't tested it, just guessing as I read my
old bash code.



Re: [gentoo-dev] [PATCH] linux-mod.eclass: support module signing

2022-06-26 Thread Georgy Yakovlev
On Tue, 2022-06-21 at 14:19 -0400, Kenton Groombridge wrote:
> eee74b9fca1 adds support for module compression, but this breaks
> loading
> out of tree modules when module signing is enforced because modules
> must
> be signed before they are compressed. Additionally, the recommended
> Portage hook[1] no longer works with this change.
> 
> Add module signing support in linux-mod.eclass which more or less
> does
> exactly what the aforementioned Portage hook does. If the kernel
> configuration has CONFIG_MODULE_SIG_ALL=y, then read the hash and
> keys
> from the kernel configuration and call the sign_file tool to sign the
> module before it is compressed.
> 
> Bug: https://bugs.gentoo.org/show_bug.cgi?id=447352
> Signed-off-by: Kenton Groombridge 
> ---
>  eclass/linux-mod.eclass | 16 
>  1 file changed, 16 insertions(+)
> 
> diff --git a/eclass/linux-mod.eclass b/eclass/linux-mod.eclass
> index b7c13cbf7e7..fd40f6d7c6c 100644
> --- a/eclass/linux-mod.eclass
> +++ b/eclass/linux-mod.eclass
> @@ -712,6 +712,22 @@ linux-mod_src_install() {
> cd "${objdir}" || die "${objdir} does not exist"
> insinto
> "${INSTALL_MOD_PATH}"/lib/modules/${KV_FULL}/${libdir}
>  
> +   # check here for CONFIG_MODULE_SIG_ALL and sign the
> module being built if enabled.
> +   # modules must be signed before they are compressed.
> +
> +   if linux_chkconfig_present MODULE_SIG_ALL; then
> +   local
> module_sig_hash="$(linux_chkconfig_string MODULE_SIG_HASH)"
> +   local
> module_sig_key="$(linux_chkconfig_string MODULE_SIG_KEY)"
> +   module_sig_key="${module_sig_key:-
> certs/signing_key.pem}"
> +   if [[ "${module_sig_key#pkcs11:}" ==
> "${module_sig_key}" && "${module_sig_key#/}" == "${module_sig_key}"
> ]]; then
> +   local
> key_path="${KERNEL_DIR}/${module_sig_key}"
> +   else
> +   local key_path="${module_sig_key}"
> +   fi
> +   local
> cert_path="${KERNEL_DIR}/certs/signing_key.x509"
> +   "${KERNEL_DIR}"/scripts/sign-file
> ${module_sig_hash//\"} ${key_path//\"} ${cert_path}
> ${modulename}.${KV_OBJ}
> +   fi
> +
> # check here for CONFIG_MODULE_COMPRESS_ option> (NONE, GZIP, XZ, ZSTD) 
> # and similarily compress the module being built if
> != NONE.
>  


Hi,

I've spent some time in the past ( circa 2018 ) to get this in, but 
gave up due to various reasons, I was not a gentoo dev yet at the time.

I can't see how posted implementation will work tbh.
portage will strip signature out of the module, unless you prevent
stripping completely or package uses EAPI>=7, and omits stripping
modules via dostrip -x on the ko object.
kernel will NOT load module with stripped signature.

so either you have to sign in pkg_postinst phase, or prevent stripping.
signing in postinst is not ideal, because if breaks recorded file
checksums in vdb.

here's old fork of eclass I made, maybe you can find some helpful code
in there

https://github.com/gyakovlev/linux-mod.eclass/blob/master/linux-mod.eclass

old ML discussion we had:
https://archives.gentoo.org/gentoo-dev/message/4b15b1c851f379a1f802e2f2895cdfa8

You will also need a dependency on openssl, since sign-file uses it.

lmk if you need more info, I might remember more details, but for now
that's all I have. I'll try to help get it done, but my availability is
spotty due to limited time.


Re: [gentoo-dev] [PATCH] linux-mod.eclass: support module signing

2022-06-23 Thread Kenton Groombridge
On 22/06/23 08:51AM, Mike Pagano wrote:
> On 6/21/22 14:21, Kenton Groombridge wrote:
> > On 22/06/21 02:19PM, Kenton Groombridge wrote:
> > > eee74b9fca1 adds support for module compression, but this breaks loading
> > > out of tree modules when module signing is enforced because modules must
> > > be signed before they are compressed. Additionally, the recommended
> > > Portage hook[1] no longer works with this change.
> > > 
> > 
> > Forgot to include this reference:
> > 
> > [1] 
> > https://wiki.gentoo.org/wiki/Signed_kernel_module_support#Automatically_signing_kernel_modules_.28Portage.29
> > 
> > > Add module signing support in linux-mod.eclass which more or less does
> > > exactly what the aforementioned Portage hook does. If the kernel
> > > configuration has CONFIG_MODULE_SIG_ALL=y, then read the hash and keys
> > > from the kernel configuration and call the sign_file tool to sign the
> > > module before it is compressed.
> > > 
> > > Bug: https://bugs.gentoo.org/show_bug.cgi?id=447352
> > > Signed-off-by: Kenton Groombridge 
> > > ---
> > >   eclass/linux-mod.eclass | 16 
> > >   1 file changed, 16 insertions(+)
> > > 
> > > diff --git a/eclass/linux-mod.eclass b/eclass/linux-mod.eclass
> > > index b7c13cbf7e7..fd40f6d7c6c 100644
> > > --- a/eclass/linux-mod.eclass
> > > +++ b/eclass/linux-mod.eclass
> > > @@ -712,6 +712,22 @@ linux-mod_src_install() {
> > >   cd "${objdir}" || die "${objdir} does not exist"
> > >   insinto 
> > > "${INSTALL_MOD_PATH}"/lib/modules/${KV_FULL}/${libdir}
> > > + # check here for CONFIG_MODULE_SIG_ALL and sign the module 
> > > being built if enabled.
> > > + # modules must be signed before they are compressed.
> > > +
> > > + if linux_chkconfig_present MODULE_SIG_ALL; then
> > > + local module_sig_hash="$(linux_chkconfig_string 
> > > MODULE_SIG_HASH)"
> > > + local module_sig_key="$(linux_chkconfig_string 
> > > MODULE_SIG_KEY)"
> > > + 
> > > module_sig_key="${module_sig_key:-certs/signing_key.pem}"
> > > + if [[ "${module_sig_key#pkcs11:}" == 
> > > "${module_sig_key}" && "${module_sig_key#/}" == "${module_sig_key}" ]]; 
> > > then
> > > + local key_path="${KERNEL_DIR}/${module_sig_key}"
> > > + else
> > > + local key_path="${module_sig_key}"
> > > + fi
> > > + local cert_path="${KERNEL_DIR}/certs/signing_key.x509"
> > > + "${KERNEL_DIR}"/scripts/sign-file 
> > > ${module_sig_hash//\"} ${key_path//\"} ${cert_path} 
> > > ${modulename}.${KV_OBJ}
> > > + fi
> > > +
> > >   # check here for CONFIG_MODULE_COMPRESS_ > > option> (NONE, GZIP, XZ, ZSTD)
> > >   # and similarily compress the module being built if != 
> > > NONE.
> > > -- 
> > > 2.35.1
> > > 
> > > 
> 
> 
> First of all, thank-you for your work !
> I appreciate any assistance with enhancement or clean-up of these eclasses.
> 
> I tested your patch, are you signing the files in 'work' after they are 
> installed in 'image' ?
> 
> 
> /usr/src/linux/scripts/extract-module-sig.pl -s ./work/kernel/nvidia.ko > 
> /tmp/sig
> Read 47802433 bytes from module file
> Found magic number at 47802433
> Found PKCS#7/CMS encapsulation
> Found 681 bytes of signature [308202a506092a864886f70d010702a0]
> 
> /usr/src/linux/scripts/extract-module-sig.pl -s 
> ./image/lib/modules/5.18.6-gentoo/video/nvidia.ko > /tmp/sig
> Read 47227784 bytes from module file
> Magic number not found at 47227784
> 

Thanks for testing!

That's odd. In my environment they are signed in 'work' before
installing to 'image' as they should be.

# unzstd /lib/modules/5.15.48-gentoo/misc/p_lkrg.ko.zst
/lib/modules/5.15.48-gentoo/misc/p_lkrg.ko.zst: 436681 bytes
# /usr/src/linux/scripts/extract-module-sig.pl -s 
/lib/modules/5.15.48-gentoo/misc/p_lkrg.ko >sig
Read 436681 bytes from module file
Found magic number at 436681
Found PKCS#7/CMS encapsulation
Found 681 bytes of signature [308202a506092a864886f70d010702a0]

The installation of modules in linux-mod_src_install happens after
signing and compression, so unless I am missing something that shouldn't
be happening.


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PATCH] linux-mod.eclass: support module signing

2022-06-23 Thread Mike Pagano

On 6/21/22 14:21, Kenton Groombridge wrote:

On 22/06/21 02:19PM, Kenton Groombridge wrote:

eee74b9fca1 adds support for module compression, but this breaks loading
out of tree modules when module signing is enforced because modules must
be signed before they are compressed. Additionally, the recommended
Portage hook[1] no longer works with this change.



Forgot to include this reference:

[1] 
https://wiki.gentoo.org/wiki/Signed_kernel_module_support#Automatically_signing_kernel_modules_.28Portage.29


Add module signing support in linux-mod.eclass which more or less does
exactly what the aforementioned Portage hook does. If the kernel
configuration has CONFIG_MODULE_SIG_ALL=y, then read the hash and keys
from the kernel configuration and call the sign_file tool to sign the
module before it is compressed.

Bug: https://bugs.gentoo.org/show_bug.cgi?id=447352
Signed-off-by: Kenton Groombridge 
---
  eclass/linux-mod.eclass | 16 
  1 file changed, 16 insertions(+)

diff --git a/eclass/linux-mod.eclass b/eclass/linux-mod.eclass
index b7c13cbf7e7..fd40f6d7c6c 100644
--- a/eclass/linux-mod.eclass
+++ b/eclass/linux-mod.eclass
@@ -712,6 +712,22 @@ linux-mod_src_install() {
cd "${objdir}" || die "${objdir} does not exist"
insinto "${INSTALL_MOD_PATH}"/lib/modules/${KV_FULL}/${libdir}
  
+		# check here for CONFIG_MODULE_SIG_ALL and sign the module being built if enabled.

+   # modules must be signed before they are compressed.
+
+   if linux_chkconfig_present MODULE_SIG_ALL; then
+   local module_sig_hash="$(linux_chkconfig_string 
MODULE_SIG_HASH)"
+   local module_sig_key="$(linux_chkconfig_string 
MODULE_SIG_KEY)"
+   
module_sig_key="${module_sig_key:-certs/signing_key.pem}"
+   if [[ "${module_sig_key#pkcs11:}" == "${module_sig_key}" && 
"${module_sig_key#/}" == "${module_sig_key}" ]]; then
+   local key_path="${KERNEL_DIR}/${module_sig_key}"
+   else
+   local key_path="${module_sig_key}"
+   fi
+   local cert_path="${KERNEL_DIR}/certs/signing_key.x509"
+   "${KERNEL_DIR}"/scripts/sign-file ${module_sig_hash//\"} 
${key_path//\"} ${cert_path} ${modulename}.${KV_OBJ}
+   fi
+
# check here for CONFIG_MODULE_COMPRESS_ 
(NONE, GZIP, XZ, ZSTD)
# and similarily compress the module being built if != NONE.
  
--

2.35.1





First of all, thank-you for your work !
I appreciate any assistance with enhancement or clean-up of these eclasses.

I tested your patch, are you signing the files in 'work' after they are 
installed in 'image' ?


/usr/src/linux/scripts/extract-module-sig.pl -s ./work/kernel/nvidia.ko > 
/tmp/sig
Read 47802433 bytes from module file
Found magic number at 47802433
Found PKCS#7/CMS encapsulation
Found 681 bytes of signature [308202a506092a864886f70d010702a0]

/usr/src/linux/scripts/extract-module-sig.pl -s 
./image/lib/modules/5.18.6-gentoo/video/nvidia.ko > /tmp/sig
Read 47227784 bytes from module file
Magic number not found at 47227784



Mike




--
Mike Pagano
Gentoo Developer - Kernel Project
Gentoo Sources - Lead
E-Mail : mpag...@gentoo.org
GnuPG FP   : 52CC A0B0 F631 0B17 0142 F83F 92A6 DBEC 81F2 B137
Public Key : 
http://http://pgp.mit.edu/pks/lookup?search=0x92A6DBEC81F2B137=index



[gentoo-dev] [PATCH] linux-mod.eclass: support module signing

2022-06-21 Thread Kenton Groombridge
eee74b9fca1 adds support for module compression, but this breaks loading
out of tree modules when module signing is enforced because modules must
be signed before they are compressed. Additionally, the recommended
Portage hook[1] no longer works with this change.

Add module signing support in linux-mod.eclass which more or less does
exactly what the aforementioned Portage hook does. If the kernel
configuration has CONFIG_MODULE_SIG_ALL=y, then read the hash and keys
from the kernel configuration and call the sign_file tool to sign the
module before it is compressed.

Bug: https://bugs.gentoo.org/show_bug.cgi?id=447352
Signed-off-by: Kenton Groombridge 
---
 eclass/linux-mod.eclass | 16 
 1 file changed, 16 insertions(+)

diff --git a/eclass/linux-mod.eclass b/eclass/linux-mod.eclass
index b7c13cbf7e7..fd40f6d7c6c 100644
--- a/eclass/linux-mod.eclass
+++ b/eclass/linux-mod.eclass
@@ -712,6 +712,22 @@ linux-mod_src_install() {
cd "${objdir}" || die "${objdir} does not exist"
insinto "${INSTALL_MOD_PATH}"/lib/modules/${KV_FULL}/${libdir}
 
+   # check here for CONFIG_MODULE_SIG_ALL and sign the module 
being built if enabled.
+   # modules must be signed before they are compressed.
+
+   if linux_chkconfig_present MODULE_SIG_ALL; then
+   local module_sig_hash="$(linux_chkconfig_string 
MODULE_SIG_HASH)"
+   local module_sig_key="$(linux_chkconfig_string 
MODULE_SIG_KEY)"
+   
module_sig_key="${module_sig_key:-certs/signing_key.pem}"
+   if [[ "${module_sig_key#pkcs11:}" == 
"${module_sig_key}" && "${module_sig_key#/}" == "${module_sig_key}" ]]; then
+   local key_path="${KERNEL_DIR}/${module_sig_key}"
+   else
+   local key_path="${module_sig_key}"
+   fi
+   local cert_path="${KERNEL_DIR}/certs/signing_key.x509"
+   "${KERNEL_DIR}"/scripts/sign-file 
${module_sig_hash//\"} ${key_path//\"} ${cert_path} ${modulename}.${KV_OBJ}
+   fi
+
# check here for CONFIG_MODULE_COMPRESS_ 
(NONE, GZIP, XZ, ZSTD) 
# and similarily compress the module being built if != NONE.
 
-- 
2.35.1




Re: [gentoo-dev] [PATCH] linux-mod.eclass: support module signing

2018-04-15 Thread NP-Hardass
On 04/14/2018 05:25 PM, Georgy Yakovlev wrote:
> Hi,
> 
> There is an old bug[1] to support
> linux kernel module signing at install.
> 
> And here is my first attempt to modify an eclass.
> Need proper input on it and a kick in the right direction.
> 
> Add 3 variables, settable by users if they keep keys somewhere safe.
> Otherwise it just works with the auto-generated keys 
> if CONFIG_MODULE_SIG=y and vars are unset.
> 
> eclass will die if kernel requires a signed module,
> but signing is not requested.
> 
> 
> Known problems:
> 
> Packages that do not use linux-mod_src_install() will not sign 
> the modules, 
> But those packages will still inherit module-sign useflag.
> It's misleading and I'm not sure how to fix that.
> Examples : sys-kernel/spl, sys-fs/zfs-kmod
> 
> May need additional handling of KBUILD_SIGN_PIN variable[2],
> which can be set to hold the passphrase to the key. But it may end up
> in vdb environment files, not sure how to handle that or if it worth it
> 
> not eapi-7 ready because of STRIP_MASK usage.
> will need to cover this case as well, probably later.
> 
> older (<4.3.3) kernels use perl to sign modules, not sure if it's worth
> supporting old kernels, there is no gentoo-sources in the tree old
> enough, except masked 4.1
> there are old vanilla-sources that will be affected by this.
> 
> 
> [1] https://bugs.gentoo.org/447352
> [2] https://www.kernel.org/doc/html/v4.16/admin-guide/module-signing.html
> 
> diff --git a/eclass/linux-mod.eclass b/eclass/linux-mod.eclass
> index bf580cf4cfa9..211b0496f528 100644
> --- a/eclass/linux-mod.eclass
> +++ b/eclass/linux-mod.eclass
> @@ -14,7 +14,7 @@
>  # required to install external modules against a kernel source
>  # tree.
>  
> -# A Couple of env vars are available to effect usage of this eclass
> +# Several env vars are available to effect usage of this eclass
>  # These are as follows:
>  
>  # @ECLASS-VARIABLE: MODULES_OPTIONAL_USE
> @@ -132,6 +132,31 @@
>  # @DESCRIPTION:
>  # It's a read-only variable. It contains the extension of the kernel modules.
>  
> +# @ECLASS-VARIABLE: KERNEL_MODULE_SIG_HASH
> +# @DEFAULT_UNSET
> +# @DESCRIPTION:
> +# A string to control signing algorithm
> +# Possible values: sha1:sha224:sha256:sha384:sha512
> +# Defaults to value extracted from .config
> +# Can be set by user in make.conf, as it can differ from kernel's.
> +# In case of overriding this it's users responsibility to make sure
> +# that kernel supports desired hash algo
> +
> +# @ECLASS-VARIABLE: KERNEL_MODULE_SIG_PEM
> +# @DEFAULT_UNSET
> +# @DESCRIPTION:
> +# A string, containing path to the private key filename or PKCS#11 URI
> +# Defaults to ${KV_DIR}/certs/signing_key.pem} if unset.
> +# Can be set by user in make.conf
> +
> +# @ECLASS-VARIABLE: KERNEL_MODULE_SIG_X509
> +# @DEFAULT_UNSET
> +# @DESCRIPTION:
> +# A string, containing path to the public key filename
> +# Defaults to ${KV_DIR}/certs/signing_key.x509} if unset.
> +# Can be set by user in make.conf
> +
> +
>  inherit eutils linux-info multilib
>  EXPORT_FUNCTIONS pkg_setup pkg_preinst pkg_postinst src_install src_compile 
> pkg_postrm
>  

These KV_DIRs should be KV_OUT_DIRs, as they are objects only available
after building the kernel and thus if KV_OUT_DIR != KV_DIR, this will fail.

Additionally, sig_pem and sig_x509 should be derived from MODULE_SIG_KEY
by default.
> @@ -144,12 +169,13 @@ esac
>   0) die "EAPI=${EAPI} is not supported with 
> MODULES_OPTIONAL_USE_IUSE_DEFAULT due to lack of IUSE defaults" ;;
>  esac
>  
> -IUSE="kernel_linux 
> ${MODULES_OPTIONAL_USE:+${_modules_optional_use_iuse_default}}${MODULES_OPTIONAL_USE}"
> +IUSE="module-sign kernel_linux 
> ${MODULES_OPTIONAL_USE:+${_modules_optional_use_iuse_default}}${MODULES_OPTIONAL_USE}"
>  SLOT="0"
>  RDEPEND="${MODULES_OPTIONAL_USE}${MODULES_OPTIONAL_USE:+? (} kernel_linux? ( 
> virtual/modutils ) ${MODULES_OPTIONAL_USE:+)}"
>  DEPEND="${RDEPEND}
>  ${MODULES_OPTIONAL_USE}${MODULES_OPTIONAL_USE:+? (}
>   sys-apps/sed
> + module-sign? ( || ( dev-libs/openssl dev-libs/libressl ) )
>   kernel_linux? ( virtual/linux-sources )
>   ${MODULES_OPTIONAL_USE:+)}"
>  
> @@ -196,6 +222,25 @@ check_vermagic() {
>   fi
>  }
>  
> +# @FUNCTION: check_sig_force
> +# @INTERNAL
> +# @DESCRIPTION:
> +# Check if kernel requires module signing and die
> +# if module is not going to be signed.
> +check_sig_force() {
> + debug-print-function ${FUNCNAME} $*
> +
> + if linux_chkconfig_present MODULE_SIG_FORCE; then
> + if use !module-sign; then
> + ewarn ""
> + ewarn "Kernel requires all modules to be signed and 
> verified"
> + ewarn "please enable USE=\"module-sign\""
> + ewarn "otherwise loading the module will fail"
> + die "signature required"
> + fi
> + fi
> +}
> +
>  # @FUNCTION: use_m
>  # @RETURN: true or false
>  # @DESCRIPTION:


The documentation for 

[gentoo-dev] [PATCH] linux-mod.eclass: support module signing

2018-04-14 Thread Georgy Yakovlev
Hi,

There is an old bug[1] to support
linux kernel module signing at install.

And here is my first attempt to modify an eclass.
Need proper input on it and a kick in the right direction.

Add 3 variables, settable by users if they keep keys somewhere safe.
Otherwise it just works with the auto-generated keys 
if CONFIG_MODULE_SIG=y and vars are unset.

eclass will die if kernel requires a signed module,
but signing is not requested.


Known problems:

Packages that do not use linux-mod_src_install() will not sign 
the modules, 
But those packages will still inherit module-sign useflag.
It's misleading and I'm not sure how to fix that.
Examples : sys-kernel/spl, sys-fs/zfs-kmod

May need additional handling of KBUILD_SIGN_PIN variable[2],
which can be set to hold the passphrase to the key. But it may end up
in vdb environment files, not sure how to handle that or if it worth it

not eapi-7 ready because of STRIP_MASK usage.
will need to cover this case as well, probably later.

older (<4.3.3) kernels use perl to sign modules, not sure if it's worth
supporting old kernels, there is no gentoo-sources in the tree old
enough, except masked 4.1
there are old vanilla-sources that will be affected by this.


[1] https://bugs.gentoo.org/447352
[2] https://www.kernel.org/doc/html/v4.16/admin-guide/module-signing.html

diff --git a/eclass/linux-mod.eclass b/eclass/linux-mod.eclass
index bf580cf4cfa9..211b0496f528 100644
--- a/eclass/linux-mod.eclass
+++ b/eclass/linux-mod.eclass
@@ -14,7 +14,7 @@
 # required to install external modules against a kernel source
 # tree.
 
-# A Couple of env vars are available to effect usage of this eclass
+# Several env vars are available to effect usage of this eclass
 # These are as follows:
 
 # @ECLASS-VARIABLE: MODULES_OPTIONAL_USE
@@ -132,6 +132,31 @@
 # @DESCRIPTION:
 # It's a read-only variable. It contains the extension of the kernel modules.
 
+# @ECLASS-VARIABLE: KERNEL_MODULE_SIG_HASH
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# A string to control signing algorithm
+# Possible values: sha1:sha224:sha256:sha384:sha512
+# Defaults to value extracted from .config
+# Can be set by user in make.conf, as it can differ from kernel's.
+# In case of overriding this it's users responsibility to make sure
+# that kernel supports desired hash algo
+
+# @ECLASS-VARIABLE: KERNEL_MODULE_SIG_PEM
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# A string, containing path to the private key filename or PKCS#11 URI
+# Defaults to ${KV_DIR}/certs/signing_key.pem} if unset.
+# Can be set by user in make.conf
+
+# @ECLASS-VARIABLE: KERNEL_MODULE_SIG_X509
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# A string, containing path to the public key filename
+# Defaults to ${KV_DIR}/certs/signing_key.x509} if unset.
+# Can be set by user in make.conf
+
+
 inherit eutils linux-info multilib
 EXPORT_FUNCTIONS pkg_setup pkg_preinst pkg_postinst src_install src_compile 
pkg_postrm
 
@@ -144,12 +169,13 @@ esac
0) die "EAPI=${EAPI} is not supported with 
MODULES_OPTIONAL_USE_IUSE_DEFAULT due to lack of IUSE defaults" ;;
 esac
 
-IUSE="kernel_linux 
${MODULES_OPTIONAL_USE:+${_modules_optional_use_iuse_default}}${MODULES_OPTIONAL_USE}"
+IUSE="module-sign kernel_linux 
${MODULES_OPTIONAL_USE:+${_modules_optional_use_iuse_default}}${MODULES_OPTIONAL_USE}"
 SLOT="0"
 RDEPEND="${MODULES_OPTIONAL_USE}${MODULES_OPTIONAL_USE:+? (} kernel_linux? ( 
virtual/modutils ) ${MODULES_OPTIONAL_USE:+)}"
 DEPEND="${RDEPEND}
 ${MODULES_OPTIONAL_USE}${MODULES_OPTIONAL_USE:+? (}
sys-apps/sed
+   module-sign? ( || ( dev-libs/openssl dev-libs/libressl ) )
kernel_linux? ( virtual/linux-sources )
${MODULES_OPTIONAL_USE:+)}"
 
@@ -196,6 +222,25 @@ check_vermagic() {
fi
 }
 
+# @FUNCTION: check_sig_force
+# @INTERNAL
+# @DESCRIPTION:
+# Check if kernel requires module signing and die
+# if module is not going to be signed.
+check_sig_force() {
+   debug-print-function ${FUNCNAME} $*
+
+   if linux_chkconfig_present MODULE_SIG_FORCE; then
+   if use !module-sign; then
+   ewarn ""
+   ewarn "Kernel requires all modules to be signed and 
verified"
+   ewarn "please enable USE=\"module-sign\""
+   ewarn "otherwise loading the module will fail"
+   die "signature required"
+   fi
+   fi
+}
+
 # @FUNCTION: use_m
 # @RETURN: true or false
 # @DESCRIPTION:
@@ -352,6 +397,28 @@ get-KERNEL_CC() {
echo "${kernel_cc}"
 }
 
+# @FUNCTION: sign_module
+# @DESCRIPTION:
+# Sign a kernel module if enabled and supported, or just silently ignore the 
request and do nothing.
+# @USAGE: 
+sign_module() {
+   debug-print-function ${FUNCNAME} $*
+
+   if use module-sign; then
+   local sig_hash sig_pem sig_x509 modulename
+   sig_hash=$(linux_chkconfig_string MODULE_SIG_HASH)
+   sig_pem="${KV_DIR}/certs/signing_key.pem"
+