Bug 1320921 - modinfo shows incomplete module signature information
Summary: modinfo shows incomplete module signature information
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: kmod
Version: 29
Hardware: All
OS: Linux
unspecified
urgent
Target Milestone: ---
Assignee: kmod development team
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 1490975 (view as bug list)
Depends On:
Blocks: 1668459
TreeView+ depends on / blocked
 
Reported: 2016-03-24 10:17 UTC by Artem S. Tashkinov
Modified: 2019-10-23 08:24 UTC (History)
15 users (show)

Fixed In Version: kmod-26-3.fc30
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1486865 1668459 (view as bug list)
Environment:
Last Closed: 2019-09-03 12:32:26 UTC
Type: Bug


Attachments (Terms of Use)

Description Artem S. Tashkinov 2016-03-24 10:17:18 UTC
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@perex.cz>
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

Comment 1 Josh Boyer 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.

Comment 2 Artem S. Tashkinov 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.

Comment 3 Yauheni Kaliuta 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

Comment 4 Yauheni Kaliuta 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.

Comment 5 Carlos Alberto Lopez Perez 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

Comment 6 Artem S. Tashkinov 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.

Comment 7 Yauheni Kaliuta 2018-01-31 20:38:20 UTC
*** Bug 1490975 has been marked as a duplicate of this bug. ***

Comment 8 Stephan Mueller 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.

Comment 9 Yauheni Kaliuta 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",
};

Comment 10 Yauheni Kaliuta 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
};

Comment 11 Stephan Mueller 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.

Comment 12 Yauheni Kaliuta 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).

Comment 13 Yauheni Kaliuta 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.

Comment 14 Mark J. Cox 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?

Comment 15 Yauheni Kaliuta 2018-10-26 21:05:17 UTC
Upstream maintainer did no share opinion about that (I made a couple of implementations)

Comment 16 Ben Cotton 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.

Comment 17 Yauheni Kaliuta 2018-11-27 14:05:15 UTC
The bug is still valid, moving to F29

Comment 18 Laurie Barry 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.

Comment 19 Stanislav Kozina 2019-01-23 13:06:43 UTC
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/

Comment 20 Mark J. Cox 2019-01-29 12:45:37 UTC
Proposed upstream patch is based on OpenSSL now at https://lore.kernel.org/linux-modules/xunybm3z94j6.fsf@redhat.com/T/#t

Comment 21 Fedora Update System 2019-08-19 09:10:07 UTC
FEDORA-2019-e11df00d17 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-e11df00d17

Comment 22 Fedora Update System 2019-08-20 00:41:58 UTC
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

Comment 23 Fedora Update System 2019-09-03 12:32:26 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.