DPDK patches and discussions
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: "Mattias Rönnblom" <hofors@lysator.liu.se>
Cc: "Shunzhi Wen" <shunzhi.wen@arm.com>,
	"Thomas Monjalon" <thomas@monjalon.net>,
	"Mattias Rönnblom" <mattias.ronnblom@ericsson.com>,
	"Ruifeng Wang" <ruifeng.wang@arm.com>,
	"Bruce Richardson" <bruce.richardson@intel.com>,
	"Tyler Retzlaff" <roretzla@linux.microsoft.com>,
	"Min Zhou" <zhoumin@loongson.cn>,
	"David Christensen" <drc@linux.ibm.com>,
	"Stanislaw Kardach" <stanislaw.kardach@gmail.com>,
	"Konstantin Ananyev" <konstantin.v.ananyev@yandex.ru>,
	dev@dpdk.org, nd@arm.com,
	"Wathsala Vithanage" <wathsala.vithanage@arm.com>,
	"Jack Bond-Preston" <jack.bond-preston@arm.com>,
	"Dhruv Tripathi" <dhruv.tripathi@arm.com>
Subject: Re: [PATCH] eal: add support for TRNG with Arm RNG feature
Date: Thu, 25 Jul 2024 07:56:46 -0700	[thread overview]
Message-ID: <20240725075646.70e16939@hermes.local> (raw)
In-Reply-To: <44ab5731-6fc6-4283-835a-4f46f9e425a3@lysator.liu.se>

On Thu, 25 Jul 2024 06:48:47 +0200
Mattias Rönnblom <hofors@lysator.liu.se> wrote:

> >>
> >> 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.)  
> > 
> > I would trust the upstream kernel support for secure random more than
> > anything DPDK could develop. As soon as we get deeper into crypto it
> > opens up a whole new security domain and attack surface.
> >   
> 
> I much agree here.
> 
> What potentially would be useful is an EAL-level OS wrapper. So 
> getrandom() for UNIX-like OSes, and something else for Windows. In 
> addition, you could make larger getrandom() calls to shave off some 
> cycles on the average (at least for the non-vDSO case).
> 
> It seems to me we should defer the introduction of anything like that 
> until a) it's needed by a DPDK library, or b) someone on the application 
> side is asking for it.

Agreed. It doesn't make sense for DPDK to become a crypto library.
The community doesn't have the expertise and the infrastructure is missing
and there are several other projects that handle that OpenSSL etc.

  reply	other threads:[~2024-07-25 15:03 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-23 21:27 Shunzhi Wen
2024-07-24  6:40 ` Mattias Rönnblom
2024-07-24 14:35   ` Stephen Hemminger
2024-07-24 15:07     ` Mattias Rönnblom
2024-07-24 16:16       ` Stephen Hemminger
2024-07-24 19:14         ` Mattias Rönnblom
2024-07-24 20:02           ` Stephen Hemminger
2024-07-25  4:48             ` Mattias Rönnblom
2024-07-25 14:56               ` Stephen Hemminger [this message]
2024-07-26 18:34   ` Shunzhi Wen
2024-07-26 19:00     ` Stephen Hemminger
2024-07-26 20:12       ` Wathsala Wathawana Vithanage
2024-07-26 22:33     ` Mattias Rönnblom
2024-07-27 15:45       ` Wathsala Wathawana Vithanage
2024-07-27 15:54         ` Stephen Hemminger
2024-07-27 22:27           ` Wathsala Wathawana Vithanage
2024-07-27 23:55             ` Stephen Hemminger
2024-07-28  6:46               ` Mattias Rönnblom
2024-07-29  4:48               ` Wathsala Wathawana Vithanage
2024-07-27 17:07         ` Mattias Rönnblom
2024-07-27 22:45           ` Wathsala Wathawana Vithanage
2024-07-28  6:42             ` Mattias Rönnblom
2024-07-28 15:52               ` Stephen Hemminger
2024-07-29  4:34                 ` Wathsala Wathawana Vithanage
2024-07-29  6:34               ` Wathsala Wathawana Vithanage
2024-07-29  6:47                 ` Mattias Rönnblom
2024-07-29 18:16                   ` Wathsala Wathawana Vithanage
2024-07-29 18:31                     ` Stephen Hemminger
2024-07-29 19:11                     ` Mattias Rönnblom
2024-07-29 19:30                       ` Morten Brørup

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240725075646.70e16939@hermes.local \
    --to=stephen@networkplumber.org \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=dhruv.tripathi@arm.com \
    --cc=drc@linux.ibm.com \
    --cc=hofors@lysator.liu.se \
    --cc=jack.bond-preston@arm.com \
    --cc=konstantin.v.ananyev@yandex.ru \
    --cc=mattias.ronnblom@ericsson.com \
    --cc=nd@arm.com \
    --cc=roretzla@linux.microsoft.com \
    --cc=ruifeng.wang@arm.com \
    --cc=shunzhi.wen@arm.com \
    --cc=stanislaw.kardach@gmail.com \
    --cc=thomas@monjalon.net \
    --cc=wathsala.vithanage@arm.com \
    --cc=zhoumin@loongson.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).