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 26D8CA00C4; Thu, 23 Apr 2020 19:28:37 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 956F61C139; Thu, 23 Apr 2020 19:28:36 +0200 (CEST) Received: from mail-il1-f196.google.com (mail-il1-f196.google.com [209.85.166.196]) by dpdk.org (Postfix) with ESMTP id 08C9E1C0CD for ; Thu, 23 Apr 2020 19:28:35 +0200 (CEST) Received: by mail-il1-f196.google.com with SMTP id z12so6300084ilb.10 for ; Thu, 23 Apr 2020 10:28:34 -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:content-transfer-encoding; bh=pKYJVHtOexWKyh6LvQAOSiZNwIyiHFOhv41otGJFfh8=; b=YRBK/YJZRWu1BlDzeXgO4MtVcynjn71dyZq+fPaVDv9SP2rfiVj1q1I32kwiM4Dj4R cnGndmbp2DxRyEfEDVcQzMZWHFr+Msdshuk+LwLpMEGLf1fZnZOfZ15sIm7d3gobjz2Z ix2jq/9/oHOHFExPYXr5ei5g8Q855G0ujdfmS+qzP9t8NBmeU2lJ9aDdUYMKcAMOy7FC sdFGL0JYvuEOEGVia6DHnLVJ+Z9jVscv24JgaAPadrG9Eh1NgMGtYEn9AtKIIbob23ei tBklZoEUy+IlRhM5YzGoivnTllYv0VDK2iUH32cevyUhP9pLR9RThBc/SCykj2n/Lycc 8i4g== X-Gm-Message-State: AGi0PuZvPh+fcaSprJKNk3klp2XorLCi8sVdXclMsYBhm4zNDB/etFHo nWfOOsz4X+gwCStUHd8XirlLNtOYWDtN4RVwaro= X-Google-Smtp-Source: APiQypL5d2dPzcGQ/eculwlKg4VUikWU7RZst4YRGooTKp/xLA/79f7FNDluzg21u4xhVQoC49lJrkuWpuoizlfU6eQ= X-Received: by 2002:a92:3a48:: with SMTP id h69mr4326019ila.150.1587662914132; Thu, 23 Apr 2020 10:28:34 -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> <4afd42ec-3f0e-0ee3-d05f-0adf5a4a80a0@ericsson.com> In-Reply-To: <4afd42ec-3f0e-0ee3-d05f-0adf5a4a80a0@ericsson.com> From: Dan Gora Date: Thu, 23 Apr 2020 14:27:58 -0300 Message-ID: To: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= Cc: "dev@dpdk.org" , David Marchand , Jerin Jacob Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 9:36 AM Mattias R=C3=B6nnblom wrote: > >> > >> /dev/urandom is basically only a different interface to the same > >> underlying mechanism. > >> > >> Such an alternative would look something like: > >> > >> static int > >> getentropy(void *buffer, size_t length) > >> { > >> int rc =3D -1; > >> int old_errno =3D errno; > >> int fd; > >> > >> fd =3D open("/dev/urandom", O_RDONLY); > >> > >> if (fd < 0) > >> goto out; > >> > >> if (read(fd, buffer, length) !=3D length) > >> goto out_close; > >> > >> rc =3D 0; > >> > >> out_close: > >> close(fd); > >> out: > >> errno =3D old_errno; > >> > >> return rc; > >> } > > That's fine with me, but like I said I wasn't trying to change how any > > of this worked, just work around glibc dependencies. There seems to > > be some subtle difference between /dev/urandom and /dev/random, but... > > > > https://protect2.fireeye.com/v1/url?k=3D1705be57-4b8f6b41-1705fecc-862f= 14a9365e-bb983def357fdfad&q=3D1&e=3D10fec9c1-51b3-4bc3-b77d-7eb39787d007&u= =3Dhttps%3A%2F%2Fpatches-gcc.linaro.org%2Fcomment%2F14484%2F > > > >>>> Failure to run on old libc seems like a non-issue to me. > >>> Well, again, it's a new dependency that didn't exist before.. We sell > >>> to telco customers, so we have to support 10s of different target > >>> platforms of various ages. If they update their system, we'd have to > >>> recompile our code to be able to use getentropy(). Similarly, if we > >>> compiled on a system which has getentropy(), but the target system > >>> doesn't, then they cannot run our binary because of the glibc 2.25 > >>> dependency. That means that we have to have separate versions with > >>> and without getentropy(). It's a maintenance headache for no real > >>> benefit. > >> > >> I'm not sure I follow. Why would you need to recompile DPDK in case th= ey > >> upgrade their system? It sounds like you care about initial seeding, > >> since you want getentropy() if it exists, but then in the next paragra= ph > >> you want to throw it out, so I'm a little confused. > > Well _I_ wouldn't but maybe someone wants getentropy() for the > > initial seed.. I assume that's why it was added in the first place.. > > For my application we don't care at all. I just want to get rid of > > this dependency on glibc 2.25 and have the behavior be the same on > > meson and Makefile builds on the same complication system. > > > The reason for trying to avoid a wall time-based seed as the default is > that application instances started at the roughly the same time might > end up having a the same seed, which in turn might impact their behavior > in an adverse way. For example, random back-off timers may be the same. > On x86_64, TSC has a high resolution, but on other platforms its > equivalent the clock rate is much lower. > > > >> Why doesn't the standard practice of compiling against the oldest > >> supported libc work for you? > > I guess I didn't realize that was "standard practice" but even so it > > still adds an unnecessary restriction on the complication platform. > > > If DPDK has the policy of attempting to allow DPDK applications compiled > against one glibc version to run against another, older, version, we can > go ahead and discuss the details further. That would be up to the tech > board to decide. I would vote against it. I don't know why anyone would vote against removing an unnecessary dependency, which was only introduced in v19.08 anyways. > If the fix was simple, that's one thing. dlopen()/dlsym() doesn't > qualify as such, nor does a syscall wrapper, as you pointed out. The dlopen/dlsym() method is used in at least 4 other places in DPDK. It's not that complicated. There is plenty of precedence for it being done this way. I sent a v4 of the patch which emulated getentropy() using /dev/urandom as you suggested. Did you see that? thanks dan