From: George Spelvin <lkml@SDF.ORG>
To: "Theodore Y. Ts'o" <tytso@mit.edu>
Cc: David Laight <David.Laight@ACULAB.COM>,
Dan Williams <dan.j.williams@intel.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Qian Cai <cai@lca.pw>, Kees Cook <keescook@chromium.org>,
Michal Hocko <mhocko@suse.com>,
Andrew Morton <akpm@linux-foundation.org>,
Linux MM <linux-mm@kvack.org>,
Thomas Garnier <thgarnie@google.com>,
lkml@sdf.org
Subject: lib/random32.c security
Date: Wed, 1 Apr 2020 05:17:59 +0000 [thread overview]
Message-ID: <20200401051759.GA9616@SDF.ORG> (raw)
In-Reply-To: <20200329214214.GB768293@mit.edu>
On Sun, Mar 29, 2020 at 05:42:14PM -0400, Theodore Y. Ts'o wrote:
> If anyone is trying to rely on prandom_u32() as being "strong" in any
> sense of the word in terms of being reversable by attacker --- they
> shouldn't be using prandom_u32(). That's going to be true no matter
> *what* algorithm we use.
>
> Better distribution? Sure. Making prandom_u32() faster? Absolutely;
> that's its primary Raison d'Etre.
I'd like your comments on an idea I had to add a second PRNG state
for security-interesting applications.
There are some ASLR tasks, notably slab freelist shuffling and
per-syscall stack offset randomization, which need a Very Fast
source of random numbers. No crypto-grade generator qualifies,
and both currently use very bad ad-hoc generators.
The per-syscall stack offset code currently uses the lsbits of the
TSC, which is obviously bad as they're observable by the (presumed
malicious) userspace immediately before the call and thus highly
predictable.
Likewise, the slab shuffling currently precomputes a permutation and
just picks a random starting position for every slab.
Both are saved by the fact that their PRNG outputs are mostly
unobservable, so an attacker can't start to predict them.
I was thinking that a second PRNG, identical to the prandom_u32()
one but seeded speartely, could be used for this purpose. The good
distribution would preclude trivial patterns in their output, which
is about all we can hope for.
The difference is that it would only be used for applications which
both require high speed and are (mostly) unobservable to an attacker.
Any opinions, anyone?
prev parent reply other threads:[~2020-04-01 5:19 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-03 9:51 [RFC PATCH v1 46/50] mm/shuffle.c: use get_random_max() George Spelvin
2020-03-28 18:23 ` Dan Williams
2020-03-28 18:28 ` [RFC PATCH v1 00/52] Audit kernel random number use George Spelvin
2020-03-29 12:21 ` David Laight
2020-03-29 17:41 ` George Spelvin
2020-03-29 21:42 ` Theodore Y. Ts'o
2020-03-30 9:27 ` David Laight
2020-04-01 5:17 ` George Spelvin [this message]
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=20200401051759.GA9616@SDF.ORG \
--to=lkml@sdf.org \
--cc=David.Laight@ACULAB.COM \
--cc=akpm@linux-foundation.org \
--cc=cai@lca.pw \
--cc=dan.j.williams@intel.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=thgarnie@google.com \
--cc=tytso@mit.edu \
/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).