linux-kernel - Re: [BUG/PATCH] kernel RNG and its secrets

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 18 Mar 2015 13:41:36 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	Hannes Frederic Sowa <hannes@...essinduktion.org>
Cc:	Daniel Borkmann <daniel@...earbox.net>,
	Stephan Mueller <smueller@...onox.de>,
	mancha <mancha1@...o.com>, linux-kernel@...r.kernel.org,
	linux-crypto@...r.kernel.org, herbert@...dor.apana.org.au,
	dborkman@...hat.com
Subject: Re: [BUG/PATCH] kernel RNG and its secrets

Maybe we should add a kernel self-test that automatically checks
whether or not memset_explicit() gets optimized away?  Otherwise we
might not notice when gcc or how we implement barrier() or whatever
else we end up using ends up changing.

It shold be something that is really fast, so it might be a good idea
to simply automatically run it as part of an __initcall()
unconditionally.  We can debate where the __initcall() lives, but I'd
prefer that it be run even if the crypto layer isn't configured for
some reason.  Hopefully such an self-test is small enough that the
kernel bloat people won't complain.  :-)

							 -Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/