> From: Mattias Rönnblom [mailto:hof...@lysator.liu.se]
> Sent: Monday, 29 July 2024 21.12
>
> On 2024-07-29 20:16, Wathsala Wathawana Vithanage wrote:
> >>
> >> Without a rationale why rte_csrand() functionality is something that
> should be
> >> in DPDK, and a rationale why the ARM CPU CSRNG is
On 2024-07-29 20:16, Wathsala Wathawana Vithanage wrote:
Without a rationale why rte_csrand() functionality is something that should be
in DPDK, and a rationale why the ARM CPU CSRNG is superior to getentropy(),
it doesn't really matter how the patch set looks like.
I've repeatedly asked for th
>
> Without a rationale why rte_csrand() functionality is something that should be
> in DPDK, and a rationale why the ARM CPU CSRNG is superior to getentropy(),
> it doesn't really matter how the patch set looks like.
>
> I've repeatedly asked for this information, and you've repeatedly ignored i
On 2024-07-29 08:34, Wathsala Wathawana Vithanage wrote:
...to have a non-zero chance of getting accepted.
I see too much uncertainty in that statement with "non-zero chance". As the
maintainer
of this library and someone with the community's best interest in mind, can you
outline
the requir
> ...to have a non-zero chance of getting accepted.
>
I see too much uncertainty in that statement with "non-zero chance". As the
maintainer
of this library and someone with the community's best interest in mind, can you
outline
the requirements for a rte_csrand implementation with a higher deg
> > > 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.
> >
> > Perhaps,
>
> The Linux kernel in arch/arm64/include/asm/archrandom.h has support
> already. The support includes lots of checks for capabilities and caveats for
> the
> limitations of the ARM implementation that are not reflected in this
> simplistic
> version.
No, such checks are unnecessary, because
(
On Sun, 28 Jul 2024 08:42:42 +0200
Mattias Rönnblom wrote:
> > 1- An implementation of rte_csrand that calls getrandom() with per-core
> > entropy caching. Which will be the default for DPDK.
> > 2- Build time flag to enable HW CSRNG for those who want to override the
> > default kernel getrand
On 2024-07-28 01:55, Stephen Hemminger wrote:
On Sat, 27 Jul 2024 22:27:05 +
Wathsala Wathawana Vithanage wrote:
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 ope
On 2024-07-28 00:45, Wathsala Wathawana Vithanage wrote:
If your patch are to have non-zero chance of being accepted, it should include
a base implementation based on getrandom() (and the Windows equivalent),
with the proper optimizations (e.g., batching entropy requests to the kernel
on a per-lc
On Sat, 27 Jul 2024 22:27:05 +
Wathsala Wathawana Vithanage wrote:
> > 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 in
> If your patch are to have non-zero chance of being accepted, it should include
> a base implementation based on getrandom() (and the Windows equivalent),
> with the proper optimizations (e.g., batching entropy requests to the kernel
> on a per-lcore basis).
>
> You would also need to provide a r
tzlaff ; 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
>
> On Sat, 27 Jul 2024 15:45:55
On 2024-07-27 17:45, Wathsala Wathawana Vithanage wrote:
Hi Mattias,
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
On Sat, 27 Jul 2024 15:45:55 +
Wathsala Wathawana Vithanage wrote:
> Hi Mattias,
>
> > > 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 feature
Hi Mattias,
> > 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 instructio
On 2024-07-26 20:34, Shunzhi Wen wrote:
I'm missing a rationale here. Why is this useful?
This creates an API for HW that supports cryptographically secure random number
generation.
If you want to extend with a cryptographically secure
random number generator, that's fine.
To have an API t
>
> If you decide to rte_csrand() it should fallback to get_random or get_entropy.
>
> Note: many people don't fully trust RDRAND or ARM CPU instructions.
> That is why the Linux entropy calls do not use only the HW instructions.
Thanks Stephen. I understand the concern, would it be acceptable f
On Fri, 26 Jul 2024 18:34:44 +
Shunzhi Wen wrote:
> > I'm missing a rationale here. Why is this useful?
> >
> This creates an API for HW that supports cryptographically secure random
> number generation.
>
> > If you want to extend with a cryptographically secure
> > random number genera
> I'm missing a rationale here. Why is this useful?
>
This creates an API for HW that supports cryptographically secure random number
generation.
> 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 AR
On 2024-07-24 22:02, Stephen Hemminger wrote:
On Wed, 24 Jul 2024 21:14:30 +0200
Mattias Rönnblom wrote:
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 oft
On Wed, 24 Jul 2024 21:14:30 +0200
Mattias Rönnblom wrote:
> >> 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 t
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
23 matches
Mail list logo
