Bug 1668459

RH - please fix this for RHEL8.

+++ This bug was initially created as a clone of Bug #1320921 +++

Description of problem: in theory modinfo should show modules signatures

Version-Release number of selected component (if applicable): kmod-22-2.fc23.x86_64

# modinfo snd
filename:       /lib/modules/4.4.6-300.fc23.x86_64/kernel/sound/core/snd.ko.xz
alias:          char-major-116-*
license:        GPL
description:    Advanced Linux Sound Architecture driver for soundcards.
author:         Jaroslav Kysela <perex>
depends:        soundcore
intree:         Y
vermagic:       4.4.6-300.fc23.x86_64 SMP mod_unload 
parm:           debug:Debug level (0 = disable) (int)
parm:           slots:Module names assigned to the slots. (array of charp)
parm:           major:Major # for sound driver. (int)
parm:           cards_limit:Count of auto-loadable soundcards. (int)

The problem is also discussed here: https://github.com/coreos/bugs/issues/1054 

The only workaround at the moment is to run this command:

# xzcat `modinfo -n snd` | grep 'Module signature appended'
Binary file (standard input) matches

--- Additional comment from Josh Boyer on 2016-03-24 11:28:51 UTC ---

As you found in the coreos issue, the problem comes from the kernel changing how it signs modules (using PKCS#7) and is now lacking the information that kmod needs.

I'm adding David Howells on CC, but at the moment there is no known fix for this because upstream kmod doesn't want to link with crypto libraries.

--- Additional comment from Artem S. Tashkinov on 2017-07-24 22:08:44 UTC ---

In Fedora 26 the situation has improved:

$ modinfo blowfish-x86_64
filename:       /lib/modules/4.11.9-200.fc25.x86_64/kernel/arch/x86/crypto/blowfish-x86_64.ko.xz
alias:          crypto-blowfish-asm
alias:          blowfish-asm
alias:          crypto-blowfish
alias:          blowfish
description:    Blowfish Cipher Algorithm, asm optimized
license:        GPL
depends:        blowfish_common
intree:         Y
vermagic:       4.11.9-200.fc25.x86_64 SMP mod_unload 
signat:         PKCS#7
signer:         
sig_key:        
sig_hashalgo:   md4
parm:           force:Force module load, ignore CPU blacklist (int)

However signer and sig_key are both missing.

If that's an intended behavior please close this bug report.

--- Additional comment from Yauheni Kaliuta on 2017-07-30 18:15:33 UTC ---

The implementation has not yet been released by the upstream:

https://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git/commit/?id=e5b6a658eab9f1fa6405e2ac98930723b7f2bbfd

--- Additional comment from Yauheni Kaliuta on 2017-09-05 17:09:30 UTC ---

(In reply to Yauheni Kaliuta from comment #3)
> The implementation has not yet been released by the upstream:
> 
> https://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git/commit/
> ?id=e5b6a658eab9f1fa6405e2ac98930723b7f2bbfd

Actually, the bug is a bit more serious, it's about missing of PKCS#7 signature format support, introduced by https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bc1c373dd2a5113800360f7152be729c9da996cc

Sorry for misleading.

--- Additional comment from Carlos Alberto Lopez Perez on 2017-10-31 15:29:48 UTC ---

(In reply to Yauheni Kaliuta from comment #4)
> (In reply to Yauheni Kaliuta from comment #3)
> > The implementation has not yet been released by the upstream:
> > 
> > https://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git/commit/
> > ?id=e5b6a658eab9f1fa6405e2ac98930723b7f2bbfd
> 
> Actually, the bug is a bit more serious, it's about missing of PKCS#7
> signature format support, introduced by
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/
> ?id=bc1c373dd2a5113800360f7152be729c9da996cc
> 
> Sorry for misleading.

It took me a while to realize that you were talking about a bug in kmod rather than in the kernel

To clarify this: the problem is that kmod doesn't still doesn't understand the PKCS#7 signatures that modern kernels (>=4.3) use.

Related: https://github.com/coreos/bugs/issues/1054

--- Additional comment from Artem S. Tashkinov on 2018-01-18 13:29:23 UTC ---

This is so much better in Fedora 27 (it shows sig_id, sig_hashalgo, signature in HEX), but two fields are still missing: signer and sig_key.

--- Additional comment from Yauheni Kaliuta on 2018-01-31 20:38:20 UTC ---



--- Additional comment from Stephan Mueller on 2018-01-31 20:54:17 UTC ---

I am not sure that this bug report is a duplication of 1490975, but whatever.

The issue described in 1490975 is that the modinfo shows md4 as a hash algo. Note, on RHEL7 or other systems, it is commonly sha256. For more details, see 1490975.

--- Additional comment from Yauheni Kaliuta on 2018-01-31 21:00:53 UTC ---

(In reply to Stephan Mueller from comment #8)
> I am not sure that this bug report is a duplication of 1490975, but whatever.

It is.

> The issue described in 1490975 is that the modinfo shows md4 as a hash algo.
> Note, on RHEL7 or other systems, it is commonly sha256. For more details,
> see 1490975.

With PKC#7 the real algo is not part of the structure, which is shown, anymore. It requires additional handling. MD4 is just the 0 value:

const char *const pkey_hash_algo[PKEY_HASH__LAST] = {
	[PKEY_HASH_MD4]		= "md4",
	[PKEY_HASH_MD5]		= "md5",
	[PKEY_HASH_SHA1]	= "sha1",
	[PKEY_HASH_RIPE_MD_160]	= "rmd160",
	[PKEY_HASH_SHA256]	= "sha256",
	[PKEY_HASH_SHA384]	= "sha384",
	[PKEY_HASH_SHA512]	= "sha512",
	[PKEY_HASH_SHA224]	= "sha224",
};

--- Additional comment from Yauheni Kaliuta on 2018-01-31 21:01:39 UTC ---

This will be the correct snippet:

enum pkey_hash_algo {
	PKEY_HASH_MD4,
	PKEY_HASH_MD5,
	PKEY_HASH_SHA1,
	PKEY_HASH_RIPE_MD_160,
	PKEY_HASH_SHA256,
	PKEY_HASH_SHA384,
	PKEY_HASH_SHA512,
	PKEY_HASH_SHA224,
	PKEY_HASH__LAST
};

--- Additional comment from Stephan Mueller on 2018-01-31 21:07:25 UTC ---

I understand that the code supports it, but the configured signatures do not even include MD4 as referred to in 1490975.

In addition, the kernel config compiles the md4.ko as a module. lsmod shows no inserted md4. /proc/crypto does not list an md4 implementation either.

Thus, my hunch is that MD4 is not used and it is a display error.

If it would be for real that MD4 is used, something rather big is broken in the Fedora build system, because MD4 should NOT be used.

--- Additional comment from Yauheni Kaliuta on 2018-01-31 21:12:23 UTC ---

I consider it as a error in modinfo display code, it should parse PKC#7, instead of the structure, since now all the info is there.

Filling the structure by the kernel signing code in case of PKC#7 looks pretty clumsy for me.

But if David agree to implement it -- then nothing should be done on the kmod side. Anyway, it is exactly the same "problem" (the real problem is that the kernel code has been submitted without sync with pretty critical userspace and broke it).

--- Additional comment from Yauheni Kaliuta on 2018-01-31 21:16:07 UTC ---

BTW, if I remember correctly, I consider it clumsy because the structure assumes that all the field follow each other, which is not the case in case of PKCS#7, it is ASN.1 encoded.

--- Additional comment from Mark J. Cox on 2018-10-26 12:27:53 UTC ---

ping: is there a plan to address this?  At least fixing the confusing default display of "MD4" but ideally with the subject parsing the certificate info?

--- Additional comment from Yauheni Kaliuta on 2018-10-26 21:05:17 UTC ---

Upstream maintainer did no share opinion about that (I made a couple of implementations)

--- Additional comment from Ben Cotton on 2018-11-27 13:55:03 UTC ---

This message is a reminder that Fedora 27 is nearing its end of life.
On 2018-Nov-30  Fedora will stop maintaining and issuing updates for
Fedora 27. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora  'version' of '27'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 27 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

--- Additional comment from Yauheni Kaliuta on 2018-11-27 14:05:15 UTC ---

The bug is still valid, moving to F29

--- Additional comment from Laurie Barry on 2019-01-22 19:06:51 UTC ---

This bug has benign, but ugly side affects. 

This bug causes modinfo to report incorrect information. I used modinfo on SLES 15 SP1 and RHEL 8SS3 to display the differences.

Testing on RHEL8 SS3:
[root@RHEL8SS3]# modinfo /lib/modules/4.18.0-56.el8.x86_64/kernel/drivers/scsi/lpfc/lpfc.ko.xz | grep sig
sig_id:         PKCS#7
signer:
sig_key:
sig_hashalgo:   md4
signature:      30:82:02:64:06:09:2A:86:48:86:F7:0D:01:07:02:A0:82:02:55:30:
[root@RHEL8SS3]#

Copied the RHEL 8 lpfc.ko to SLES 15 SP1:
linux-20l6:~ # modinfo ./lpfc.ko.xz | grep sig
sig_id:         PKCS#7
signer:         Red Hat Enterprise Linux kernel signing key
sig_key:        30:6C:31:10:30:0E:06:03:55:04:0A:0C:07:52:65:64:20:48:61:74:
sig_hashalgo:   sha256
signature:      91:34:9F:FB:78:60:3B:15:47:A6:0A:93:39:17:37:D9:F6:39:97:AE:
linux-20l6:~ # 

Not only are many of the fields empty or incorrect, but loading an ECD signed driver on RHEL8 causes the kernel to report a warning:
# dmesg | grep PKCS
[61234.894961] PKCS#7 signature not signed with a trusted key

It's in Red Hat's best interest to fix this in RHEL 8.0.