linux-modules.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jinchao Wang <wangjinchao600@gmail.com>
To: Sami Tolvanen <samitolvanen@google.com>
Cc: Luis Chamberlain <mcgrof@kernel.org>,
	Petr Pavlu <petr.pavlu@suse.com>,
	Daniel Gomez <da.gomez@kernel.org>,
	linux-modules@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/5] module: Fix module_sig_check() for modules with ignored modversions/vermagic
Date: Mon, 25 Aug 2025 11:17:05 +0800	[thread overview]
Message-ID: <6cd0f597-d56e-4a20-bf6b-42cebacdd4c8@gmail.com> (raw)
In-Reply-To: <CABCJKucGtbZw_DCpnbUr7cQeU+_DF97YTeDVgPX7tTyPwNabog@mail.gmail.com>

On 8/23/25 03:36, Sami Tolvanen wrote:
> On Fri, Aug 22, 2025 at 5:55 AM Jinchao Wang <wangjinchao600@gmail.com> wrote:
>>
>> The current signature check logic incorrectly fails modules that have
>> valid signatures when the caller specifies MODULE_INIT_IGNORE_MODVERSIONS
>> or MODULE_INIT_IGNORE_VERMAGIC flags. This happens because the code
>> treats these flags as indicating a "mangled module" and skips signature
>> verification entirely.
>>
>> The key insight is that the intent of the caller (to ignore modversions
>> or vermagic) should not affect signature verification. A module with
>> a valid signature should be verified regardless of whether the caller
>> wants to ignore versioning information.
> 
> Why would you need to ignore versions when loading signed modules?
> Here's the original series that added this check and I feel it's very
> much relevant still:
> 
> https://lore.kernel.org/lkml/20160423184421.GL3348@decadent.org.uk/
> 
> Sami

Hi Sami,

Thanks for explaining the historical context. I think there are two 
possible understandings of "ignore."

The original seems to be "do not check, but still taint the module." My 
patch was based on the understanding that "ignore" means to allow the 
module, even if it is not signed or is signed with a different key.

Given your feedback, I've decided to drop the patch for now.
-- 
Best regards,
Jinchao

  reply	other threads:[~2025-08-25  3:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-22 12:54 [PATCH 0/5] Module loading error handling improvements Jinchao Wang
2025-08-22 12:54 ` [PATCH 1/5] module: Fix module_sig_check() for modules with ignored modversions/vermagic Jinchao Wang
2025-08-22 19:36   ` Sami Tolvanen
2025-08-25  3:17     ` Jinchao Wang [this message]
2025-08-22 12:54 ` [PATCH 2/5] module: signing: Use pr_err for signature rejection Jinchao Wang
2025-08-22 12:54 ` [PATCH 3/5] module: show why force load fails Jinchao Wang
2025-08-22 12:54 ` [PATCH 4/5] module: centralize no-versions force load check Jinchao Wang
2025-08-22 12:54 ` [PATCH 5/5] module: separate vermagic and livepatch checks Jinchao Wang

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=6cd0f597-d56e-4a20-bf6b-42cebacdd4c8@gmail.com \
    --to=wangjinchao600@gmail.com \
    --cc=da.gomez@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-modules@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    --cc=petr.pavlu@suse.com \
    --cc=samitolvanen@google.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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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 NNTP newsgroup(s).