Bug 1320921

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.

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.

The implementation has not yet been released by the upstream:

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

(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.

(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

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.

*** Bug 1490975 has been marked as a duplicate of this bug. ***

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.

(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",
};

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
};

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.

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).

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.

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?

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

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.

The bug is still valid, moving to F29

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.

This bug has been stalled on upstream review. Recently there's certain progress:
https://lore.kernel.org/linux-modules/CAKi4VALJcbwq2SKpb3fBw022gBO1kBe0qL9=Vszg2OOBps+dtA@mail.gmail.com/

Proposed upstream patch is based on OpenSSL now at https://lore.kernel.org/linux-modules/xunybm3z94j6.fsf@redhat.com/T/#t

FEDORA-2019-e11df00d17 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-e11df00d17

kmod-26-3.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-e11df00d17

kmod-26-3.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.