From: Rusty Russell <rusty@rustcorp.com.au>
To: Ben Hutchings <ben@decadent.org.uk>
Cc: David Howells <dhowells@redhat.com>,
David Woodhouse <dwmw2@infradead.org>,
keyrings@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] module: Invalidate signatures on force-loaded modules
Date: Thu, 28 Apr 2016 09:24:40 +0930 [thread overview]
Message-ID: <87pota4ngf.fsf@rustcorp.com.au> (raw)
In-Reply-To: <1461704447.5852.17.camel@decadent.org.uk>
Ben Hutchings <ben@decadent.org.uk> writes:
> On Tue, 2016-04-26 at 20:07 +0930, Rusty Russell wrote:
>> Ben Hutchings <ben@decadent.org.uk> writes:
>> > - if (info->len > markerlen &&
>> > + /*
>> > + * Require flags == 0, as a module with version information
>> > + * removed is no longer the module that was signed
>> > + */
>> > + if (flags == 0 &&
>> This check is a bit lazy. We could have other flags in future,
>> so this should really be !(flags &
>> (MODULE_INIT_IGNORE_MODVERSIONS|MODULE_INIT_IGNORE_VERMAGIC) right?
>
> Yes we could, but I'd prefer this to fail-safe in case no-one thinks
> about whether it should be updated then.
Yeah, line ball. We could screw up either way, and I can't think of
an reasonable new flag off the top of my head to give a concrete
example.
I've applied all three, thanks!
Rusty.
next prev parent reply other threads:[~2016-04-28 0:27 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-23 18:44 [PATCH 0/3] Module signing and version info Ben Hutchings
2016-04-23 18:45 ` [PATCH 1/3] module: Invalidate signatures on force-loaded modules Ben Hutchings
2016-04-26 10:37 ` Rusty Russell
2016-04-26 21:00 ` Ben Hutchings
2016-04-27 23:54 ` Rusty Russell [this message]
2016-04-23 18:45 ` [PATCH 2/3] Documentation/module-signing.txt: Note need for version info if reusing a key Ben Hutchings
2016-04-23 18:45 ` [PATCH 3/3] module: Disable MODULE_FORCE_LOAD when MODULE_SIG_FORCE is enabled Ben Hutchings
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=87pota4ngf.fsf@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=ben@decadent.org.uk \
--cc=dhowells@redhat.com \
--cc=dwmw2@infradead.org \
--cc=keyrings@vger.kernel.org \
--cc=linux-kernel@vger.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 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.