From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 9AC04138334 for ; Sat, 22 Sep 2018 02:23:13 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7D9A7E0886; Sat, 22 Sep 2018 02:23:09 +0000 (UTC) Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 156E6E087A for ; Sat, 22 Sep 2018 02:23:08 +0000 (UTC) Received: from reaper.local.sysdump.net (ip72-194-88-79.oc.oc.cox.net [72.194.88.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: gyakovlev) by smtp.gentoo.org (Postfix) with ESMTPSA id C8E4B335CD2 for ; Sat, 22 Sep 2018 02:23:06 +0000 (UTC) From: Georgy Yakovlev 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 Message-ID: <3463209.JvmGyCbEsu@reaper.local.sysdump.net> In-Reply-To: <1537534680.1635.11.camel@tsoy.me> References: <20180921051304.115704-1-gyakovlev@gentoo.org> <1537534680.1635.11.camel@tsoy.me> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3213433.jpY8fjhZJx"; micalg="pgp-sha256"; protocol="application/pgp-signature" X-Archives-Salt: 532f3471-a9f5-4ae4-8870-bb4e0a99c715 X-Archives-Hash: bc9071b7cafbc5ce127077ed90873e06 --nextPart3213433.jpY8fjhZJx Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Friday, September 21, 2018 5:58:00 AM PDT Alexander Tsoy wrote: > =D0=92 =D0=A7=D1=82, 20/09/2018 =D0=B2 22:13 -0700, Georgy Yakovlev =D0= =BF=D0=B8=D1=88=D0=B5=D1=82: > > ----------------->%------------------- > > @@ -144,13 +158,16 @@ esac > >=20 > > 0) die "EAPI=3D${EAPI} is not supported with > >=20 > > MODULES_OPTIONAL_USE_IUSE_DEFAULT due to lack of IUSE defaults" ;; > >=20 > > esac > >=20 > > -IUSE=3D"kernel_linux > > ${MODULES_OPTIONAL_USE:+${_modules_optional_use_iuse_default}}${MODUL > > ES_OPTIONAL_USE}" > > +IUSE=3D"module-sign kernel_linux > > ${MODULES_OPTIONAL_USE:+${_modules_optional_use_iuse_default}}${MODUL > > ES_OPTIONAL_USE}" > >=20 > > SLOT=3D"0" > > RDEPEND=3D"${MODULES_OPTIONAL_USE}${MODULES_OPTIONAL_USE:+? (} > >=20 > > kernel_linux? ( virtual/modutils ) ${MODULES_OPTIONAL_USE:+)}" > >=20 > > DEPEND=3D"${RDEPEND} > > =20 > > ${MODULES_OPTIONAL_USE}${MODULES_OPTIONAL_USE:+? (} > > =09 > > sys-apps/sed > >=20 > > - kernel_linux? ( virtual/linux-sources virtual/libelf ) > > + kernel_linux? ( > > + virtual/linux-sources virtual/libelf > > + module-sign? ( || ( dev-libs/openssl dev- > > libs/libressl ) ) > > + ) >=20 > 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= =2E=20 libcrypto is not required to load the module. Adding slot build dep to a package with a module does not make a lot of sen= se=20 to me, but probably does not hurt either. >=20 > > ${MODULES_OPTIONAL_USE:+)}" > > =20 > > # eclass utilities > >=20 > > @@ -352,6 +369,84 @@ get-KERNEL_CC() { > >=20 > > echo "${kernel_cc}" > > =20 > > } > >=20 > > +# @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=3Dy option set" > > + eerror "This means that kernel requires all > > modules" > > + eerror "to be signed and verified before > > loading" > > + eerror "please enable USE=3D\"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=3D"$(linux_chkconfig_string > > MODULE_SIG_HASH)" > > + dotconfig_sig_key=3D"$(linux_chkconfig_string MODULE_SIG_KEY)" > > + > > + # sign-file binary chokes on double quotes > > + dotconfig_sig_hash=3D${dotconfig_sig_hash//\"/} > > + dotconfig_sig_key=3D${dotconfig_sig_key//\"/} > > + > > + sign_binary_path=3D"${KV_OUT_DIR}/scripts/sign-file" >=20 > 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= =20 re-building sign-file binary) and update modules later (probably with @modu= le- rebuild). Last ABI change was in 2016 (still masked in gentoo), and in 2010 before th= at. It's unlikely to encounter an abi changing openssl upgrade and a random mod= ule=20 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 artic= le. The whole eclass relies on kernel build dir to be available with exact same= =20 configuration to build modules, not just the signing part. As an example, using kernel gcc plugins situation is much worse, but still = not=20 a big deal, just rebuild a kernel after upgrading gcc to be able to build o= ut- of tree modules. sign-file binary is rather simple and is not that picky and rarely breaks. = At=20 least what's what I observe while testing this patch. I build kernels weekly (and rebuilding modules) and have not seen a single= =20 problem related to signing. I'll post rebased/updated patch with latest changes happened to eclass to=20 support EAPI7. =2D-=20 Regads, Georgy Yakovlev Gentoo Linux Developer --nextPart3213433.jpY8fjhZJx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE3NQc5d2Nq7vhc9JNonLI8BUSnVIFAlulp4AACgkQonLI8BUS nVKX2A//Yr27idwMBb2iMwTKyfttjF8i+ZzpHoty3hDwTb5Q2hdG2qx1Nz7gdjih xMbp7mBPoroVDdlX5YuA6Z6VT2qadPxcQ+ceN9Sx55RfLHT4RKTUlsHzni6K4pgb jx2nKygvWWQQAyD9S8stGie5WuiRZmh0nWfzPoEy8DCNpRwAtP5KF+H/eS9k5OTw /fj0i6LpDMjxMMuutLxjqA1C6TGACzwIrKb4LlQgfWZIlEbEVG50CoOHU0cQcC6L jykMkljQANe4KmIDlch64+ZqS89uJQ89aAETDq7SMtSre7cHv+tkbQW81YsHiCMv RT7ka1ZDecRdAZuAGrsAq3heOlwSaFfzg19Pc/o9RJpPzJhqUXwoC4r40Wr4KzOI RnT9n/t54L5NBmzz8BwBGVRTTNx0rO1k1Lb8dn4ZFTkWQlOhqLtkUcq2cyjGP16+ VVPnAC5Lemg8oXlONQReGrIlREQ556tk6OpQJBzsDEf99piq8LGmCPofl3L33GYy MjtUGA3/9Si9V7rweTsxYntTA0pvUfWyBfTBgD0GIGcysF8xpgoGE1qONef1/7Ci VG1fn0LedNR1wwrZ9+mYiwewUuTgKVFRdth2f/a5EIj/k7qgs98QC4A13XcaLsFd vagwrawbmOX1KjVOkJu2SP5n4WZ5Ead3wKQzsDx6heWyxDu8Jmc= =X/UN -----END PGP SIGNATURE----- --nextPart3213433.jpY8fjhZJx--