From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 5F662456CE; Sat, 27 Jul 2024 17:54:27 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 1DCD74025F; Sat, 27 Jul 2024 17:54:27 +0200 (CEST) Received: from mail-oa1-f47.google.com (mail-oa1-f47.google.com [209.85.160.47]) by mails.dpdk.org (Postfix) with ESMTP id BDCFC4025E for ; Sat, 27 Jul 2024 17:54:25 +0200 (CEST) Received: by mail-oa1-f47.google.com with SMTP id 586e51a60fabf-264988283a3so1253972fac.0 for ; Sat, 27 Jul 2024 08:54:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1722095664; x=1722700464; darn=dpdk.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=fW9Ptk7wGo5caSj3RQErt4JEyyxs5tV1jMKWREUW6iw=; b=IXN0WA/0A5ntznIblPkM0EHh1+z8c4fGRINo2wXo7UWYcyfTBXZ6BmsSsFbbC9CuRE drD3Cb8TS8bemhl3rO+cIIlu69gWaBhTImZlj3wXIz+P9Q47fQOgNzMojVqUdxVyHFGf 8KgDVrCXPZGs7DdWhWLXGah4gnl0arDpuMR8AlFz3SAkQD7WpagPIuCTnPICqQSwZNme L/gGWjIPraI7SFqAxs/mIWbp42eCcr9nxO4KLdwCC3lCoQhbbrnR4TfYVvAWkvt9hrFA JoLtEypgeZOywm9k45ldJYjAWb5jISFhbZ+a4d8XBesCxLXYSFAA9ThCYZZLz+36sto6 dXSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722095664; x=1722700464; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=fW9Ptk7wGo5caSj3RQErt4JEyyxs5tV1jMKWREUW6iw=; b=RNLWwd++CKTH2cNN2auqN63gBy5Y4lKhbbEICfVTqRugUX+D79fIb8qnVnAb1wEaTH RjbBCpzwimpjtjZHFrCbxOMkMUf+nf952OClAppdiLKH51L1sx1B+qwRsvLj4r+BzKwV 1HGkrOOFvha2rHXu2IJzF4q4yQtvZ/Lbd4spZjNngFezN4xuhfv3ayov4YdBWkr3cHcj 0bdB+1gE4yIS2uf+3tLNeHBEI1ST0N45S7vZSHtz9sdQEAnRCk3yuwoMw1DMm8i1+6eF 22uxmgABimBrr8YD1y1+tcyn6hE4Jqb4Oa+SQcK08FdHf915lHkxvyk8kORznUJYyQL2 p5Zw== X-Forwarded-Encrypted: i=1; AJvYcCXjM6nQeMUS+WwDXuOwmaf4YYEHYuvlH3GW1/Zrmr/jEVo2VOJHGDhKkWPjnKI9p8w7Qu8kimee71Q7fmw= X-Gm-Message-State: AOJu0YxYoLodqUB02fGHDI/t4aGBI7H6lOr7nv768aeswWx/y+8LZnsa XJVp+D2DaIc6LCyP1Med83qU2UbRGhX3aSLs8osHrOolKWjPeEQBHO+T95B5oaI= X-Google-Smtp-Source: AGHT+IFWRuV0yeE2Vjrjf88tfXlrrQsj/YDrhmppCxPjwNDVAP/pNM9RYjs8fH38jrHrjVLccO0juA== X-Received: by 2002:a05:6870:414a:b0:261:72a:1336 with SMTP id 586e51a60fabf-267d4f58bbdmr3185263fac.50.1722095664550; Sat, 27 Jul 2024 08:54:24 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id 41be03b00d2f7-7aa9b184139sm3994927a12.75.2024.07.27.08.54.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 27 Jul 2024 08:54:24 -0700 (PDT) Date: Sat, 27 Jul 2024 08:54:22 -0700 From: Stephen Hemminger To: Wathsala Wathawana Vithanage Cc: Mattias =?UTF-8?B?UsO2bm5ibG9t?= , Shunzhi Wen , "thomas@monjalon.net" , Mattias =?UTF-8?B?UsO2bm5ibG9t?= , Ruifeng Wang , Bruce Richardson , Tyler Retzlaff , Min Zhou , David Christensen , Stanislaw Kardach , Konstantin Ananyev , "dev@dpdk.org" , nd , Jack Bond-Preston , Dhruv Tripathi , Honnappa Nagarahalli Subject: Re: [PATCH] eal: add support for TRNG with Arm RNG feature Message-ID: <20240727085422.737bb9ce@hermes.local> In-Reply-To: References: <20240723212703.721050-1-shunzhi.wen@arm.com> <536d1325-ee15-4630-9ae9-00cef9411d34@lysator.liu.se> <2d28f42f-480b-4070-8ba2-1353a742b46d@lysator.liu.se> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On Sat, 27 Jul 2024 15:45:55 +0000 Wathsala Wathawana Vithanage wrote: > Hi Mattias, >=20 > > > The primary goal of this patch is to provide a direct interface to HW, > > > instead of letting kernel handle it. This is not an API just for Arm > > > CPUs, as other vendors also have similar HW features. For instance, > > > Intel and AMD has support for x86 RDRAND and RDSEED instructions, thus > > > can easily implement this API. > > > =20 > >=20 > > No DPDK library (or PMD) currently needs this functionality, and no > > application, to my knowledge, has asked for this. If an app or a DPDK l= ibrary > > would require cryptographically secure random numbers, it would most li= kely > > require it on all CPU/OS platforms (and with all DPDK -march flags). > > =20 >=20 > I'm sorry, I'm not following this. Are you saying=C2=A0 >=20 > (a) adding a feature someone hasn't already asked for is impossible? >=20 > (b) it is impossible to add support for a feature that is only available = in a few CPUs > of an architecture family? >=20 > > RDRAND is only available on certain x86_64 CPUs, and is incredibly slow > > - slower than getting entropy via the kernel, even with non-vDSO syscal= ls. > >=20 > > Agner Fog lists the RDRAND latency as ~3700 cc for Zen 2. Later generat= ions of > > both AMD and Intel CPUs have much shorter latencies, but a reciprocal > > throughput so low that one have to wait thousands of clock cycles before > > issuing another RDRAND, or risk stalling the core. > >=20 > > My Raptor Lake seems to require ~1000 cc retire RDRAND, which is ~11x > > slower than getting entropy (in bulk) via getentropy(). > >=20 > > What is the latency for the ARM equivalent? Does it also have a recipro= cal > > throughput issue? > > =20 >=20 > Agree, from the numbers you are showing, it looks like they are all slow = and > unsuitable for the data plane. But aren't there multi-plane DPDK applicat= ions > with control-plane threads that can benefit from a CSRNG, albeit slow? The issue is that RDRAND and ARM RNG are both hardware features and the trust level is debatable. (See Wikipedia on RDRAND). The DPDK should stay out of this security fight because if DPDK offers direct access to HW RNG then naive vendors will start using it in applications. Then when it is revealed that some nation state has compromised HW RNG the blame will land on DPDK for enabling this. Lets not not get into the supply chain problem here. DPDK is an application environment, not a benchmark environment. The answer is to have API's like (rte_csrand) which then call the OS level primitives. The trust is then passed to the OS. I trust Linus, Theo de Raadt, and the rest of the open OS community to evaluate and integrate the best secure random number generator.