From: Georgy Yakovlev <gyakovlev@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] [PATCH] eclass/linux-mod.eclass: add module signing support
Date: Fri, 21 Sep 2018 19:22:56 -0700 [thread overview]
Message-ID: <3463209.JvmGyCbEsu@reaper.local.sysdump.net> (raw)
In-Reply-To: <1537534680.1635.11.camel@tsoy.me>
[-- Attachment #1: Type: text/plain, Size: 4689 bytes --]
On Friday, September 21, 2018 5:58:00 AM PDT Alexander Tsoy wrote:
> В Чт, 20/09/2018 в 22:13 -0700, Georgy Yakovlev пишет:
> > ----------------->%-------------------
> > @@ -144,13 +158,16 @@ 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}}${MODUL
> > ES_OPTIONAL_USE}"
> > +IUSE="module-sign kernel_linux
> > ${MODULES_OPTIONAL_USE:+${_modules_optional_use_iuse_default}}${MODUL
> > ES_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
> >
> > - kernel_linux? ( virtual/linux-sources virtual/libelf )
> > + kernel_linux? (
> > + virtual/linux-sources virtual/libelf
> > + module-sign? ( || ( dev-libs/openssl dev-
> > libs/libressl ) )
> > + )
>
> It should depend on the proper openssl slot: dev-libs/openssl:0
Thanks for suggestion.
Not sure, all it does is it makes sure -lcrypto works while building module.
libcrypto is not required to load the module.
Adding slot build dep to a package with a module does not make a lot of sense
to me, but probably does not hurt either.
>
> > ${MODULES_OPTIONAL_USE:+)}"
> >
> > # eclass utilities
> >
> > @@ -352,6 +369,84 @@ get-KERNEL_CC() {
> >
> > echo "${kernel_cc}"
> >
> > }
> >
> > +# @FUNCTION: _check_sig_force
> > +# @INTERNAL
> > +# @DESCRIPTION:
> > +# Check if kernel requires module signing and die
> > +# if modules are 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
> > + eerror "kernel .config has
> > MODULE_SIG_FORCE=y option set"
> > + eerror "This means that kernel requires all
> > modules"
> > + eerror "to be signed and verified before
> > loading"
> > + eerror "please enable USE=\"module-sign\" or
> > reconfigure your kernel"
> > + eerror "otherwise loading the module will
> > fail"
> > + die "signature required"
> > + fi
> > + fi
> > +}
> > +
> > +# @FUNCTION: _sign_module
> > +# @INTERNAL
> > +# @USAGE: <filename>
> > +# @DESCRIPTION:
> > +# Sign a kernel module
> > +_sign_module() {
> > + debug-print-function ${FUNCNAME} "${@}"
> > +
> > + local dotconfig_sig_hash dotconfig_sig_key
> > + local sign_binary_path sig_key_path sig_x509_path
> > + local module
> > +
> > + # extract values from kernel .config
> > + # extracted key path is not full, e.g.
> > "certs/signing_key.pem"
> > + dotconfig_sig_hash="$(linux_chkconfig_string
> > MODULE_SIG_HASH)"
> > + dotconfig_sig_key="$(linux_chkconfig_string MODULE_SIG_KEY)"
> > +
> > + # sign-file binary chokes on double quotes
> > + dotconfig_sig_hash=${dotconfig_sig_hash//\"/}
> > + dotconfig_sig_key=${dotconfig_sig_key//\"/}
> > +
> > + sign_binary_path="${KV_OUT_DIR}/scripts/sign-file"
>
> Yet another way to screw up modules building. It relies on some binary
> in the kernel build dir that may break after openssl update (e.g.
> soname change).
openssl soname rarely changes and a user likely to build kernel first (thus
re-building sign-file binary) and update modules later (probably with @module-
rebuild).
Last ABI change was in 2016 (still masked in gentoo), and in 2010 before that.
It's unlikely to encounter an abi changing openssl upgrade and a random module
rebuild while updating unless a user updates very infrequently.
simple workaround:
cd /usr/src/linux && rm scripts/sign-file && make scripts
I can probably add this to die message and/or create a news item/wiki article.
The whole eclass relies on kernel build dir to be available with exact same
configuration to build modules, not just the signing part.
As an example, using kernel gcc plugins situation is much worse, but still not
a big deal, just rebuild a kernel after upgrading gcc to be able to build out-
of tree modules.
sign-file binary is rather simple and is not that picky and rarely breaks. At
least what's what I observe while testing this patch.
I build kernels weekly (and rebuilding modules) and have not seen a single
problem related to signing.
I'll post rebased/updated patch with latest changes happened to eclass to
support EAPI7.
--
Regads,
Georgy Yakovlev
Gentoo Linux Developer
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2018-09-22 2:23 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-21 5:13 [gentoo-dev] [PATCH] eclass/linux-mod.eclass: add module signing support Georgy Yakovlev
2018-09-21 12:58 ` Alexander Tsoy
2018-09-21 22:59 ` Chí-Thanh Christopher Nguyễn
2018-09-22 2:30 ` Georgy Yakovlev
2018-09-22 2:22 ` Georgy Yakovlev [this message]
2018-10-01 8:48 ` [gentoo-dev] [PATCH 1/2] " Georgy Yakovlev
2018-10-01 8:48 ` [gentoo-dev] [PATCH 2/2] profiles: mask module signing for testing Georgy Yakovlev
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=3463209.JvmGyCbEsu@reaper.local.sysdump.net \
--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