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 CE796456BE; Fri, 26 Jul 2024 21:00:31 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 83A714279A; Fri, 26 Jul 2024 21:00:30 +0200 (CEST) Received: from mail-il1-f177.google.com (mail-il1-f177.google.com [209.85.166.177]) by mails.dpdk.org (Postfix) with ESMTP id C74BF40E6E for ; Fri, 26 Jul 2024 21:00:29 +0200 (CEST) Received: by mail-il1-f177.google.com with SMTP id e9e14a558f8ab-39865a15900so7734915ab.1 for ; Fri, 26 Jul 2024 12:00:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20230601.gappssmtp.com; s=20230601; t=1722020429; x=1722625229; 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=X7TsH+jcoekKvmRusSuzP5xUGq8VDbP699pU6+kYT/k=; b=VLhqnJhiGbGB3FgjZNJH+CCLQtl+926o0xLWEeRHolbY2GWw46xAmDDiYEJ2wqAEb7 yJCorht9QuRZwUWyhzPYMde4ImnatBfJAGpXywgxhBhzmK1RD1If+IRAl5UL2XyJVCOF LUUdeHihA3OlzKEMx0nNdFc5rxqxYC9VNtvoP1BJyn2sOp9mocNSb6jxycuOtWatFQ/s 1c/4Ua5QwWHuFHt1++9bEXYZ+btmVputwzOwlRv//NwN/eP9ZD9rELHjDVwceAFUzbOe Qxdc234TuAKv8mCG+QxTu2ASlH9dMTd11+LGWtJvqSSuOLS6dRavjMK3ezsD5/D/qYz4 47oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1722020429; x=1722625229; 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=X7TsH+jcoekKvmRusSuzP5xUGq8VDbP699pU6+kYT/k=; b=IVegp9pbd6d60Ddrr+etSCLH7tbovd6nu9ciCHBnx+2h/gT8UcfIFXBKksjGC7SP4S n0+8EDj2t2ioEH8cZtYSQf+YwcRqggw4LAfjS+HPuG5QVvmzw9yUikwGmbXnexhXj7AA jduTNp+ah7sVc0W3nf+F8ilshO7klpoTOHKH+F3f3SvCEF0kjjq/3hi0raGGPs6V0y5l Sxwynusf/+AvDGvoRiMwz9HdmB+bPl4HHmraM4NfscQ8qlT0lxDPCOfJHS6wG21OW3MW r9cfLedkJFJkDrL0uc7ysRIWrtNIMbBROF5gViK/70wmEkxp07pcmmajvbATFT5JWKr4 +OJg== X-Forwarded-Encrypted: i=1; AJvYcCVMIMJAAxdyg+k0tLrqxLaPEfRdMEap5zDjh6fVKHYpJiqqLJBbJ6u9P129qoj/3/37uh+niEYYHFnoMDs= X-Gm-Message-State: AOJu0YwlXruAiHzzj3Zk1Cz+a+ypwzlfhhQrK3HYi48/pnCw6E5hQFIP mq3VDmIuykLNDknXD874yyEHiqMFv/7nBc0uzjLJrelQ6p7DeYBxLZOemMQ6uzM= X-Google-Smtp-Source: AGHT+IFpsNIl+xUXQf+6dKS00tzmsk7VIwPs1kO365zoFm7iRfCN1btR5Pyq29LeBMyRz/OMQdowsw== X-Received: by 2002:a05:6e02:2183:b0:371:6b02:9da0 with SMTP id e9e14a558f8ab-39aec2aef30mr4553175ab.19.1722020429005; Fri, 26 Jul 2024 12:00:29 -0700 (PDT) Received: from hermes.local (204-195-96-226.wavecable.com. [204.195.96.226]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-70ead6e16fbsm3143383b3a.19.2024.07.26.12.00.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Jul 2024 12:00:28 -0700 (PDT) Date: Fri, 26 Jul 2024 12:00:26 -0700 From: Stephen Hemminger To: Shunzhi Wen Cc: Mattias =?UTF-8?B?UsO2bm5ibG9t?= , "thomas@monjalon.net" , Mattias =?UTF-8?B?UsO2bm5i?= =?UTF-8?B?bG9t?= , Ruifeng Wang , Bruce Richardson , Tyler Retzlaff , Min Zhou , David Christensen , Stanislaw Kardach , Konstantin Ananyev , "dev@dpdk.org" , nd , Wathsala Wathawana Vithanage , Jack Bond-Preston , Dhruv Tripathi Subject: Re: [PATCH] eal: add support for TRNG with Arm RNG feature Message-ID: <20240726120026.3be4d0d0@hermes.local> In-Reply-To: References: <20240723212703.721050-1-shunzhi.wen@arm.com> <536d1325-ee15-4630-9ae9-00cef9411d34@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 Fri, 26 Jul 2024 18:34:44 +0000 Shunzhi Wen wrote: > > I'm missing a rationale here. Why is this useful? > > =20 > This creates an API for HW that supports cryptographically secure random = number generation. >=20 > > 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 > > =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 > > A new function should be called something with "secure", rather than "t= rue" > > (which is a bit silly, since we might well live in a completely determi= nistic > > universe). "secure" would more clearly communicate the intent, and also > > doesn't imply any particular implementation. > > =20 > Regarding the terminology, =E2=80=9Ccryptographically secure random numbe= r=E2=80=9D > is a more accurate and meaningful term than =E2=80=9Ctrue random number.= =E2=80=9D > This change will be made in the description, and the function name will > be replaced with rte_csrand. If you decide to rte_csrand() it should fallback to get_random or get_entro= py. Note: many people don't fully trust RDRAND or ARM CPU instructions.=20 That is why the Linux entropy calls do not use only the HW instructions.