Re: [dpdk-dev] [PATCH 1/6] eal: replace libc-based random number generation with LFSR

[Neil Horman <nhorman@tuxdriver.com>]

On Fri, May 17, 2019 at 11:10:25PM +0200, Mattias Rönnblom wrote:
> On 2019-05-17 21:27, Neil Horman wrote:
> 
> > > > > diff --git a/lib/librte_eal/common/rte_random.c b/lib/librte_eal/common/rte_random.c
> > > > > new file mode 100644
> > > > > index 000000000..4d3cf5226
> > > > > --- /dev/null
> > > > > +++ b/lib/librte_eal/common/rte_random.c
> > > > > @@ -0,0 +1,139 @@
> > > > > +/* SPDX-License-Identifier: BSD-3-Clause
> > > > > + * Copyright(c) 2019 Ericsson AB
> > > > > + */
> > > > > +
> > > > > +#include <stdlib.h>
> > > > > +
> > > > > +#include <rte_branch_prediction.h>
> > > > > +#include <rte_cycles.h>
> > > > > +#include <rte_eal.h>
> > > > > +#include <rte_lcore.h>
> > > > > +#include <rte_memory.h>
> > > > > +#include <rte_random.h>
> > > > > +
> > > > > +struct rte_rand_state {
> > > > > +	uint64_t z1;
> > > > > +	uint64_t z2;
> > > > > +	uint64_t z3;
> > > > > +	uint64_t z4;
> > > > > +	uint64_t z5;
> > > > > +} __rte_cache_aligned;
> > > > > +
> > > > > +static struct rte_rand_state rand_states[RTE_MAX_LCORE];
> > > > > +
> > > > 
> > > > It just occured to me that this variable embodies all the state of the rng.
> > > > Whats to stop an attacker from digging through ram to get this info and
> > > > predicting what the output will be?  I understand that this rng probably
> > > > shouldn't be considered secure for cryptographic use, but it is used in the
> > > > ipsec test example, so it could be mistaken for an rng that is.
> > > > 
> > > 
> > > rte_rand() was never safe for use in cryptography, and now it's spelled out
> > > in the API documentation.
> > > 
> > > If the IPsec example uses rte_rand() for anything security-related, it's a
> > > bug or at least should be accompanied by a comment, in my opinion.
> > > 
> > I would agree with that, but the fact remains that the examples use rte_rand in
> > a context that is explicitly in violation of what you are documenting, which
> > certainly seems confusing.
> > 
> > > That said, if you have an attacker who's already broken into your DPDK
> > > process' virtual memory, I'm not sure I understand why he would care much
> > > about the state of the PRNG. Wouldn't he just read your private keys, your
> > > messages in clear text or whatever other secrets you might have in memory?
> > > 
> > Because the term "Breaking in" is a misnomer here.  In unix system, IIRC, global
> > variables are shared accross processes.
> 
> Mutable data, like the BSS section where the PRNG state goes, is not shared.
> 
Yes, you and bruce are right, It is shared, but marked copy on write, so
its safe from the common case of multiple programs loading the object.

Neil

>