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 194A8456A2; Wed, 24 Jul 2024 21:14:39 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id BC6A84325C; Wed, 24 Jul 2024 21:14:38 +0200 (CEST) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) by mails.dpdk.org (Postfix) with ESMTP id 8415540E19 for ; Wed, 24 Jul 2024 21:14:36 +0200 (CEST) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 812D412FB8 for ; Wed, 24 Jul 2024 21:14:35 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 74C191300F; Wed, 24 Jul 2024 21:14:35 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on hermod.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=ALL_TRUSTED,AWL, T_SCC_BODY_TEXT_LINE autolearn=disabled version=4.0.0 X-Spam-Score: -1.3 Received: from [192.168.1.86] (h-62-63-215-114.A163.priv.bahnhof.se [62.63.215.114]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id D7D7912EE6; Wed, 24 Jul 2024 21:14:30 +0200 (CEST) Message-ID: <02097e5b-1c04-4e02-a3d7-e8d0df1e3308@lysator.liu.se> Date: Wed, 24 Jul 2024 21:14:30 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] eal: add support for TRNG with Arm RNG feature To: Stephen Hemminger Cc: Shunzhi Wen , Thomas Monjalon , =?UTF-8?Q?Mattias_R=C3=B6nnblom?= , Ruifeng Wang , Bruce Richardson , Tyler Retzlaff , Min Zhou , David Christensen , Stanislaw Kardach , Konstantin Ananyev , dev@dpdk.org, nd@arm.com, Wathsala Vithanage , Jack Bond-Preston , Dhruv Tripathi References: <20240723212703.721050-1-shunzhi.wen@arm.com> <536d1325-ee15-4630-9ae9-00cef9411d34@lysator.liu.se> <20240724073501.70d86435@hermes.local> <18c67157-8753-4a95-9ab5-f4f1d4a32010@lysator.liu.se> <20240724091620.11ce8c38@hermes.local> Content-Language: en-US From: =?UTF-8?Q?Mattias_R=C3=B6nnblom?= In-Reply-To: <20240724091620.11ce8c38@hermes.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP 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 2024-07-24 18:16, Stephen Hemminger wrote: >>>> > +/** >>>> > + * Get a true random value. >>>> > + * >>>> > + * The generator is cryptographically secure. >>>> >>>> If you want to extend with a cryptographically secure >>>> random number generator, that's fine. >>>> >>>> To have an API that's only available on certain ARM CPUs is not. >>>> >>>> NAK >>>> >>>> A new function should be called something with "secure", rather than >>>> "true" (which is a bit silly, since we might well live in a completely >>>> deterministic universe). "secure" would more clearly communicate the >>>> intent, and also doesn't imply any particular implementation. >>> >>> Agree, with Mattias. What constitutes a secure random number generator >>> is a matter of much debate. Most of the HW random generators are taking >>> diode (Schottky noise) and doing transforms on it to get something uniform. >>> >>> If a key generation type API was added, why not just use existing and more >>> researched kernel get_random()? >>> >> >> Ideally, you want to avoid system calls on lcore workers doing packet >> processing. If you have to do system calls (which I believe is the case >> here), it's better to a simple call, not so often. >> >> getentropy() seems to need about 800 core clock cycles on my x86_64, on >> average. (rte_rand() needs ~11 cc/call.) 800 cc is not too horrible, but >> system calls tend to have some pretty bad tail latencies. >> >> To improve efficiency, one could do a getentropy() on a relatively large >> buffer, and cache the result on a per-lcore basis, amortizing the system >> call overhead over many calls. >> >> You still have the tail latency issue to deal with. We could have a >> control thread providing entropy for the lcores, but that seems like >> massive overkill. > > > Getrandom is a vsyscall on current kernels, and it manages use of entropy across > multiple sources. If you are doing lots of key generation, you don't want to > hit the hardware every time. > > https://lwn.net/Articles/974468/ > > If I understand things correctly, the getrandom() vDSO support was mainlined *today*, so you need to be current indeed to have a vDSO getrandom(). :) The above benchmark (rand_perf_autotest with rte_rand() implemented with getentropy()) was run on Linux 5.15 and glibc 2.35, so a regular system call was used. (getentropy() delegates to getrandom(), so the performance is the same.)