On Thu, Aug 27, 2020 at 3:09 AM Willy Tarreau wrote:
>
> Hi Amit,
>
> On Thu, Aug 27, 2020 at 02:06:39AM +0300, Amit Klein wrote:
> > Hi
> >
> > Is there an ETA for this patch then?
>
> No particular ETA on my side, I was waiting for potential criticisms
> before going further. I suspect that if n
Hi Amit,
On Thu, Aug 27, 2020 at 02:06:39AM +0300, Amit Klein wrote:
> Hi
>
> Is there an ETA for this patch then?
No particular ETA on my side, I was waiting for potential criticisms
before going further. I suspect that if nobody complains anymore, it's
an implicit voucher and I'll have to clea
On Thu, Aug 20, 2020 at 10:05 AM Willy Tarreau wrote:
>
> On Thu, Aug 20, 2020 at 08:58:38AM +0200, Willy Tarreau wrote:
> > I've just pushed a new branch "20200820-siphash-noise" that I also
> > rebased onto latest master. It's currently running make allmodconfig
> > here, so that will take a whi
On Thu, Aug 20, 2020 at 08:58:38AM +0200, Willy Tarreau wrote:
> I've just pushed a new branch "20200820-siphash-noise" that I also
> rebased onto latest master. It's currently running make allmodconfig
> here, so that will take a while, but I think it's OK as random32.o is
> already OK. I've also
On Thu, Aug 20, 2020 at 08:08:43AM +0200, Willy Tarreau wrote:
> On Thu, Aug 20, 2020 at 06:42:23AM +0200, Sedat Dilek wrote:
> > On Thu, Aug 20, 2020 at 6:33 AM Willy Tarreau wrote:
> > >
> > > On Thu, Aug 20, 2020 at 05:05:49AM +0200, Sedat Dilek wrote:
> > > > We have the same defines for K0 an
On Thu, Aug 20, 2020 at 06:42:23AM +0200, Sedat Dilek wrote:
> On Thu, Aug 20, 2020 at 6:33 AM Willy Tarreau wrote:
> >
> > On Thu, Aug 20, 2020 at 05:05:49AM +0200, Sedat Dilek wrote:
> > > We have the same defines for K0 and K1 in include/linux/prandom.h and
> > > lib/random32.c?
> > > More room
On Thu, Aug 20, 2020 at 6:33 AM Willy Tarreau wrote:
>
> On Thu, Aug 20, 2020 at 05:05:49AM +0200, Sedat Dilek wrote:
> > We have the same defines for K0 and K1 in include/linux/prandom.h and
> > lib/random32.c?
> > More room for simplifications?
>
> Definitely, I'm not surprized at all. As I said
On Thu, Aug 20, 2020 at 05:05:49AM +0200, Sedat Dilek wrote:
> We have the same defines for K0 and K1 in include/linux/prandom.h and
> lib/random32.c?
> More room for simplifications?
Definitely, I'm not surprized at all. As I said, the purpose was to
discuss around the proposal, not much more. If
On Sun, Aug 16, 2020 at 6:48 PM Sedat Dilek wrote:
>
> On Sun, Aug 16, 2020 at 5:01 PM Willy Tarreau wrote:
> >
> > Hi,
> >
> > so as I mentioned, I could run several test on our lab with variations
> > around the various proposals and come to quite positive conclusions.
> >
> > Synthetic observa
On Sun, Aug 16, 2020 at 5:01 PM Willy Tarreau wrote:
>
> Hi,
>
> so as I mentioned, I could run several test on our lab with variations
> around the various proposals and come to quite positive conclusions.
>
> Synthetic observations: the connection rate and the SYN cookie rate do not
> seem to be
Hi,
so as I mentioned, I could run several test on our lab with variations
around the various proposals and come to quite positive conclusions.
Synthetic observations: the connection rate and the SYN cookie rate do not
seem to be affected the same way by the prandom changes. One explanation
is th
On Fri, Aug 14, 2020 at 6:05 PM Willy Tarreau wrote:
>
> On Fri, Aug 14, 2020 at 05:32:32PM +0200, Sedat Dilek wrote:
> > commit 94c7eb54c4b8e81618ec79f414fe1ca5767f9720
> > "random32: add a tracepoint for prandom_u32()"
> >
> > ...I gave Willy's patches a try and used the Linux Test Project (LTP)
On Fri, Aug 14, 2020 at 05:32:32PM +0200, Sedat Dilek wrote:
> commit 94c7eb54c4b8e81618ec79f414fe1ca5767f9720
> "random32: add a tracepoint for prandom_u32()"
>
> ...I gave Willy's patches a try and used the Linux Test Project (LTP)
> for testing.
Just FWIW today I could run several relevant tes
On Thu, Aug 13, 2020 at 10:06 AM Willy Tarreau wrote:
>
> On Thu, Aug 13, 2020 at 09:53:11AM +0200, Sedat Dilek wrote:
> > On Wed, Aug 12, 2020 at 5:21 AM Willy Tarreau wrote:
> > >
> > > On Tue, Aug 11, 2020 at 12:51:43PM +0200, Sedat Dilek wrote:
> > > > Can you share this "rebased to mainline"
On Thu, Aug 13, 2020 at 4:00 PM Eric Dumazet wrote:
>
> On Thu, Aug 13, 2020 at 1:27 AM Sedat Dilek wrote:
> >
> > I run a perf session looks like this in my KDE/Plasma desktop-environment:
> >
> > [ PERF SESSION ]
> >
> > 1016 2020-08-13 09:57:24 echo 1 > /proc/sys/kernel/sched_schedstats
> >
I run a perf session looks like this in my KDE/Plasma desktop-environment:
[ PERF SESSION ]
1016 2020-08-13 09:57:24 echo 1 > /proc/sys/kernel/sched_schedstats
1017 2020-08-13 09:57:24 echo prandom_u32 >>
/sys/kernel/debug/tracing/set_event
1018 2020-08-13 09:57:24 echo traceon >
/sys/kerne
On Thu, Aug 13, 2020 at 10:06 AM Willy Tarreau wrote:
>
> On Thu, Aug 13, 2020 at 09:53:11AM +0200, Sedat Dilek wrote:
> > On Wed, Aug 12, 2020 at 5:21 AM Willy Tarreau wrote:
> > >
> > > On Tue, Aug 11, 2020 at 12:51:43PM +0200, Sedat Dilek wrote:
> > > > Can you share this "rebased to mainline"
On Thu, Aug 13, 2020 at 09:53:11AM +0200, Sedat Dilek wrote:
> On Wed, Aug 12, 2020 at 5:21 AM Willy Tarreau wrote:
> >
> > On Tue, Aug 11, 2020 at 12:51:43PM +0200, Sedat Dilek wrote:
> > > Can you share this "rebased to mainline" version of George's patch?
> >
> > You can pick it from there if t
On Wed, Aug 12, 2020 at 5:21 AM Willy Tarreau wrote:
>
> On Tue, Aug 11, 2020 at 12:51:43PM +0200, Sedat Dilek wrote:
> > Can you share this "rebased to mainline" version of George's patch?
>
> You can pick it from there if that helps, but keep in mind that
> it's just experimental code that we us
On Tue, Aug 11, 2020 at 12:51:43PM +0200, Sedat Dilek wrote:
> Can you share this "rebased to mainline" version of George's patch?
You can pick it from there if that helps, but keep in mind that
it's just experimental code that we use to explain our ideas and
that we really don't care a single sec
In the previous discussion...
"Flaw in "random32: update the net random state on interrupt and activity"
...someone referred to .
Someone tested this?
Feedback?
- Sedat -
[0] https://marc.info/?t=15965890352&r=1&w=2
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/log/?h
[ CC netdev ML ]
Hi Willy,
in [1] you say:
> I've applied it on top of George's patch rebased to mainline for simplicity.
> I've used a separate per_cpu noise variable to keep the net_rand_state static
> with its __latent_entropy.
Can you share this "rebased to mainline" version of George's pat
On Mon, Aug 10, 2020 at 11:04:55PM +0200, Willy Tarreau wrote:
> What could be improved is the way the input values are mixed (just
> added hence commutative for now). I didn't want to call a siphash
> round on the hot paths, but just shifting the previous noise value
> before adding would work, su
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:
struct siprand_state {
...
+ uint32_t noise[i];
+
On Tue, Aug 11, 2020 at 05:26:49AM +, George Spelvin wrote:
> On Mon, Aug 10, 2020 at 11:04:55PM +0200, Willy Tarreau wrote:
> > What could be improved is the way the input values are mixed (just
> > added hence commutative for now). I didn't want to call a siphash
> > round on the hot paths, b
On Tue, Aug 11, 2020 at 03:47:24AM +, 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
Linus, George, Florian,
would something in this vein be OK in your opinion ?
- update_process_times still updates the noise
- we don't touch the fast_pool anymore
- we don't read any TSC on hot paths
- we update the noise in xmit from jiffies and a few pointer values instead
I've applied it on t
On Mon, Aug 10, 2020 at 10:45:26AM -0700, Linus Torvalds wrote:
> On Mon, Aug 10, 2020 at 9:59 AM Willy Tarreau wrote:
> >
> > I took what we were already using in add_interrupt_randomness() since
> > I considered that if it was acceptable there, it probably was elsewhere.
>
> Once you've taken a
On Mon, Aug 10, 2020 at 9:59 AM Willy Tarreau wrote:
>
> I took what we were already using in add_interrupt_randomness() since
> I considered that if it was acceptable there, it probably was elsewhere.
Once you've taken an interrupt, you're doing IO anyway, and the
interrupt costs will dominate a
On Mon, Aug 10, 2020 at 09:31:48AM -0700, Linus Torvalds wrote:
> On Mon, Aug 10, 2020 at 4:47 AM Willy Tarreau wrote:
> >
> > Doing testing on real hardware showed that retrieving the TSC on every
> > call had a non negligible cost, causing a loss of 2.5% on the accept()
> > rate and 4% on packet
On Mon, Aug 10, 2020 at 4:47 AM Willy Tarreau wrote:
>
> Doing testing on real hardware showed that retrieving the TSC on every
> call had a non negligible cost, causing a loss of 2.5% on the accept()
> rate and 4% on packet rate when using iptables -m statistics.
And by "real hardware" I assume
On Mon, Aug 10, 2020 at 02:03:02PM +0200, Florian Westphal wrote:
> As this relates to networking, you could also hook perturbation into rx/tx
> softirq processing. E.g. once for each new napi poll round or only once
> for each softnet invocation, depending on cost.
I was wondering what/where to
On Mon, Aug 10, 2020 at 12:01:11PM +, David Laight wrote:
> > /*
> > * On 32-bit machines, we use HSipHash, a reduced-width version of SipHash.
> > * This is weaker, but 32-bit machines are not used for high-traffic
> > @@ -375,6 +377,12 @@ static u32 siprand_u32(struct siprand_state *s)
>
Willy Tarreau wrote:
> On Sun, Aug 09, 2020 at 06:30:17PM +, George Spelvin wrote:
> > Even something simple like buffering 8 TSC samples, and adding them
> > at 32-bit offsets across the state every 8th call, would make a huge
> > difference.
>
> Doing testing on real hardware showed that re
From: Willy Tarreau
> Sent: 10 August 2020 12:47
> On Sun, Aug 09, 2020 at 06:30:17PM +, George Spelvin wrote:
> > Even something simple like buffering 8 TSC samples, and adding them
> > at 32-bit offsets across the state every 8th call, would make a huge
> > difference.
>
> Doing testing on r
Hi George,
On Sun, Aug 09, 2020 at 06:30:17PM +, George Spelvin wrote:
> Even something simple like buffering 8 TSC samples, and adding them
> at 32-bit offsets across the state every 8th call, would make a huge
> difference.
Doing testing on real hardware showed that retrieving the TSC on ev
On Sun, Aug 09, 2020 at 07:33:03PM +0200, Willy Tarreau wrote:
> Not that low in fact because they don't know precisely when the call is
> made. I mean, let's say we're in the worst case, with two VMs running on
> two siblings of the same core, with the same TSC, on a 3 GHz machine. The
> attacker
On Sun, Aug 9, 2020 at 2:10 PM Marc Plumb wrote:
>
> However, I think I'm starting to see your underlying assumptions.
> You're thinking that raw noise data are the only truly unpredictable
> thing so you think that adding it is a defense against attacks like
> foreshadow/spectre/meltdown. You are
+ CC:netdev
( Just FYI: Build and boot on bare metal. )
- Sedat -
On Sun, Aug 9, 2020 at 11:01 PM Sedat Dilek wrote:
>
> Hi George,
>
> I have tried your patch on top of Linux v5.8 with...
>
> commit f227e3ec3b5c ("random32: update the net random state on
> interrupt and activity")
>
> ...rever
(Reseending since I accidentally sent it as HTML which the netdev
mailing list doesn't like)
On 2020-08-09 2:05 p.m., Marc Plumb wrote:
Willy,
On 2020-08-07 3:19 p.m., Willy Tarreau wrote:
If I can figure the state out once,
Yes but how do you take that as granted ? This state doesn't appe
On Sun, Aug 09, 2020 at 11:38:05AM +0200, Willy Tarreau wrote:
> So I gave it a quick test under Qemu and it didn't show any obvious
> performance difference compared to Tausworthe, which is a good thing,
> even though there's a significant amount of measurement noise in each
> case.
Thank you ver
On Sun, Aug 09, 2020 at 11:26:31AM +0300, Amit Klein wrote:
> BITS_PER_LONG==23 ???
> Should be ==32, I guess.
Of course. I've been testing on a 64-bit system so hadn't
exercised that branch yet, and it's a case of "seeing what
I expect to see".
On Sun, Aug 09, 2020 at 06:30:17PM +, George Spelvin wrote:
> I'm trying to understand your attack scenario. I'm assuming that an
> attacker can call prandom_u32() locally.
Well, first, I'm mostly focusing on remote attacks, because if the
attacker has a permanent local access, he can as well
On Sun, Aug 09, 2020 at 05:06:39PM +, George Spelvin wrote:
> On Sun, Aug 09, 2020 at 11:38:05AM +0200, Willy Tarreau wrote:
> > So I gave it a quick test under Qemu and it didn't show any obvious
> > performance difference compared to Tausworthe, which is a good thing,
> > even though there's
On 8/8/20 11:57 PM, George Spelvin wrote:
+#elif BITS_PER_LONG == 23
s/23/32/ ???
--
~Randy
Non-cryptographic PRNGs may have great statistical proprties, but
are usually trivially predictable to someone who knows the algorithm,
given a small sample of their output. An LFSR like prandom_u32() is
particularly simple, even if the sample is widely scattered bits.
It turns out the network st
Hi George,
On Sun, Aug 09, 2020 at 06:57:44AM +, George Spelvin wrote:
> +/*
> + * This is the core CPRNG function. As "pseudorandom", this is not used
> + * for truly valuable things, just intended to be a PITA to guess.
> + * For maximum speed, we do just two SipHash rounds per word. This
47 matches
Mail list logo
