Re: [PATCH] crypto: Force panic on continuous CPRNG test failurewhen in FIPS mode

[Neil Horman]

On Wed, Jan 28, 2009 at 11:17:41PM +1100, Herbert Xu wrote:
> On Wed, Jan 28, 2009 at 07:15:11AM -0500, Neil Horman wrote:
> > On Wed, Jan 28, 2009 at 03:18:28PM +1100, Herbert Xu wrote:
> > > 
> > > I'm OK with this change but I'd like it to look like:
> > > 
> > > 	if (fips_enabled) {
> > > 		panic(...)
> > > 	}
> > > 
> > > 	blah blah blah
> > > 
> > > This way the FIPS crap doesn't get in the way of everyday use.
> > > 
> > > Thanks,
> > 
> > 
> > Sure, new patch, extra commentary removed.  Also brought the panic/printk text
> > into agreement.
> 
> Hmm no I wasn't referring to the comment, but rather that you
> should just move the stuff in the else branch into the main code
> path since the panic makes the else redundant.
> 

Ahh, my bad.  Here you go



FIPS 140-2 specifies that all access to various cryptographic modules be
prevented in the event that any of the provided self tests fail on the various
implemented algorithms.  We already panic when any of the test in testmgr.c
fail when we are operating in fips mode.  The continuous test in the cprng here
was missed when that was implmented.  This code simply checks for the
fips_enabled flag if the test fails, and warns us via syslog or panics the box
accordingly.

Signed-off-by: Neil Horman <nhorman@xxxxxxxxxxxxx>

diff --git a/crypto/ansi_cprng.c b/crypto/ansi_cprng.c
index 7447806..9ec0f0a 100644
--- a/crypto/ansi_cprng.c
+++ b/crypto/ansi_cprng.c
@@ -132,9 +132,15 @@ static int _get_more_prng_bytes(struct prng_context *ctx)
 			 */
 			if (!memcmp(ctx->rand_data, ctx->last_rand_data,
 					DEFAULT_BLK_SZ)) {
+				if (fips_enabled) {
+					panic("cprng %p Failed repetition check!\n",
+						ctx);  
+				} 
+
 				printk(KERN_ERR
 					"ctx %p Failed repetition check!\n",
 					ctx);
+
 				ctx->flags |= PRNG_NEED_RESET;
 				return -EINVAL;
 			}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/