From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id C8C1DA05D3 for ; Sun, 19 May 2019 20:32:47 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 218E62C36; Sun, 19 May 2019 20:32:46 +0200 (CEST) Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 47C0E1B53 for ; Sun, 19 May 2019 20:32:44 +0200 (CEST) Received: from cpe-2606-a000-111b-405a-0-0-0-1ff7.dyn6.twc.com ([2606:a000:111b:405a::1ff7] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1hSQbo-0006zY-TM; Sun, 19 May 2019 14:32:40 -0400 Date: Sun, 19 May 2019 14:32:04 -0400 From: Neil Horman To: Mattias =?iso-8859-1?Q?R=F6nnblom?= Cc: dev@dpdk.org, stephen@networkplumber.org, david.marchand@redhat.com, bruce.richardson@intel.com Message-ID: <20190519183204.GA3004@localhost.localdomain> References: <20190508181014.7dde7580@xps13> <20190514092046.30808-1-mattias.ronnblom@ericsson.com> <20190514092046.30808-2-mattias.ronnblom@ericsson.com> <20190514141615.GA12163@hmswarspite.think-freely.org> <8522b2d7-8361-3e34-7750-88b66d61b98a@ericsson.com> <20190517192725.GA4077@hmswarspite.think-freely.org> <295f536a-3793-3654-8711-dc1d57368ac9@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <295f536a-3793-3654-8711-dc1d57368ac9@ericsson.com> User-Agent: Mutt/1.11.3 (2019-02-01) X-Spam-Score: -2.9 (--) X-Spam-Status: No Subject: Re: [dpdk-dev] [PATCH 1/6] eal: replace libc-based random number generation with LFSR X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 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 > > > > > + > > > > > +#include > > > > > +#include > > > > > +#include > > > > > +#include > > > > > +#include > > > > > +#include > > > > > + > > > > > +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 >