From: Neil Horman <nhorman@tuxdriver.com>
To: Jarod Wilson <jarod@redhat.com>
Cc: linux-crypto@vger.kernel.org, linux-kernel@vger.kernel.org,
Herbert Xu <herbert@gondor.apana.org.au>
Subject: Re: [PATCH] crypto: tcrypt: add option to not exit on success
Date: Tue, 12 May 2009 20:37:27 -0400 [thread overview]
Message-ID: <20090513003727.GA12788@localhost.localdomain> (raw)
In-Reply-To: <200905121602.45960.jarod@redhat.com>
On Tue, May 12, 2009 at 04:02:45PM -0400, Jarod Wilson wrote:
> On Monday 11 May 2009 10:06:32 Jarod Wilson wrote:
> > At present, the tcrypt module always exits with an -EAGAIN upon
> > successfully completing all the tests its been asked to run. There
> > are cases where it would be much simpler to verify all tests passed
> > if tcrypt simply stayed loaded (i.e. returned 0). Specifically, in
> > fips mode, all self-tests need to be run from the initrd, and its
> > much simpler to check the ret from modprobe for success than to
> > scrape dmesg. To make this doable, I've simply added a module param
> > to allow this behavior, leaving the default behavior more or less
> > the same as before, although now we're tracking all success/failure
> > rets as well.
>
> I've been reminded that a self-test failure in fips mode means an
> immediate panic, so modprobe never sees the ret in that case, but if
> the module load failed for other reasons, a non-zero return value
> from modprobe is possible w/o traversing the code paths that trigger
> a self-test failure panic. For one, if the tcrypt module were to go
> missing for some reason, modprobe would have a non-zero ret, and the
> initrd would need to handle panicking the system.
>
> Would there be any objections to dropping the noexit parameter
> entirely and just making its behavior the default? It would make
> all users regardless of fips mode notice failures more readily.
>
I think thats a fine idea. Theres no reason that a user of the tcrypt module
can't manually rmmod it when the testing is done. Doing it that way just seems
more sane to me to begin with anyway.
Neil
> --
> Jarod Wilson
> jarod@redhat.com
>
next prev parent reply other threads:[~2009-05-13 0:37 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-11 14:06 [PATCH] crypto: tcrypt: add option to not exit on success Jarod Wilson
2009-05-12 20:02 ` Jarod Wilson
2009-05-13 0:37 ` Neil Horman [this message]
2009-05-13 1:30 ` Herbert Xu
2009-05-13 11:08 ` Neil Horman
2009-05-13 11:38 ` Herbert Xu
2009-05-13 13:12 ` Jarod Wilson
2009-05-13 13:27 ` Herbert Xu
2009-05-13 13:37 ` Jarod Wilson
2009-05-13 14:03 ` Herbert Xu
2009-05-13 16:40 ` [PATCH v2] crypto: tcrypt: do not exit on success in fips mode Jarod Wilson
2009-05-13 17:32 ` Neil Horman
2009-05-27 5:10 ` Herbert Xu
2009-05-13 14:02 ` [PATCH] crypto: tcrypt: add option to not exit on success Neil Horman
2009-05-13 16:53 ` Jarod Wilson
2009-05-13 23:45 ` Herbert Xu
2009-05-14 12:48 ` Jarod Wilson
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=20090513003727.GA12788@localhost.localdomain \
--to=nhorman@tuxdriver.com \
--cc=herbert@gondor.apana.org.au \
--cc=jarod@redhat.com \
--cc=linux-crypto@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.