From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by dpdk.org (Postfix) with ESMTP id E14834D27 for ; Tue, 14 May 2019 16:53:14 +0200 (CEST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 877804000E for ; Tue, 14 May 2019 16:53:14 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 7231140003; Tue, 14 May 2019 16:53:14 +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 9164840002; Tue, 14 May 2019 16:53:09 +0200 (CEST) To: Neil Horman 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> From: =?UTF-8?Q?Mattias_R=c3=b6nnblom?= Message-ID: <8522b2d7-8361-3e34-7750-88b66d61b98a@ericsson.com> Date: Tue, 14 May 2019 16:53:08 +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: <20190514141615.GA12163@hmswarspite.think-freely.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2019 14:53:15 -0000 On 2019-05-14 16:16, Neil Horman wrote: > On Tue, May 14, 2019 at 11:20:41AM +0200, Mattias Rönnblom wrote: >> This commit replaces rte_rand()'s use of lrand48() with a DPDK-native >> combined Linear Feedback Shift Register (LFSR) (also known as >> Tausworthe) pseudo-random number generator. >> >> This generator is faster and produces better-quality random numbers >> than the linear congruential generator (LCG) of lib's lrand48(). The >> implementation, as opposed to lrand48(), is multi-thread safe in >> regards to concurrent rte_rand() calls from different lcore threads. >> A LCG is still used, but only to seed the five per-lcore LFSR >> sequences. >> >> In addition, this patch also addresses the issue of the legacy >> implementation only producing 62 bits of pseudo randomness, while the >> API requires all 64 bits to be random. >> >> This pseudo-random number generator is not cryptographically secure - >> just like lrand48(). >> >> Bugzilla ID: 114 >> Bugzilla ID: 276 >> >> Signed-off-by: Mattias Rönnblom >> --- >> lib/librte_eal/common/include/rte_random.h | 29 ++--- >> lib/librte_eal/common/meson.build | 1 + >> lib/librte_eal/common/rte_random.c | 139 +++++++++++++++++++++ >> lib/librte_eal/freebsd/eal/Makefile | 1 + >> lib/librte_eal/freebsd/eal/eal.c | 2 - >> lib/librte_eal/linux/eal/Makefile | 1 + >> lib/librte_eal/linux/eal/eal.c | 2 - >> lib/librte_eal/rte_eal_version.map | 8 ++ >> 8 files changed, 161 insertions(+), 22 deletions(-) >> create mode 100644 lib/librte_eal/common/rte_random.c >> >> diff --git a/lib/librte_eal/common/include/rte_random.h b/lib/librte_eal/common/include/rte_random.h >> index b2ca1c209..66dfe8ae7 100644 >> --- a/lib/librte_eal/common/include/rte_random.h >> +++ b/lib/librte_eal/common/include/rte_random.h >> @@ -16,7 +16,6 @@ extern "C" { >> #endif >> >> #include >> -#include >> >> /** >> * Seed the pseudo-random generator. >> @@ -25,34 +24,28 @@ extern "C" { >> * value. It may need to be re-seeded by the user with a real random >> * value. >> * >> + * This function is not multi-thread safe in regards to other >> + * rte_srand() calls, nor is it in relation to concurrent rte_rand() >> + * calls. >> + * >> * @param seedval >> * The value of the seed. >> */ >> -static inline void >> -rte_srand(uint64_t seedval) >> -{ >> - srand48((long)seedval); >> -} >> +void >> +rte_srand(uint64_t seedval); >> >> /** >> * Get a pseudo-random value. >> * >> - * This function generates pseudo-random numbers using the linear >> - * congruential algorithm and 48-bit integer arithmetic, called twice >> - * to generate a 64-bit value. >> + * The generator is not cryptographically secure. >> + * >> + * If called from lcore threads, this function is thread-safe. >> * >> * @return >> * A pseudo-random value between 0 and (1<<64)-1. >> */ >> -static inline uint64_t >> -rte_rand(void) >> -{ >> - uint64_t val; >> - val = (uint64_t)lrand48(); >> - val <<= 32; >> - val += (uint64_t)lrand48(); >> - return val; >> -} >> +uint64_t >> +rte_rand(void); >> >> #ifdef __cplusplus >> } >> diff --git a/lib/librte_eal/common/meson.build b/lib/librte_eal/common/meson.build >> index 0670e4102..bafd23207 100644 >> --- a/lib/librte_eal/common/meson.build >> +++ b/lib/librte_eal/common/meson.build >> @@ -35,6 +35,7 @@ common_sources = files( >> 'rte_keepalive.c', >> 'rte_malloc.c', >> 'rte_option.c', >> + 'rte_random.c', >> 'rte_reciprocal.c', >> 'rte_service.c' >> ) >> 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. 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? 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 1EC5AA00E6 for ; Tue, 14 May 2019 16:53:17 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id ED6145F17; Tue, 14 May 2019 16:53:15 +0200 (CEST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by dpdk.org (Postfix) with ESMTP id E14834D27 for ; Tue, 14 May 2019 16:53:14 +0200 (CEST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 877804000E for ; Tue, 14 May 2019 16:53:14 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 7231140003; Tue, 14 May 2019 16:53:14 +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 9164840002; Tue, 14 May 2019 16:53:09 +0200 (CEST) To: Neil Horman 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> From: =?UTF-8?Q?Mattias_R=c3=b6nnblom?= Message-ID: <8522b2d7-8361-3e34-7750-88b66d61b98a@ericsson.com> Date: Tue, 14 May 2019 16:53:08 +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: <20190514141615.GA12163@hmswarspite.think-freely.org> Content-Type: text/plain; charset="UTF-8"; format="flowed" Content-Language: en-US Content-Transfer-Encoding: 8bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Message-ID: <20190514145308.DQ93Lq_tVaMlei_E_WN1JDmGFGjIwHRuCzn0jg04T3M@z> On 2019-05-14 16:16, Neil Horman wrote: > On Tue, May 14, 2019 at 11:20:41AM +0200, Mattias Rönnblom wrote: >> This commit replaces rte_rand()'s use of lrand48() with a DPDK-native >> combined Linear Feedback Shift Register (LFSR) (also known as >> Tausworthe) pseudo-random number generator. >> >> This generator is faster and produces better-quality random numbers >> than the linear congruential generator (LCG) of lib's lrand48(). The >> implementation, as opposed to lrand48(), is multi-thread safe in >> regards to concurrent rte_rand() calls from different lcore threads. >> A LCG is still used, but only to seed the five per-lcore LFSR >> sequences. >> >> In addition, this patch also addresses the issue of the legacy >> implementation only producing 62 bits of pseudo randomness, while the >> API requires all 64 bits to be random. >> >> This pseudo-random number generator is not cryptographically secure - >> just like lrand48(). >> >> Bugzilla ID: 114 >> Bugzilla ID: 276 >> >> Signed-off-by: Mattias Rönnblom >> --- >> lib/librte_eal/common/include/rte_random.h | 29 ++--- >> lib/librte_eal/common/meson.build | 1 + >> lib/librte_eal/common/rte_random.c | 139 +++++++++++++++++++++ >> lib/librte_eal/freebsd/eal/Makefile | 1 + >> lib/librte_eal/freebsd/eal/eal.c | 2 - >> lib/librte_eal/linux/eal/Makefile | 1 + >> lib/librte_eal/linux/eal/eal.c | 2 - >> lib/librte_eal/rte_eal_version.map | 8 ++ >> 8 files changed, 161 insertions(+), 22 deletions(-) >> create mode 100644 lib/librte_eal/common/rte_random.c >> >> diff --git a/lib/librte_eal/common/include/rte_random.h b/lib/librte_eal/common/include/rte_random.h >> index b2ca1c209..66dfe8ae7 100644 >> --- a/lib/librte_eal/common/include/rte_random.h >> +++ b/lib/librte_eal/common/include/rte_random.h >> @@ -16,7 +16,6 @@ extern "C" { >> #endif >> >> #include >> -#include >> >> /** >> * Seed the pseudo-random generator. >> @@ -25,34 +24,28 @@ extern "C" { >> * value. It may need to be re-seeded by the user with a real random >> * value. >> * >> + * This function is not multi-thread safe in regards to other >> + * rte_srand() calls, nor is it in relation to concurrent rte_rand() >> + * calls. >> + * >> * @param seedval >> * The value of the seed. >> */ >> -static inline void >> -rte_srand(uint64_t seedval) >> -{ >> - srand48((long)seedval); >> -} >> +void >> +rte_srand(uint64_t seedval); >> >> /** >> * Get a pseudo-random value. >> * >> - * This function generates pseudo-random numbers using the linear >> - * congruential algorithm and 48-bit integer arithmetic, called twice >> - * to generate a 64-bit value. >> + * The generator is not cryptographically secure. >> + * >> + * If called from lcore threads, this function is thread-safe. >> * >> * @return >> * A pseudo-random value between 0 and (1<<64)-1. >> */ >> -static inline uint64_t >> -rte_rand(void) >> -{ >> - uint64_t val; >> - val = (uint64_t)lrand48(); >> - val <<= 32; >> - val += (uint64_t)lrand48(); >> - return val; >> -} >> +uint64_t >> +rte_rand(void); >> >> #ifdef __cplusplus >> } >> diff --git a/lib/librte_eal/common/meson.build b/lib/librte_eal/common/meson.build >> index 0670e4102..bafd23207 100644 >> --- a/lib/librte_eal/common/meson.build >> +++ b/lib/librte_eal/common/meson.build >> @@ -35,6 +35,7 @@ common_sources = files( >> 'rte_keepalive.c', >> 'rte_malloc.c', >> 'rte_option.c', >> + 'rte_random.c', >> 'rte_reciprocal.c', >> 'rte_service.c' >> ) >> 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. 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?