From: Rusty Russell <rusty@rustcorp.com.au>
To: Kyle McMartin <kyle@redhat.com>, linux-kernel@vger.kernel.org
Cc: David Howells <dhowells@redhat.com>,
jstancek@redhat.com, Stephan Mueller <stephan.mueller@atsec.com>
Subject: Re: [PATCH] MODSIGN: flag modules that use cryptoapi and only panic if those are unsigned
Date: Fri, 25 Jan 2013 10:06:01 +1030 [thread overview]
Message-ID: <874ni6qhlq.fsf@rustcorp.com.au> (raw)
In-Reply-To: <20130124190610.GI6538@redacted.bos.redhat.com>
Kyle McMartin <kyle@redhat.com> writes:
> After thinking about it a while, this seems like the best way to solve
> the problem, although it does still kind of offend my delicate
> sensibilities...
You're far too polite. This patch was horrible, partial and ugly.
Stephan Mueller <stephan.mueller@atsec.com> wrote:
> FIPS requires the module (in our case the static kernel binary with its
> kernel crypto API plus all the crypto kernel modules) to be unavailable
> if the module signature fails. That is an unconditional requirement.
"the module signature" here being the signature of any crypto module,
I'm guessing from Kyle's awful patch. Any crypto module, or just some?
Presumably any module used by any crypto module, too?
Because you can panic when a !sig_ok module registers a crypto
algorithm. Or you can panic when anyone registers a crypto algorithm
after any module has failed the signature check.
But it doesn't make much sense to pick on the crypto modules, since
they're not well isolated from the rest of the kernel.
Thanks,
Rusty.
next prev parent reply other threads:[~2013-01-25 3:04 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-22 18:43 [PATCH] MODSIGN: only panic in fips mode if sig_enforce is set Kyle McMartin
2013-01-22 23:17 ` Rusty Russell
2013-01-23 11:26 ` David Howells
2013-01-23 15:18 ` Stephan Mueller
2013-01-24 14:59 ` Kyle McMartin
2013-01-25 11:28 ` Stephan Mueller
2013-01-24 19:06 ` [PATCH] MODSIGN: flag modules that use cryptoapi and only panic if those are unsigned Kyle McMartin
2013-01-24 19:21 ` Kyle McMartin
2013-01-24 23:36 ` Rusty Russell [this message]
2013-01-25 5:45 ` Kyle McMartin
2013-01-25 12:42 ` Stephan Mueller
2013-02-03 23:34 ` Rusty Russell
2013-01-25 12:46 ` Stephan Mueller
2013-01-25 12:18 ` Stephan Mueller
2013-02-05 22:58 ` [RFC PATCH] fips: check whether a module registering an alg or template is signed Kyle McMartin
2013-02-06 8:02 ` Stephan Mueller
2013-02-06 16:15 ` Kyle McMartin
2013-02-06 17:45 ` Stephan Mueller
2013-02-06 18:18 ` Kyle McMartin
2013-01-25 0:14 ` [PATCH] MODSIGN: flag modules that use cryptoapi and only panic if those are unsigned David Howells
2013-01-25 3:20 ` Matthew Garrett
2013-01-25 12:23 ` Stephan Mueller
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=874ni6qhlq.fsf@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=dhowells@redhat.com \
--cc=jstancek@redhat.com \
--cc=kyle@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=stephan.mueller@atsec.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).