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 7CDBBA00C4; Thu, 23 Apr 2020 19:39:13 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 644CF1C22D; Thu, 23 Apr 2020 19:39:12 +0200 (CEST) Received: from mail-io1-f68.google.com (mail-io1-f68.google.com [209.85.166.68]) by dpdk.org (Postfix) with ESMTP id BAA3B1C1F7 for ; Thu, 23 Apr 2020 19:39:10 +0200 (CEST) Received: by mail-io1-f68.google.com with SMTP id k6so7317269iob.3 for ; Thu, 23 Apr 2020 10:39:10 -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=BhyxzUk1EwajxvsJKyNHERNeWMreXQAyjkvZU+L01kY=; b=GBzW+X7v6aGEoGkj/n4gHglI9gBXB5zHVAoY3jaJmuhYtWN8UxoFf6QnyijVULAXB1 QfGHhY1tc+9RsE+iGlOTeNMh2otzUC0zPwBa9A8x9SrpsvDRhFoxjAmCvCSv2gGn8pQI 42so8p6bX3Jt35HB6Ob+s0NRTND0gGABiff8MKN0478JwtpGAnx4Hrk2pI9l9a9ua1MP 3NplAUsc1Sd3rHuU2StD4I+EsKUNWy51nUoMSPx/vVxqm5S7y0uCsytgvcpYKHRY9nwH FiSz03PjEdW3xagJZuFdqxUXV2bUblelfoXAww1IOHeoR9tK9T1SzH3TDsDsgkoc4s0o bAPA== X-Gm-Message-State: AGi0PuaIrq6BLS4komRR83p/v+ISkLgEjc//4pOKUSFr1Ns1vcMb1RNx a3y7/p2mxHXYsA0KWT5Y9QDygIs925rAbP9Yybw= X-Google-Smtp-Source: APiQypIsfMEmk9mlc9PnzuduHNC8IKrEIlLuWQjbpftv0ezWNOs20jDTMQscxUzMw6QfL7gEbmfV2jCnt+mUpYyAnfo= X-Received: by 2002:a6b:e802:: with SMTP id f2mr4805602ioh.128.1587663549990; Thu, 23 Apr 2020 10:39:09 -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> In-Reply-To: From: Dan Gora Date: Thu, 23 Apr 2020 14:38:33 -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 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. 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