public inbox for linux-modules@vger.kernel.org
 help / color / mirror / Atom feed
From: Yusong Gao <a869920004@gmail.com>
To: Luis Chamberlain <mcgrof@kernel.org>
Cc: linux-modules@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] module: Add log information for loading module failures
Date: Wed, 19 Jun 2024 15:37:30 +0800	[thread overview]
Message-ID: <e529ab0e-3b92-4e0b-bf4e-af7cd3266d18@gmail.com> (raw)
In-Reply-To: <ZnHYA9dmtUEPLgYP@bombadil.infradead.org>



On 6/19/24 02:54, Luis Chamberlain wrote:
> On Fri, Jun 14, 2024 at 09:25:19AM +0000, Yusong Gao wrote:
>> Add log information in kernel-space when loading module failures.
>> Try to load the unsigned module and the module with bad signature
>> when set 1 to /sys/module/module/parameters/sig_enforce.
>>
>> Unsigned module case:
>> (linux) insmod unsigned.ko
>> [   18.714661] Loading of unsigned module is rejected
>> insmod: can't insert 'unsigned.ko': Key was rejected by service
>> (linux)
>>
>> Bad signature module case:
>> (linux) insmod bad_signature.ko
>> insmod: can't insert 'bad_signature.ko': Key was rejected by service
>> (linux)
>>
>> There have different logging behavior the bad signature case only log
>> in user-space, add log info for fatal errors in module_sig_check().
>>
>> Signed-off-by: Yusong Gao <a869920004@gmail.com>
>> ---
>>   kernel/module/signing.c | 1 +
>>   1 file changed, 1 insertion(+)
>>
>> diff --git a/kernel/module/signing.c b/kernel/module/signing.c
>> index a2ff4242e623..6a6493c8f7e4 100644
>> --- a/kernel/module/signing.c
>> +++ b/kernel/module/signing.c
>> @@ -113,6 +113,7 @@ int module_sig_check(struct load_info *info, int flags)
>>   		 * unparseable signatures, and signature check failures --
>>   		 * even if signatures aren't required.
>>   		 */
>> +		pr_notice("Loading module failed (errno=%d)\n", -err);
>>   		return err;
> 
> I welcome pr_debug() messages but if we were to add a regular print for every
> single type of failure we'd clutter the code, we don't want that.
> 
>    Luis

Thanks for your reply!
Agreed. I'll make that change. The reason I select the notice print 
level is because I found the codes in module_sig_check() use notice 
level when signature enforced. In fact the pr_debug() is more suitable 
for this scene.

BR, Yusong Gao

      reply	other threads:[~2024-06-19  7:37 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-14  9:25 [PATCH] module: Add log information for loading module failures Yusong Gao
2024-06-18 18:54 ` Luis Chamberlain
2024-06-19  7:37   ` Yusong Gao [this message]

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=e529ab0e-3b92-4e0b-bf4e-af7cd3266d18@gmail.com \
    --to=a869920004@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-modules@vger.kernel.org \
    --cc=mcgrof@kernel.org \
    /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