From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 5F3BEA00C2; Thu, 23 Apr 2020 12:04:19 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B9A5C1D447; Thu, 23 Apr 2020 12:04:18 +0200 (CEST) Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com [209.85.221.66]) by dpdk.org (Postfix) with ESMTP id CFFF21D446 for ; Thu, 23 Apr 2020 12:04:17 +0200 (CEST) Received: by mail-wr1-f66.google.com with SMTP id s10so6146017wrr.0 for ; Thu, 23 Apr 2020 03:04:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:content-transfer-encoding:user-agent:mime-version; bh=cgzN8Swff7DRoguOCQN8KbapawF79A6EEbhcwf4tR6Q=; b=iDtNFImlQktoO7xCGCXxiYVM5OHlvsuGkiPlA8O3g2d1S4QgfhG4aZySUhH6ypNgjQ UStRI+6m4j/m49ccBvgykE/qK9oLwyia0qHZCeT2RVBzRa4lHJuoCUtiVKEfM2brLjKI boOa8fsMZLwgkKRiSMT9NRw3snT1AGafsH/gwaTUo8N/F2T4ZBJZ4iZlTZ/qiHzGAGtF RqJre+vOLIfV8ZJ8iF7iV79GjpLN8eGTHMHTxyu6Mq+btxZacP1SuZhfnXt1M3t6jZ42 lxbpZJvxSOcan2n8fvgOCdb64Y4KxG2rDZSNomipke98f9rPNzcyWU219apqTuOBDBsS IvsQ== X-Gm-Message-State: AGi0PuYtKC6IQyhFn6+OEkigJ3gqT1GLwTqjc3Y/4tkvAD4i7D0v2puX EbDzFOpIw90N5Wf5g+hQGyA= X-Google-Smtp-Source: APiQypIwEFtstTS0dinDeplNan6NUxYq0wVbwot0cFD6GIWhKjfUmo7+M4r6RZUY7bBcLyALvY9I8Q== X-Received: by 2002:adf:92c2:: with SMTP id 60mr3857020wrn.379.1587636257487; Thu, 23 Apr 2020 03:04:17 -0700 (PDT) Received: from localhost ([88.98.246.218]) by smtp.gmail.com with ESMTPSA id 60sm3217023wrr.7.2020.04.23.03.04.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Apr 2020 03:04:16 -0700 (PDT) Message-ID: From: Luca Boccassi To: Dan Gora , Mattias =?ISO-8859-1?Q?R=F6nnblom?= Cc: "dev@dpdk.org" , David Marchand , Jerin Jacob Date: Thu, 23 Apr 2020 11:04:16 +0100 In-Reply-To: References: <20200421195446.1730-1-dg@adax.com> <20200421195446.1730-3-dg@adax.com> <5df15087-781e-d27f-b7d8-50b1b8cb0c94@ericsson.com> <80e5cf97-feae-c753-5c65-4f3b121729f3@ericsson.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.30.5-1.1 MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH 2/2] eal: resolve getentropy at run time for random seed 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 Wed, 2020-04-22 at 17:35 -0300, Dan Gora wrote: > On Wed, Apr 22, 2020 at 5:14 PM Mattias R=C3=B6nnblom > wrote: > > On 2020-04-22 19:44, Dan Gora wrote: > > > On Wed, Apr 22, 2020 at 5:28 AM Mattias R=C3=B6nnblom > > > wrote: > > > > On 2020-04-21 21:54, Dan Gora wrote: > > > > > The getentropy() function was introduced into glibc v2.25 and so = is > > > > > not available on all supported platforms. Previously, if DPDK wa= s > > > > > compiled (using meson) on a system which has getentropy(), it wou= ld > > > > > introduce a dependency on glibc v2.25 which would prevent that bi= nary > > > > > from running on a system with an older glibc. Similarly if DPDK = was > > > > > compiled on a system which did not have getentropy(), getentropy(= ) > > > > > could not be used even if the execution system supported it. > > > > >=20 > > > > > Introduce a new static function, __rte_getentropy() which will tr= y to > > > > > resolve the getentropy() function dynamically using dlopen()/dlsy= m(), > > > > > returning failure if the getentropy() function cannot be resolved= or > > > > > if it fails. > > > >=20 > > > > Two other options: providing a DPDK-native syscall wrapper for > > > > getrandom(), or falling back to reading /dev/urandom. Have you > > > > considered any of those two options? If so, why do you prefer > > > > dlopen()/dlsym()? > > > I didn't give any thought at all to using /dev/urandom. The goal was > > > not really to change how the thing worked, just to remove the > > > dependency on glibc 2.25. > >=20 > > /dev/urandom is basically only a different interface to the same > > underlying mechanism. This is not the whole story though - while the end result when all works is the same, there are important differences in getting there. There's a reason a programmatic interface was added - it's just better in general. Just to name one - opening files has implications for LSMs like SELinux. You now need a specific policy to allow it, which means applications that upgrade from one version of DPDK to the next will break. In general, I do not think we should go backwards. The programmatic interface to the random pools are good and we should use them by default - of course by all means add fallbacks to urandom if they are not available. But as Stephen said glibc generally does not support compiling on new + running on old - so if it's not this that breaks, it will be something else. --=20 Kind regards, Luca Boccassi