On Sun, May 10, 2020 at 05:23:37AM +, Taylor R Campbell wrote:
> >
> > >(Obviously, it is possible to run a kernel with an /etc/rc script that
> > >skips loading the seed from disk altogether; I'm not considering weird
> > >customized installations like that. System engineers who futz with
>
> Date: Sun, 10 May 2020 04:58:23 - (UTC)
> From: mlel...@serpens.de (Michael van Elst)
>
> riastr...@netbsd.org (Taylor R Campbell) writes:
>
> >(Obviously, it is possible to run a kernel with an /etc/rc script that
> >skips loading the seed from disk altogether; I'm not considering weird
>
riastr...@netbsd.org (Taylor R Campbell) writes:
>(Obviously, it is possible to run a kernel with an /etc/rc script that
>skips loading the seed from disk altogether; I'm not considering weird
>customized installations like that. System engineers who futz with
>this are responsible for getting th
> Date: Sun, 10 May 2020 00:10:49 +
> From: m...@netbsd.org
>
> On Sat, May 09, 2020 at 10:56:51PM +, Taylor R Campbell wrote:
> > Given that, I think it is reasonable to implement getentropy(...) as
> > an alias for getrandom(..., GRND_INSECURE) == read from /dev/urandom
> > == sysctl ke
On Sat, May 09, 2020 at 10:56:51PM +, Taylor R Campbell wrote:
> Given that, I think it is reasonable to implement getentropy(...) as
> an alias for getrandom(..., GRND_INSECURE) == read from /dev/urandom
> == sysctl kern.arandom (as nia@ just committed the other day), which
> is consistent wi
> Date: Sun, 3 May 2020 21:43:15 +
> From: nia
>
> On Sun, May 03, 2020 at 09:28:37PM +, Taylor R Campbell wrote:
> > But on closer inspection, it's not clear there's a consensus on what
> > the semantics is supposed to be -- apparently _what_ everyone seems to
> > implement is slightly d
On Sat, May 09, 2020 at 05:30:18PM +0200, Joerg Sonnenberger wrote:
> On Sat, May 09, 2020 at 03:25:25PM +, nia wrote:
> > On Sat, May 09, 2020 at 01:13:44PM +, nia wrote:
> > > Right, yes, the CPUID stuff wasn't being defined when builing EVP which
> > > meant the dumb asm implementation w
In article <20200509045010.gb4...@mail.duskware.de>,
Martin Husemann wrote:
>On Fri, May 08, 2020 at 10:24:43PM +, m...@netbsd.org wrote:
>> The indirection only applies to the first call. The magic is within
>> rtld.
>
>You are comparing PLT calls with ifunc (where even normal PLT calls have
On Sat, May 09, 2020 at 03:25:25PM +, nia wrote:
> On Sat, May 09, 2020 at 01:13:44PM +, nia wrote:
> > Right, yes, the CPUID stuff wasn't being defined when builing EVP which
> > meant the dumb asm implementation was being used instead of HW/VP/BSAES.
> >
> > That's fixed now. Everything
On Sat, May 09, 2020 at 01:13:44PM +, nia wrote:
> Right, yes, the CPUID stuff wasn't being defined when builing EVP which
> meant the dumb asm implementation was being used instead of HW/VP/BSAES.
>
> That's fixed now. Everything else appears to still be slightly slower,
> but that's less cri
Right, yes, the CPUID stuff wasn't being defined when builing EVP which
meant the dumb asm implementation was being used instead of HW/VP/BSAES.
That's fixed now. Everything else appears to still be slightly slower,
but that's less critical than the AES implementation.
It almost seems like the asm implementations aren't being enabled
properly. Algorithms with no x86_64 asm (like blowfish) don't
shown a significant difference, whereas with AES and sha512
the difference is huge.
What's going on?
r[nia]$ /usr/pkg/bin/openssl speed -evp aes-256-gcm
Doing aes-256-g
12 matches
Mail list logo
