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 94158A00BE; Mon, 27 Apr 2020 18:58:07 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D3E461BEA6; Mon, 27 Apr 2020 18:58:03 +0200 (CEST) Received: from mail-il1-f195.google.com (mail-il1-f195.google.com [209.85.166.195]) by dpdk.org (Postfix) with ESMTP id 1E8B51D516 for ; Mon, 27 Apr 2020 18:58:00 +0200 (CEST) Received: by mail-il1-f195.google.com with SMTP id q10so17379545ile.0 for ; Mon, 27 Apr 2020 09:58:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DPV0wvsJme+2KRV/OotayHwlBmtdcaKN1vw+mCkw+nU=; b=rbysWkt+54RxK6UlSLBJMFOt53bIPFfIrZqXWjNnwYkSWytKtt1r0+9XEMGk89ga8D vNaCDJVoLiJD7Y+gb0yliwsCh03NUk0uW48tyn6HzmcyDv0z6yQdh1Q49bgi7fph12ax WNNwhtUbU5LbwFBmVpdUntB1qsuqzypRfGiEqJwWh1+jwZDGPuYRArNZxc/0++UZ9Awk h2S6tkXyD48wZwKK5NtGyw8ZAHvXG1EWOVNCgUlzwcQ7OGXMRpCezkS71eyfoZtGbTCs n07rAAweXWufHA/8sBR+6X2rc80UYLp8fnOx60yrsWgvjmhcQxzGRxAQ1pl8STTR0+nF UyXg== X-Gm-Message-State: AGi0PuYiNwUBTjVeBgq+MrzvHPypaDJt2nBDyF72OOQA0dtOAAC4t1sK BRGAoqMm4ckajq6+fhVv1WhKnaDQ5mzE2j5rINw= X-Google-Smtp-Source: APiQypIt0bISToaqrXnXXh7wFUZGT6Tae6RP5xGfn5bBkzTnyMdOPHmQyUa7jKEAC8T9r6gggOVPgDOB/sdalPn1pW4= X-Received: by 2002:a92:dd09:: with SMTP id n9mr22745283ilm.132.1588006679310; Mon, 27 Apr 2020 09:57:59 -0700 (PDT) MIME-Version: 1.0 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> <9782db5b1e5d2dfdcfa8e52410fd166df5db938d.camel@debian.org> In-Reply-To: <9782db5b1e5d2dfdcfa8e52410fd166df5db938d.camel@debian.org> From: Dan Gora Date: Mon, 27 Apr 2020 13:57:23 -0300 Message-ID: To: Luca Boccassi Cc: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= , "dev@dpdk.org" , David Marchand , Jerin Jacob Content-Type: text/plain; charset="UTF-8" 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 Mon, Apr 27, 2020 at 1:19 PM Luca Boccassi wrote: > > 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. > > > > > > 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. > > > > 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. "make things harder" seems especially subjective.. I would argue that I am in fact making things much easier by removing unnecessary dependecies > > > 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. > > > > > 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. > > > > 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). > > > > > 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. > > > > 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. > > > > 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. > > > > 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. But you also do not get to use the new getentropy() if you happen to compile on a system which does not have the latest glibc, or if you use the makefile system.. > 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. I am fully aware of that. I am not adding "workarounds", I am eliminating unnecessary dependencies which probably never should have been introduced in the first place. > 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. ugh.. this is the exact _opposite_ of what this patch does. It is not restricting anything to a least common denominator. It is allowing the DPDK to use the "best" available function, regardless of the build system. Restricting to the least common denominator is what the original patch did... > This is especially true when dealing with RNG APIs, where the tiniest > and most innocent-looking mistake could have disastrous consequences. This does not change the functionality of the RNG at all. It just makes it work in the way that it was intended. These changes were only introduced into 19.08, so they are not historical artifacts or anything. thanks dan