[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200811035815.GB9327@1wt.eu>
Date: Tue, 11 Aug 2020 05:58:15 +0200
From: Willy Tarreau <w@....eu>
To: George Spelvin <lkml@....org>
Cc: netdev@...r.kernel.org, aksecurity@...il.com,
torvalds@...ux-foundation.org, edumazet@...gle.com,
Jason@...c4.com, luto@...nel.org, keescook@...omium.org,
tglx@...utronix.de, peterz@...radead.org, tytso@....edu,
lkml.mplumb@...il.com, stephen@...workplumber.org, fw@...len.de
Subject: Re: [DRAFT PATCH] random32: make prandom_u32() output unpredictable
On Tue, Aug 11, 2020 at 03:47:24AM +0000, George Spelvin wrote:
> On Mon, Aug 10, 2020 at 01:47:00PM +0200, Willy Tarreau wrote:
> > except that I retrieve it only on 1/8 calls
> > and use the previous noise in this case.
>
> Er... that's quite different. I was saying you measure them all, and do:
That was my first approach and it resulted in a significant performance
loss, hence the change (and the resulting ugly construct with the counter).
> > + if (++s->count >= 8) {
> > + v3 ^= s->noise;
> > + s->noise += random_get_entropy();
> > + s->count = 0;
> > + }
> > +
>
> - Can you explain why you save the "noise" until next time? Is this meant to
> make it harder for an attacker to observe the time?
Just to make the observable call not depend on immediately measurable TSC
values. It's weak, but the point was that when mixing attack traffic with
regular one, if you can measure the time variations on TSC to know when
it was used and don't have its resulting effect at the same time, it's
harder to analyse than when you have both at once.
> - How about doing away with s->count and making it statistical:
>
> + if ((v3 & 7) == 0)
> + v3 ^= random_get_entropy();
Absolutely. I just kept the counter from previous attempt. But Linus
prefers that we completely remove TSC calls from direct calls due to
old VMs that were slow at this. We could collect it anywhere else once
in a while instead.
Willy
Powered by blists - more mailing lists