From: Georgy Yakovlev <gyakovlev@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] [PATCH] linux-mod.eclass: support module signing
Date: Mon, 27 Jun 2022 14:11:57 -0700 [thread overview]
Message-ID: <7311bbf9de54e3fb08953a40a9cd03df61f4dd00.camel@gentoo.org> (raw)
In-Reply-To: <CAJ0EP42q3TV5AeN42A5FdS7nG9c8wfx2rUwprX1pFxF659mR1A@mail.gmail.com>
On Mon, 2022-06-27 at 15:49 -0400, Mike Gilbert wrote:
> On Mon, Jun 27, 2022 at 3:42 PM Georgy Yakovlev
> <gyakovlev@gentoo.org> wrote:
> >
> > On Mon, 2022-06-27 at 14:56 -0400, Mike Gilbert wrote:
> > > On Mon, Jun 27, 2022 at 2:35 PM Kenton Groombridge
> > > <concord@gentoo.org> 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
next prev parent reply other threads:[~2022-06-27 21:12 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-21 18:19 [gentoo-dev] [PATCH] linux-mod.eclass: support module signing Kenton Groombridge
2022-06-21 18:21 ` Kenton Groombridge
2022-06-23 12:51 ` Mike Pagano
2022-06-23 14:30 ` Kenton Groombridge
2022-06-26 10:52 ` Georgy Yakovlev
2022-06-26 11:15 ` Georgy Yakovlev
2022-06-27 18:35 ` Kenton Groombridge
2022-06-27 18:56 ` Mike Gilbert
2022-06-27 19:18 ` Kenton Groombridge
2022-06-27 19:42 ` Georgy Yakovlev
2022-06-27 19:49 ` Mike Gilbert
2022-06-27 21:11 ` Georgy Yakovlev [this message]
2022-06-27 21:50 ` Mike Gilbert
2022-06-27 23:42 ` Georgy Yakovlev
2022-07-05 19:02 ` Georgy Yakovlev
2022-07-05 19:55 ` Kenton Groombridge
2022-07-05 20:11 ` Mike Gilbert
2022-06-27 19:46 ` Georgy Yakovlev
2022-06-27 20:02 ` Kenton Groombridge
2022-06-27 21:25 ` Georgy Yakovlev
-- strict thread matches above, loose matches on Subject: below --
2018-04-14 21:25 Georgy Yakovlev
2018-04-15 18:13 ` NP-Hardass
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7311bbf9de54e3fb08953a40a9cd03df61f4dd00.camel@gentoo.org \
--to=gyakovlev@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox