From: Chris Samuel <chris@csamuel.org>
To: Josh Boyer <jwboyer@gmail.com>
Cc: linux-kernel@vger.kernel.org,
Rusty Russell <rusty@rustcorp.com.au>,
dhowells@redhat.com
Subject: Re: [PATCH] MODSIGN: Warn when sign check fails due to -ENOKEY
Date: Sat, 12 Jan 2013 18:50:39 +1100 [thread overview]
Message-ID: <50F115CF.8050000@csamuel.org> (raw)
In-Reply-To: <CA+5PVA7F1RV3=Ynv+et=ZzOTRszop=sXY2QscuuHGO2RhLpSYg@mail.gmail.com>
On 12/01/13 00:49, Josh Boyer wrote:
> On Fri, Jan 11, 2013 at 4:44 AM, Chris Samuel <chris@csamuel.org> wrote:
>
>> /* Please CC me in responses, I am not subscribed to LKML */
>>
>> diff --git a/kernel/module.c b/kernel/module.c
>> index 250092c..27de534 100644
>> --- a/kernel/module.c
>> +++ b/kernel/module.c
>> @@ -2443,8 +2443,10 @@ static int module_sig_check(struct load_info *info)
>> if (err < 0 && fips_enabled)
>> panic("Module verification failed with error %d in FIPS
>> mode\n",
>> err);
>> - if (err == -ENOKEY && !sig_enforce)
>> + if (err == -ENOKEY && !sig_enforce) {
>> + printk_once(KERN_DEBUG "Module verification failed, required
>> key not present, tainting kernel\n");
>> err = 0;
>> + }
>> return err;
>
> I'd suggest putting the printk in load_module where we call the
> add_taint_module function instead.
I did ponder that, but I used module_sig_check() instead as here we know
explicitly that the failure is -ENOKEY, that information doesn't seem to
get propagated back to load_module().
Looking at the code again though it seems that any other reason will
make module_sig_check() return non-zero and hence cause the module to
fail to load, so currently we can infer that the reason was -ENOKEY.
I'm happy either way, just my inner pedant thought this was better as in
future module_sig_check() may find another reason to have to return with
a zero status when modules aren't signed and so we can no longer tell
the user the reason the signature failed.
Rusty, which is your preference?
> Also, you might want to make the priority a bit higher if it's meant
> to be informative. Something like KERN_INFO.
Yup, sounds good, I see Rusty suggested KERN_NOTICE so I'll use that.
cheers,
Chris
--
Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC
prev parent reply other threads:[~2013-01-12 7:51 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-11 9:44 [PATCH] MODSIGN: Warn when sign check fails due to -ENOKEY Chris Samuel
2013-01-11 13:49 ` Josh Boyer
2013-01-12 0:30 ` Rusty Russell
2013-01-12 7:50 ` Chris Samuel [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=50F115CF.8050000@csamuel.org \
--to=chris@csamuel.org \
--cc=dhowells@redhat.com \
--cc=jwboyer@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rusty@rustcorp.com.au \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.