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 6FE24A00BE; Mon, 27 Apr 2020 14:44:14 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id ACF931D171; Mon, 27 Apr 2020 14:44:13 +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 9CC681D161 for ; Mon, 27 Apr 2020 14:44:11 +0200 (CEST) Received: by mail-wr1-f66.google.com with SMTP id g13so20358157wrb.8 for ; Mon, 27 Apr 2020 05:44:11 -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=Ay3dQYQ1pQQYBYuWUR5ggE8pVcrIfYB85xhQKTNXHiM=; b=U5bVy4uqyxFRDtDaTLJcim0n02HO2TxNwU0M6V6f8FAt/osgQwAr9p+hYB/Pb4fW8u dz/j8n+hQNfEhWSB+eUAY9Pdrpp8TXBXcWe5CQBEWgVYmEZPObhJHz+aWb9vCR8XjPrS S4HXuO/iweoWycsE3mGR4ZE/NlFnOfob7KUjMA1mEagmig1A1quYLbI6ZzmmIbXG+sEL 2hc0oVqdgm7Pjw/bEqF4XR2+Jv7s5BZvOxrpZuja9puVcVzESoBecUyqG767cWn4NHVd 0NVVcRMG+FxOaOgKTk2Q3ef+c0LIqZ+S9GwU3yHwFyyN6FTjv4cB0ScKm/OkhBBOwpjk UfJg== X-Gm-Message-State: AGi0PuaBPiKMARo41Auxh0Tstk7qQ5EEwPDjrKo7PoA2QQ4CfogSxSJy GEAp2qzUcmIUY+UjJDeXLdQ= X-Google-Smtp-Source: APiQypLxWI6sfQA6LBMhkzVxKGhovdDtmIUHCxo1CmXdHGhbWgm6A4iYxkgI5AGINLaxewe6yfLLeg== X-Received: by 2002:adf:e88d:: with SMTP id d13mr26410918wrm.375.1587991451279; Mon, 27 Apr 2020 05:44:11 -0700 (PDT) Received: from localhost ([88.98.246.218]) by smtp.gmail.com with ESMTPSA id m188sm15281981wme.47.2020.04.27.05.44.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Apr 2020 05:44:10 -0700 (PDT) Message-ID: <9782db5b1e5d2dfdcfa8e52410fd166df5db938d.camel@debian.org> From: Luca Boccassi To: Dan Gora Cc: Mattias =?ISO-8859-1?Q?R=F6nnblom?= , "dev@dpdk.org" , David Marchand , Jerin Jacob Date: Mon, 27 Apr 2020 13:44:09 +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 Thu, 2020-04-23 at 14:38 -0300, Dan Gora wrote: > On Thu, Apr 23, 2020 at 12:59 PM Luca Boccassi wrote: > > > > /dev/urandom is basically only a different interface to the same > > > > underlying mechanism. > >=20 > > 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. >=20 > DPDK opens _tons_ of files. This would not be the first file that DPDK > has to open. And it's not like /dev/urandom is a new interface. It's > been around forever. That might be the case, but it is not reason in itself to make things harder. Especially in light of the new stability promise - this might or might not be considered part of it, but it's worth mentioning at the very least, as it has a real impact on users. > If this is such a major problem, then that would argue for using the > dlsym()/dlopen() method to try to find the getentropy glibc function > that I sent in v3 of these patches. >=20 > > 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. >=20 > The original problem was that the "programmatic interface to the > random pools" (that is, getentropy()) can only be determined at > compilation time and if found introduce a new dependency on glibc 2.25 > that can easily be avoided by emulating it (as I did here in v4 of the > patches) or by trying to dynamically find the symbol at run time using > dlopen()/dlsym() (as I did in v3 of the patches). >=20 > > 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 > Well that's not necessarily true. Most glibc interfaces have been > around forever and you can easily see what versions of glibc are > needed by running ldd on your application. I don't see the point in > introducing a new dependency on a very recent version of glibc which > is not supported by all supported DPDK platforms when it can easily be > worked around. >=20 > The issue here is that the original patch to add getentropy(): > 1) Added a _new_ dependency on glibc 2.25. > 2) Added a _new_ dependency that the rdseed CPU flag on the execution > machine has to match the complication machine. > 3) Has different behavior if the DPDK is compiled with meson or with > Make on the same complication platform. >=20 > thanks, > dan Adding a new dependecy happens only when building with the new version of the library. If it's not available, then there's no new dependency.=20 It sounds to me like you are trying to add workarounds for issues in your downstream build/deployment model, where your build dependencies are newer than your runtime dependencies. This in general is rarely well supported. Now I'm fine with adding workarounds as _fallbacks_ - what I am explicitly NACKing is forcibly restricting to the least common denominator because of issues in a third party build/deployment system that doesn't follow the common norm. This is especially true when dealing with RNG APIs, where the tiniest and most innocent-looking mistake could have disastrous consequences. --=20 Kind regards, Luca Boccassi