From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
by dpdk.space (Postfix) with ESMTP id 8BCB4A00E6
for <public@inbox.dpdk.org>; Fri, 17 May 2019 23:10:32 +0200 (CEST)
Received: from [92.243.14.124] (localhost [127.0.0.1])
by dpdk.org (Postfix) with ESMTP id 43CB25920;
Fri, 17 May 2019 23:10:31 +0200 (CEST)
Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3])
by dpdk.org (Postfix) with ESMTP id 1AA74375B
for <dev@dpdk.org>; Fri, 17 May 2019 23:10:30 +0200 (CEST)
Received: from mail.lysator.liu.se (localhost [127.0.0.1])
by mail.lysator.liu.se (Postfix) with ESMTP id 9536740017
for <dev@dpdk.org>; Fri, 17 May 2019 23:10:29 +0200 (CEST)
Received: by mail.lysator.liu.se (Postfix, from userid 1004)
id 7B60B4000E; Fri, 17 May 2019 23:10:29 +0200 (CEST)
X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on
bernadotte.lysator.liu.se
X-Spam-Level:
X-Spam-Status: No, score=-0.9 required=5.0 tests=ALL_TRUSTED,AWL
autolearn=disabled version=3.4.1
X-Spam-Score: -0.9
Received: from [192.168.1.59] (host-90-232-127-248.mobileonline.telia.com
[90.232.127.248])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(No client certificate requested)
by mail.lysator.liu.se (Postfix) with ESMTPSA id 028424000D;
Fri, 17 May 2019 23:10:26 +0200 (CEST)
To: Neil Horman <nhorman@tuxdriver.com>
Cc: dev@dpdk.org, stephen@networkplumber.org, david.marchand@redhat.com,
bruce.richardson@intel.com
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>
From: =?UTF-8?Q?Mattias_R=c3=b6nnblom?= <mattias.ronnblom@ericsson.com>
Message-ID: <295f536a-3793-3654-8711-dc1d57368ac9@ericsson.com>
Date: Fri, 17 May 2019 23:10:25 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <20190517192725.GA4077@hmswarspite.think-freely.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
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.
Does a srand48() call in one process reseed lrand48() PRNGs in all other
processes in the system? No.
> Breaking in to get this information is
> as simple as writing a program that links against the dpdk shared library, or
> just dlopens it and looks up the requisite symbol address.
Two programs using the same shared object do share memory, but the
portions shared are either read-only or copy-on-write (which means
modified pages will be private to the process).
It's even the case that with address space layout randomization (ASLR),
the address of the same symbol varies across different processes.
> And while thats true
> of any symbol, given the prior example which uses rte_rand for a cryptographic
> purpose, it seems like this would be a particularly tempting target to exploit.
> > Either way, asserting that its fine to do this because any method
that gives you
> access to it gives you access to other information is really not a great
> argument. We should protect application data wherever we can, and the integrity
> of the randomness of data seems like a case in point.
UNIX virtual memory and MMU memory protection is already protecting this
data, and has been doing so for the last 30-40 years or so.