Keyrings Archive mirror
 help / color / mirror / Atom feed

From: Yunseong Kim <ysk@kzalloc.com>
To: Luis Chamberlain <mcgrof@kernel.org>,
	Petr Pavlu <petr.pavlu@suse.com>,
	Daniel Gomez <da.gomez@kernel.org>,
	"Sami Tolvanen <samitolvanen@google.com> David Howells"
	<dhowells@redhat.com>, David Woodhouse <dwmw2@infradead.org>
Cc: linux-modules@vger.kernel.org, keyrings@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: [Question] Non-usage of PKEY_ID_PGP and PKEY_ID_X509 in module signing
Date: Wed, 27 Aug 2025 03:58:35 +0900	[thread overview]
Message-ID: <a40e660e-5a45-420a-8d37-51324242ab9b@kzalloc.com> (raw)

I would like to inquire about the purpose of the PKEY_ID_PGP and
PKEY_ID_X509 identifiers defined in include/linux/module_signature.h.

The enum pkey_id_type is defined as follows:

 enum pkey_id_type {
     PKEY_ID_PGP,        /* OpenPGP generated key ID */
     PKEY_ID_X509,       /* X.509 arbitrary subjectKeyIdentifier */
     PKEY_ID_PKCS7,      /* Signature in PKCS#7 message */
 };

While examining the module signing and verification process, it appears
that the current implementation strictly assumes the use of PKCS#7, making
PKEY_ID_PGP and PKEY_ID_X509 seem unused in this context.

I observed the following:

1. In scripts/sign-file.c, the module_signature structure is explicitly
initialized assuming PKCS#7:

 /* Key identifier type [PKEY_ID_PKCS7] */
 struct module_signature sig_info = { .id_type = PKEY_ID_PKCS7 };

2. In kernel/module_signature.c, the verification function mod_check_sig()
strictly enforces this type and rejects others:

 int mod_check_sig(const struct module_signature *ms, size_t file_len,
           const char *name)
 {
     if (be32_to_cpu(ms->sig_len) >= file_len - sizeof(*ms))
         return -EBADMSG;
 
     if (ms->id_type != PKEY_ID_PKCS7) {
         pr_err("%s: not signed with expected PKCS#7 message\n",
                name);
         return -ENOPKG;
     }
     // ...
 }


3. Furthermore, I noticed that certs/extract-cert.c only defines
   PKEY_ID_PKCS7 locally, seemingly without utilizing the definitions from
   the header for the other types:

#define PKEY_ID_PKCS7 2

Given that the module signature infrastructure seems hardcoded to use
PKCS#7, could anyone clarify if PKEY_ID_PGP and PKEY_ID_X509 are used
elsewhere in the kernel? Are they perhaps placeholders for future
implementations or remnants of past ones?

If they are indeed unused and there are no plans to support them, would
a patch to clean up these unused enum values be welcome? Or is there
another reason for keeping them?

Thank you for your time and clarification.


Best regards,
Yunseong Kim

next             reply	other threads:[~2025-08-26 18:58 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-26 18:58 Yunseong Kim [this message]
2025-09-05 15:09 ` [Question] Non-usage of PKEY_ID_PGP and PKEY_ID_X509 in module signing Sami Tolvanen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a40e660e-5a45-420a-8d37-51324242ab9b@kzalloc.com \
    --to=ysk@kzalloc.com \
    --cc=da.gomez@kernel.org \
    --cc=dhowells@redhat.com \
    --cc=dwmw2@infradead.org \
    --cc=keyrings@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-modules@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=petr.pavlu@suse.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).