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: > > +# @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