archive mirror
 help / color / mirror / Atom feed
From: "Jason A. Donenfeld" <>
To: Eric Biggers <>
Cc: Theodore Ts'o <>,,,
	Andy Polyakov <>
Subject: Re: [PATCH] random: avoid mis-detecting a slow counter as a cycle counter
Date: Thu, 21 Apr 2022 22:20:35 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hi Eric,

On Thu, Apr 21, 2022 at 9:30 PM Eric Biggers <> wrote:
> The method that try_to_generate_entropy() uses to detect a cycle counter
> is to check whether two calls to random_get_entropy() return different
> values.  This is uncomfortably prone to false positives if
> random_get_entropy() is a slow counter, as the two calls could return
> different values if the counter happens to be on the cusp of a change.
> Making things worse, the task can be preempted between the calls.
> This is problematic because try_to_generate_entropy() doesn't do any
> real entropy estimation later; it always credits 1 bit per loop
> iteration.  To avoid crediting garbage, it relies entirely on the
> preceding check for whether a cycle counter is present.
> Therefore, increase the number of counter comparisons from 1 to 3, to
> greatly reduce the rate of false positive cycle counter detections.

Thanks for the patch. It seems like this at least is not worse than
before. But before I commit this and we forget about the problem for a
while, I was also wondering if we can do much, much better than before,
and actually make this "work" with slow counters. Right now, the core
algorithm is:

    while (!crng_ready()) {
        if (no timer) mod_timer(jiffies + 1);
	schedule();    // <---- calls the timer, which does credit_entry_bits(1)
	sample = rdtsc;

So we credit 1 bit every time that timer fires. What if the timer
instead did this:

    static void entropy_timer(struct timer_list *t)
        struct timer_state *s = container_of(...t...);
        if (++s->samples == s->samples_per_bit) {
            s->samples = 0;

Currently, samples_per_bit is 1. What if we make it >1 on systems with
slow cycle counters? The question then is: how do we relate some
information about cycle counter samples to the samples_per_bit estimate?
The jitter stuff in crypto/ does something. Andy (CC'd) mentioned to me
last week that he did something some time ago computing FFTs on the fly
or something like that. And maybe there are other ideas still. I wonder
if we can find something appropriate for the kernel here.

Any thoughts on that direction?


  reply	other threads:[~2022-04-21 20:20 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-21 19:29 [PATCH] random: avoid mis-detecting a slow counter as a cycle counter Eric Biggers
2022-04-21 20:20 ` Jason A. Donenfeld [this message]
2022-04-21 20:49   ` Eric Biggers
2022-04-21 22:59     ` Jason A. Donenfeld
2022-04-21 23:14       ` Eric Biggers

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \

* 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).