Netdev Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
	Sedat Dilek <sedat.dilek@gmail.com>,
	George Spelvin <lkml@sdf.org>, Amit Klein <aksecurity@gmail.com>,
	Eric Dumazet <edumazet@google.com>,
	"Jason A. Donenfeld" <Jason@zx2c4.com>,
	Andy Lutomirski <luto@kernel.org>,
	Kees Cook <keescook@chromium.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	tytso@mit.edu, Florian Westphal <fw@strlen.de>,
	Marc Plumb <lkml.mplumb@gmail.com>
Subject: Re: [PATCH 2/2] random32: add noise from network and scheduling activity
Date: Tue, 1 Sep 2020 13:57:55 +0200	[thread overview]
Message-ID: <20200901115755.GA1059@1wt.eu> (raw)
In-Reply-To: <ed5d4d2a-0f8f-f202-8c4f-9fc3d4307e97@gmail.com>

Hi Eric,

On Tue, Sep 01, 2020 at 12:24:38PM +0200, Eric Dumazet wrote:
> There is not much entropy here really :
> 
> 1) dev & txq are mostly constant on a typical host (at least the kind of hosts that is targeted by 
> Amit Klein and others in their attacks.
> 
> 2) len is also known by the attacker, attacking an idle host.
> 
> 3) skb are also allocations from slab cache, which tend to recycle always the same pointers (on idle hosts)
> 
> 
> 4) jiffies might be incremented every 4 ms (if HZ=250)

I know. The point is essentially that someone "remote" or with rare access
to the host's memory (i.e. in a VM on the same CPU sharing L1 with some
CPU vulnerabilities) cannot synchronize with the PRNG and easily stay
synchronized forever. Otherwise I totally agree that these are pretty
weak. But in my opinion they are sufficient to turn a 100% success into
way less. I try not to forget that we're just trying to make a ~15-bit
port require ~2^14 attempts on average. Oh and by the way the number of
calls also counts here.

> Maybe we could feed percpu prandom noise with samples of ns resolution timestamps,
> lazily cached from ktime_get() or similar functions.
>
> This would use one instruction on x86 to update the cache, with maybe more generic noise.

Sure! I think the principle here allows to easily extend it to various
places, and the more the better. Maybe actually we'll figure that there
are plenty of sources of randomness that were not considered secure enough
to feed /dev/random while they're perfectly fine for such use cases.

> diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
> index 4c47f388a83f17860fdafa3229bba0cc605ec25a..a3e026cbbb6e8c5499ed780e57de5fa09bc010b6 100644
> --- a/kernel/time/timekeeping.c
> +++ b/kernel/time/timekeeping.c
> @@ -751,7 +751,7 @@ ktime_t ktime_get(void)
>  {
>         struct timekeeper *tk = &tk_core.timekeeper;
>         unsigned int seq;
> -       ktime_t base;
> +       ktime_t res, base;
>         u64 nsecs;
>  
>         WARN_ON(timekeeping_suspended);
> @@ -763,7 +763,9 @@ ktime_t ktime_get(void)
>  
>         } while (read_seqcount_retry(&tk_core.seq, seq));
>  
> -       return ktime_add_ns(base, nsecs);
> +       res = ktime_add_ns(base, nsecs);
> +       __this_cpu_add(prandom_noise, (unsigned long)ktime_to_ns(res));
> +       return res;
>  }
>  EXPORT_SYMBOL_GPL(ktime_get);

Actually it could even be nice to combine it with __builtin_return_address(0)
given the large number of callers this one has! But I generally agree with
your proposal.

Thanks,
Willy

  reply	other threads:[~2020-09-01 11:59 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-01  6:43 [PATCH 0/2] prandom_u32: make output less predictable Willy Tarreau
2020-09-01  6:43 ` [PATCH 1/2] random32: make prandom_u32() output unpredictable Willy Tarreau
2020-09-01  8:33   ` Yann Ylavic
2020-09-01  8:39     ` Willy Tarreau
2020-09-01  8:46       ` Sedat Dilek
2020-09-01  8:56         ` Willy Tarreau
2020-09-01  9:26           ` Sedat Dilek
2020-09-01 13:10   ` David Laight
2020-09-01 13:16     ` Willy Tarreau
     [not found]       ` <CANEQ_+Kuw6cxWRBE6NyXkr=8p3W-1f=o1q91ZESeueEnna9fvw@mail.gmail.com>
2020-09-14 16:16         ` Sedat Dilek
2020-09-14 16:29           ` Willy Tarreau
2020-09-14 16:48             ` Sedat Dilek
2020-09-01  6:43 ` [PATCH 2/2] random32: add noise from network and scheduling activity Willy Tarreau
2020-09-01 10:24   ` Eric Dumazet
2020-09-01 11:57     ` Willy Tarreau [this message]
2020-09-01 14:41 ` [PATCH 0/2] prandom_u32: make output less predictable Sedat Dilek
2020-09-01 14:55   ` Willy Tarreau
2020-09-01 15:19     ` Eric Dumazet

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=20200901115755.GA1059@1wt.eu \
    --to=w@1wt.eu \
    --cc=Jason@zx2c4.com \
    --cc=aksecurity@gmail.com \
    --cc=edumazet@google.com \
    --cc=eric.dumazet@gmail.com \
    --cc=fw@strlen.de \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkml.mplumb@gmail.com \
    --cc=lkml@sdf.org \
    --cc=luto@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=sedat.dilek@gmail.com \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=tytso@mit.edu \
    --subject='Re: [PATCH 2/2] random32: add noise from network and scheduling activity' \
    /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

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