On Thu, Mar 24, 2022 at 01:34:08PM +, Taylor R Campbell wrote:
> > Date: Thu, 24 Mar 2022 14:23:09 +0100
> > From: Thomas Klausner
> >
> > On Thu, Mar 24, 2022 at 01:03:11PM +, Taylor R Campbell wrote:
> > > > Date: Thu, 24 Mar 2022 11:29:16 +0100
> > > > From: Thomas Klausner
> > > >
> Date: Thu, 24 Mar 2022 14:23:09 +0100
> From: Thomas Klausner
>
> On Thu, Mar 24, 2022 at 01:03:11PM +, Taylor R Campbell wrote:
> > > Date: Thu, 24 Mar 2022 11:29:16 +0100
> > > From: Thomas Klausner
> > >
> > > entropy_account_cpu() at netbsd:entropy_account_cpy+0x211
> >
> > Errr...
On Thu, Mar 24, 2022 at 01:03:11PM +, Taylor R Campbell wrote:
> > Date: Thu, 24 Mar 2022 11:29:16 +0100
> > From: Thomas Klausner
> >
> > I've just updated from a 3 days old kernel to todays, and it didn't
> > finish booting up.
> >
> > The console output, hand-copied:
> >
> >
ain+0x331
Interesting! I see the bug, and I've committed what I think should
fix it in kern_entropy.c 1.54, but I'm curious what assortment of
entropy sources led you to trip over this -- can you send me dmesg and
rndctl -l?
Hi!
I've just updated from a 3 days old kernel to todays, and it didn't
finish booting up.
The console output, hand-copied:
breakpoint() at netbsd:breakpoint
vpanic() at netbsd:vpanic+0x156
kern_assert() at netbsd:kern_assert+0x4b
entropy_account_cpu() at netbsd:entropy_account_cpy+0x211
On Mon, Feb 14, 2022 at 12:54:27PM +0100, Riccardo Mottola wrote:
> [ 10879.215507] entropy: pid 6895 (python3.9) blocking due to lack of
> entropy
[..]
> seed 0 0 ???collect, v
The last line means your system did not load entropy at boot time, may
Hello,
entropy for me is still brittle.
Does "consolidating" entropy survive a reboot?
I still get stalls. The first thing was install a new kernel.. and again
I got the dreaded not enough entropy.
[ 10879.215507] entropy: pid 6895 (python3.9) blocking due to lack of
entropy
I th
On Tue, 1 Feb 2022 at 23:31, Greg A. Woods wrote:
>
> At Thu, 27 Jan 2022 10:40:20 +0100, Martin Husemann
> wrote:
> Subject: Re: the entropy bug, and device timeouts (was: Note: two files
> changed and hashes/signatures updated for NetBSD 8.1)
> >
> > On Wed, Jan 2
At Thu, 27 Jan 2022 10:40:20 +0100, Martin Husemann wrote:
Subject: Re: the entropy bug, and device timeouts (was: Note: two files changed
and hashes/signatures updated for NetBSD 8.1)
>
> On Wed, Jan 26, 2022 at 10:56:53PM -0800, Greg A. Woods wrote:
> > Well, if you have a hardwar
On Wed, Jan 26, 2022 at 10:56:53PM -0800, Greg A. Woods wrote:
> Well, if you have a hardware RNG, or my patches, then that'll do
> something, but otherwise it's just useless noise and misdirection.
This is not true. Once there is enough entropy gathered (or the system
has bee
At Wed, 26 Jan 2022 16:47:15 +1300, Lloyd Parkes
wrote:
Subject: Re: the entropy bug, and device timeouts (was: Note: two files changed
and hashes/signatures updated for NetBSD 8.1)
>
> The change was more subtle than that I
> think. Untrusted hardware was used as an
> en
On 25/01/22 17:57, Greg A. Woods wrote:
I have fixes that restore the previous option to use "untrusted"
hardware as an entropy source. They may need some updating to be truly
complete in the most recent -current, as I'm still back at 9.99.81.
The change was more subtle than th
At Mon, 24 Jan 2022 08:46:36 +, "Thomas Mueller"
wrote:
Subject: Re: Note: two files changed and hashes/signatures updated for NetBSD
8.1
>
> Does there look to be a fix in the entropy bug?
>
> This bug relates to entropy and how it impedes building many packages
>
On Wed, Aug 18, 2021 at 08:43:03AM +, Thomas Mueller wrote:
> What is the current status of the entropy bug in NetBSD-current,
> which prevents building and installing some packages in pkgsrc?
I am not sure what "entropy bug" you are refering to.
There is an (admin) issue if
What is the current status of the entropy bug in NetBSD-current, which prevents
building and installing some packages in pkgsrc?
Would this bug also prevent updating the base system from source (black hole)?
Would this bug affect building software outside pkgsrc, either for NetBSD or
cross
At Wed, 16 Jun 2021 11:18:02 +0200, Martin Husemann wrote:
Subject: Re: Entropy error blocks lang/python38 installation
>
> On Wed, Jun 16, 2021 at 11:10:34AM +0200, Joerg Sonnenberger wrote:
> > On Wed, Jun 16, 2021 at 06:13:23AM +0200, Martin Husemann wrote:
> > > On Wed,
On Wed, Jun 16, 2021 at 11:10:34AM +0200, Joerg Sonnenberger wrote:
> On Wed, Jun 16, 2021 at 06:13:23AM +0200, Martin Husemann wrote:
> > On Wed, Jun 16, 2021 at 03:42:35AM +, Thomas Mueller wrote:
> > > I believe I must apply the fix/workaround every time.
> >
&g
On Wed, Jun 16, 2021 at 06:13:23AM +0200, Martin Husemann wrote:
> On Wed, Jun 16, 2021 at 03:42:35AM +, Thomas Mueller wrote:
> > I believe I must apply the fix/workaround every time.
>
> The entropy state gets stored on shutdown and reloaded on next boot.
> Fixing
On Wed, Jun 16, 2021 at 03:42:35AM +, Thomas Mueller wrote:
> I believe I must apply the fix/workaround every time.
The entropy state gets stored on shutdown and reloaded on next boot.
Fixing it once is enough.
> Last time I looked at the releng wiki page, I noticed that there were
&g
from Martin Musemann:
> On Tue, Jun 15, 2021 at 09:24:01AM +, Thomas Mueller wrote:
> > This entropy thing seems crazy to me
> It is! But it also is:
> - a one time only thing (supposed to happen when you set the machine up
>for the first time)
> - a current
from Thomas Klausner:
> On Mon, Jun 14, 2021 at 10:24:23PM +, Thomas Mueller wrote:
> > Another old bug has popped up that I thought was fixed some time ago for
> > NetBSD-current and releng-9:
> > [ 190470.442443] wd1d: error writing fsbn 2316146760 of
> > 2316146760-2316146791 (wd1 bn
On Tue, Jun 15, 2021 at 09:24:01AM +, Thomas Mueller wrote:
> This entropy thing seems crazy to me
It is! But it also is:
- a one time only thing (supposed to happen when you set the machine up
for the first time)
- a current only issue
- only affecting some machines
- a bloc
One described here
> https://mail-index.netbsd.org/current-users/2020/05/01/msg038495.html,
> you can fool system into believing that it has enough entropy:
> dd if=/dev/urandom of=/dev/random bs=32 count=1
> sysctl -w kern.entropy.consolidate=1
-> These two lines enabled me to bu
One described here
> https://mail-index.netbsd.org/current-users/2020/05/01/msg038495.html,
> you can fool system into believing that it has enough entropy:
> dd if=/dev/urandom of=/dev/random bs=32 count=1
> sysctl -w kern.entropy.consolidate=1
> Another workaround which also make
On Mon, Jun 14, 2021 at 08:15:27AM +, Thomas Mueller wrote:
> [ 386.3532035] entropy: pid 24617 (python) blocking due to lack of entropy
This means your setup is incomplete. You need to seed entropy, e.g.
by one of the methods in entropy(7) in the "Adding entropy" subsec
-index.netbsd.org/current-users/2020/05/01/msg038495.html,
you can fool system into believing that it has enough entropy:
dd if=/dev/urandom of=/dev/random bs=32 count=1
sysctl -w kern.entropy.consolidate=1
Another workaround which also makes python to compile was described in
pkg/55847: https
I've been trying to install lang/python38, critically important for further
progress building and installing packages from pkgsrc
System is NetBSD-9.99.82 amd64.
Build goes through and most of the way through installation, but ends with a
green console message
[ 386.3532035] entropy: pid
On Sun, Apr 04, 2021 at 11:02:02PM +, Taylor R Campbell wrote:
>
> Lots of SoCs have on-board RNGs these days; there are Intel and ARM
> CPU instructions (no ARMv8.5 hardware yet that I know of, but we're
> ready for its RNG!); some crypto decelerators like tpm(4), ubsec(4),
> and hifn(4)
On Tue, Apr 06, 2021 at 10:54:51AM -0700, Greg A. Woods wrote:
> At Mon, 5 Apr 2021 23:18:55 -0400, Thor Lancelot Simon wrote:
>
> > But what you're missing is that neither does what you
> > think. When rndctl -L runs after the system comes up multiuser, all
> > entrop
At Wed, 7 Apr 2021 22:47:39 +0200, Martin Husemann wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> When you create a custom setup like that, you will have to replace
> etc/rc.d/entropy with a custom solution (e.g. mounting some flash storage).
No stor
storage.
When you create a custom setup like that, you will have to replace
etc/rc.d/entropy with a custom solution (e.g. mounting some flash storage).
Or you ignore the issue and do the dd at each boot - hopefully not generating
any strong keys on that machine then (but you would have no good storag
At Wed, 7 Apr 2021 09:52:29 +0200, Martin Husemann wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> On Tue, Apr 06, 2021 at 03:12:45PM -0700, Greg A. Woods wrote:
> > > Isn't it as simple as:
> > >
> > > dd bs=32 if=/dev/urandom of=/
On Wed, Apr 07, 2021 at 07:53:07AM -0400, matthew sporleder wrote:
> So on a brand new installation/first boot why isn't the clock a
> sufficiently random thing? (anymore?)
Becaus it isn't random?
> Hung and unusable systems are a big problem. Happening on the first
> boot is not a good first
On Wed, Apr 7, 2021 at 7:10 AM Martin Husemann wrote:
>
> On Wed, Apr 07, 2021 at 07:05:12AM -0400, matthew sporleder wrote:
> > Is the issue gaw saw exclusive to xen first boots? Are there other
> > ways to end up in his situation?
>
> It happens on all new installations for machines with no
On Tue, 6 Apr 2021, RVP wrote:
On Tue, 6 Apr 2021, Taylor R Campbell wrote:
Why do you say that? We do incorporate many sources that are not
well-studied -- every keystroke, for example, and the CPU cycle
counter at the time of the keystroke, affects the output of
/dev/urandom.
Is the
On Wed, Apr 07, 2021 at 07:05:12AM -0400, matthew sporleder wrote:
> Is the issue gaw saw exclusive to xen first boots? Are there other
> ways to end up in his situation?
It happens on all new installations for machines with no RNG, which is
the far majority of everything but "newish" amd64 and
erfectly secure" and "hopeless".
>
> The main issue that hits people is that the traditional mechanism by
> which the OS reports a potential security problem with entropy is for
> it to make applications silently hang -- and the issue is getting
> worse now that getran
On Tue, Apr 06, 2021 at 06:24:38PM +, Koning, Paul wrote:
> > Isn't it as simple as:
> >
> > dd bs=32 if=/dev/urandom of=/dev/random
> >
> > ?
>
> That runs the risk of people thinking it adds entropy. I'd be more
> comfortable with this:
&
On Tue, Apr 06, 2021 at 03:12:45PM -0700, Greg A. Woods wrote:
> > Isn't it as simple as:
> >
> > dd bs=32 if=/dev/urandom of=/dev/random
>
> No, that still leaves the question of _when_ to run it. (And, at least
> at the moment, where to put it. /etc/rc.local?)
Of course not!
You run it
influenced like this?
What do you mean by `things like timing jitter have been pooh-poohed
in the literature'? Timing jitter in ring oscillators arising from
thermal noise in the silicon is the main source of entropy in most
on-die hardware RNGs on the market that I'm aware of. This design is
reasonably
At Tue, 6 Apr 2021 20:21:43 +0200, Martin Husemann wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> On Tue, Apr 06, 2021 at 10:54:51AM -0700, Greg A. Woods wrote:
> >
> > And the stock implementation has no possibility of ever providing an
> > in
plementation has no possibility of ever providing an
>> initial seed at all on its own (unlike previous implementations, and of
>> course unlike what my patch _affords_).
>
> Isn't it as simple as:
>
> dd bs=32 if=/dev/urandom of=/dev/random
>
> ?
That runs
> On Apr 6, 2021, at 1:54 PM, Greg A. Woods wrote:
>
> At Mon, 5 Apr 2021 23:18:55 -0400, Thor Lancelot Simon wrote:
> Subject: Re: regarding the changes to kernel entropy gathering
>>
>>> dd if=/dev/urandom of=/dev/random bs=32 count=1
>>
>> I
On Tue, Apr 06, 2021 at 10:54:51AM -0700, Greg A. Woods wrote:
> Except it seems to be useless in practice without an initial seed,
Yes.
> And the stock implementation has no possibility of ever providing an
> initial seed at all on its own (unlike previous implementations, and of
> course
At Tue, 6 Apr 2021 12:08:54 +, Taylor R Campbell
wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> The main issue that hits people is that the traditional mechanism by
> which the OS reports a potential security problem with entropy is for
> it to make
At Mon, 5 Apr 2021 23:18:55 -0400, Thor Lancelot Simon wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> > dd if=/dev/urandom of=/dev/random bs=32 count=1
>
> It's no better.
So then I would say that in fact using some less trustworthy source of
l mechanism by
which the OS reports a potential security problem with entropy is for
it to make applications silently hang -- and the issue is getting
worse now that getrandom() is more widely used, e.g. in Python when
you do `import multiprocessing'.
Based on experience over the past year with a
u say that? We do incorporate many sources that are not
well-studied -- every keystroke, for example, and the CPU cycle
counter at the time of the keystroke, affects the output of
/dev/urandom.
We just don't _count_ these sources for the purpose of detecting and
reporting the potential security prob
On Mon, Apr 05, 2021 at 01:22:49PM -0700, Greg A. Woods wrote:
> I don't see how. I don't see any evidence for that happening.
>
> So, show me how entropy is being collected in my system:
>
> 16:18 [1.793] # uptime
> 4:19PM up 22 days, 16:04, 2 users, load averages: 0.00,
On Mon, Apr 05, 2021 at 02:13:31PM -0700, Greg A. Woods wrote:
> At Mon, 5 Apr 2021 15:37:49 -0400, Thor Lancelot Simon wrote:
> Subject: Re: regarding the changes to kernel entropy gathering
> >
> > On Sun, Apr 04, 2021 at 03:32:08PM -0700, Greg A. Woods wrote:
> > &g
At Mon, 5 Apr 2021 15:37:49 -0400, Thor Lancelot Simon wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> On Sun, Apr 04, 2021 at 03:32:08PM -0700, Greg A. Woods wrote:
> >
> > BTW, to me reusing the same entropy on every reboot seems less secure.
>
On Sun, Apr 04, 2021 at 03:32:08PM -0700, Greg A. Woods wrote:
>
> BTW, to me reusing the same entropy on every reboot seems less secure.
Sure. But that's not what the code actually does.
Please, read the code in more depth (or in this case, breadth), then argue
about it.
At Mon, 5 Apr 2021 15:35:12 -0400, Thor Lancelot Simon wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> All those inputs are *already* being injected into the entropy pool. If you
> don't understand that, you need to read the code more.
I don't see how. I don'
On Mon, Apr 05, 2021 at 09:30:16AM -0700, Greg A. Woods wrote:
> At Mon, 5 Apr 2021 10:46:19 +0200, Manuel Bouyer
> wrote:
> Subject: Re: regarding the changes to kernel entropy gathering
> >
> > If I understood it properly, there's no need for
at I believe that system
fans are a very good example of a case where there is a well understood
_physical_ basis -- turbulence -- for the existence of the entropy being
collected, and that we should count it, in a very conservative way.
If your system has an audio device, and you mute all the inp
On Mon, Apr 05, 2021 at 09:30:16AM -0700, Greg A. Woods wrote:
> At Mon, 5 Apr 2021 10:46:19 +0200, Manuel Bouyer
> wrote:
> Subject: Re: regarding the changes to kernel entropy gathering
> >
> > If I understood it properly, there's no need for
At Mon, 5 Apr 2021 03:02:42 +0200, Joerg Sonnenberger wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> Except that's not what the system is doing. It removes the seed file on
> boot and creates a new one on shutdown.
That's not exactly what the documentation say
At Mon, 5 Apr 2021 16:13:55 +1200, Lloyd Parkes
wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> The current implementation prints out a message whenever it blocks a
> process that wants randomness, which immediately makes this
> implementation superior t
At Mon, 5 Apr 2021 10:46:19 +0200, Manuel Bouyer wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> If I understood it properly, there's no need for such a knob.
> echo 0123456789abcdef0123456789abcdef > /dev/random
>
> will get you back to the state
At Sun, 4 Apr 2021 18:47:23 -0700, Brian Buhrow wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> Hello. As I understand it, Greg ran into this problem on a xen domu.
> In checking my NetBSD-9 system running as a domu under xen-4.14.1,
> there is no rdra
On Sun, Apr 04, 2021 at 06:47:23PM -0700, Brian Buhrow wrote:
> Hello. As I understand it, Greg ran into this problem on a xen domu. In
> checking my NetBSD-9
> system running as a domu under xen-4.14.1, there is no rdrand or rdseed
> feature exposed to
> domu's by xen. This observation is
On Mon, Apr 05, 2021 at 01:16:56AM +, RVP wrote:
> [...]
> Hmm. I have to say, that now I find myself not disagreeing with Greg's
> point of view: Maybe NetBSD's default is too strict and a knob like
> kern.entropy.use_pooh_poohed_sources=1 would not be a bad thing for
> some users--with all
>
} > > Your change _creates_ the lie that every bit of data entered this way
} > > is drawn from a source with independent uniform distribution.
} >
} > No, my change _allows_ the administrator to decide which devices can be
} > used as estimating/counting entropy source
ork (in case of network interrupts). That's the
>real reason why their entropy is hard to estimate. It becomes even more
>annoying with modern hardware features like interrupt moderation of
>nics. They can make the timing of interrupts highly predicable.
Must be a thing of the past,
ay. But if you answer no,
> > we should automatically copy enough pseudo-entropy bits to /dev/rnd
> > to prevent future blocking.
>
> For most architectures, sysinst does do exactly that. It assumes that
> you don't just reset or reboot, but properly shutdown the system.
&
On Sun, 4 Apr 2021, Taylor R Campbell wrote:
No, because the output of /dev/random and /dev/urandom is the output
of a pseudorandom number generator that meets modern standards of
security.
If anyone had _ever_ published statistical tests that the PRNG failed
in a detectable way, then (a) this
With some trepidation, I'm going to dip into this conversation even
though I haven't read all of. I don't have the mental fortitude for
that. I have two suggestions, one short and one long.
Firstly, we could just have an rc.d script that checks to see if the
system has /var/db/entropy-file
. You might think it is insane, and that's fine, but
there are reasons.
On recent NetBSD, as I understand it, I can
dd if=/dev/zero bs=N count=1 >/dev/random
and now I have "entropy". But it refuses to provide a simpler knob
to do the same thing (or perhaps something a
> All that changed is that we don't pretend it provides entropy.
Instead, you pretend it provides none.
Neither pretense is accurate (where the "pretend it provides entropy"
refers to providing any non-configurable fixed amount). The real
problem here, as I see it, is that NetB
Hello. As I understand it, Greg ran into this problem on a xen domu. In
checking my NetBSD-9
system running as a domu under xen-4.14.1, there is no rdrand or rdseed feature
exposed to
domu's by xen. This observation is confirmed by looking at the xen command
line reference
page:
ideration and that is cloning virtual machines. The short
answer is that you as system integrator are responsible for handling it
in an appropiate manner. Ensuring that the VM sees enough entropic
action before the entropy is accessed would ensure that. The seed file
doesn't replace the entropy poo
On Sun, Apr 04, 2021 at 03:32:08PM -0700, Greg A. Woods wrote:
> At Mon, 05 Apr 2021 00:14:30 +0200 (CEST), Havard Eidnes
> wrote:
> Subject: Re: regarding the changes to kernel entropy gathering
> >
> > > What about architectures that have no
devices can be
used as estimating/counting entropy sources. For example I know that
many of the devices on almost all of my machines (virtual or otherwise)
are equally good sources of entropy for their uses.
I think running the /dev/random bit-stream through some statistical
tests, (both
NG on x86? It
got killed by a down-shrink in the pre-release phase. The hardware still
said it is present. That's the reason why we don't use RDSEED directly
in place of the entropy pool and still merge other potential entropy
sources in.
Joerg
>> Nope, not entirely. But they have to be seeded once. If they have
>> storage which survives reboots, and entropy is saved and restored on
>> reboot, they will be ~fine.
> BTW, to me reusing the same entropy on every reboot seems less
> secure.
Hence the "save
least
one incident that demonstrates that on occasion they don't.)
If I am ever in a situation where I need randomness good enough that I
care about things like the accuracy of entropy estimates, I expect the
applicable threat model will consider CPU manufacturers untrusted.
Thus, I would want t
At Sun, 4 Apr 2021 23:09:18 +, Taylor R Campbell
wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> If you know this (and this is something I certainly can't confidently
> assert!), you can write 32 bytes to /dev/random, save a seed, and be
> done with
At Mon, 5 Apr 2021 01:05:58 +0200, Joerg Sonnenberger wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> Part of the problem here is that most of the non-RNG data sources are
> easily observable either from the local system (e.g. any malicious user)
>
ussed in much more significant forums than NetBSD mailing lists,
and (b) we would stop using this PRNG and switch to another one.
(Device-dependent health tests do make sense in the HWRNG device
driver, to detect broken devices before we treat them as having
entropy, which is why we do them wh
>> > No amount of uptime and activity was increasing the entropy in my
>> > system before I patched it.
>>
>> As I understand it, entropy was being contributed. What wasn't
>> happening was the random driver code recognizing and acknowledging that
>>
> Date: Sun, 04 Apr 2021 12:58:09 -0700
> From: "Greg A. Woods"
> References:
> <20210404094958.692f360...@jupiter.mumble.net>
>
> At Sun, 4 Apr 2021 09:49:58 +, Taylor R Campbell
> wrote:
> Subject: Re: regarding the changes to kernel entropy
the problem here is that most of the non-RNG data sources are
easily observable either from the local system (e.g. any malicious user)
or other VMs on the same machine (in case of a hypervisor) or local
machines on the same network (in case of network interrupts). That's the
real reason why t
n a system has RDRAND/RDSEED?
# cpuctl identify 0 | grep -e RDRAND -e RDSEED
cpu0: features1 0x7fbae3bf
> Are there other sources that can
> be positively identified as providing randomness?
`rndctl -l' will tell you whether any sources you have on your syste
rbitrary data on your disk, that adversary is
outside the threat model and you need to do something else to deal
with such an adversary -- for example, by encrypting your disk with
cgd(4).
If the random seed is stored on a networked file system, then NetBSD
incorporates it but treats it as having zero entro
od
> enough" for the vast bulk of our users and potential users.
>
> Perhaps sysinst(8) should ask
>
> Do you need a hyper-secure system?
>
> If yes, then leave things as they are today. But if you answer no,
> we should automatically copy enough pseudo-entropy bits t
At Mon, 05 Apr 2021 00:14:30 +0200 (CEST), Havard Eidnes
wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> > What about architectures that have nothing like RDRAND/RDSEED? Are
> > they, effectively, totally unsupported now?
>
> Nope, not ent
At Mon, 05 Apr 2021 00:07:49 +0200 (CEST), Havard Eidnes
wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> Indeed, that's also compatible with what I wrote. The samples
> from whatever sources you have are still being mixed into the
> pool, but they are not b
At Sun, 4 Apr 2021 16:39:11 -0400 (EDT), Mouse
wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> > No amount of uptime and activity was increasing the entropy in my
> > system before I patched it.
>
> As I understand it, entropy was being cont
ally unsupported now?
Nope, not entirely. But they have to be seeded once. If they
have storage which survives reboots, and entropy is saved and
restored on reboot, they will be ~fine.
Systems without persistent storage and also without RDRAND/RDSEED
will however be ... a more challenging problem.
Regards,
- Håvard
>> Do note, the existing randomness sources are still being sampled and
>> mixed into the pool, so even if the starting state from the saved
>> entropy may be known (by violating the security of the storage),
>> it's still not possible to predict the complete stream of
are today. But if you answer no,
we should automatically copy enough pseudo-entropy bits to /dev/rnd
to prevent future blocking.
++--+---+
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired) |
> No amount of uptime and activity was increasing the entropy in my
> system before I patched it.
As I understand it, entropy was being contributed. What wasn't
happening was the random driver code recognizing and acknowledging that
entropy, because it had no way to tell ho
> My question is, how can we tell what random sources a system actually
> has, i.e. is there some flag that cpuctl identify shows when a system
> has RDRAND/RDSEED?
What about architectures that have nothing like RDRAND/RDSEED? Are
they, effectively, totally unsupported now?
/~\ The ASCII
At Sun, 04 Apr 2021 21:14:31 +0200 (CEST), Havard Eidnes
wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> Do note, the existing randomness sources are still being sampled and
> mixed into the pool, so even if the starting state from the saved
> entropy
At Sun, 04 Apr 2021 23:47:10 +0700, Robert Elz wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> If we want really good security, I'd submit we need to disable
> the random seed file, and RDRAND (and anything similar) until we
> have proof that they're perfect
At Sun, 4 Apr 2021 09:49:58 +, Taylor R Campbell
wrote:
Subject: Re: regarding the changes to kernel entropy gathering
>
> > Date: Sat, 03 Apr 2021 12:24:29 -0700
> > From: "Greg A. Woods"
> >
> > Updating a system, even on -current, shouldn't cr
es are still being sampled and
mixed into the pool, so even if the starting state from the saved
entropy may be known (by violating the security of the storage),
it's still not possible to predict the complete stream of randomness
data once the system has seen a bit of uptime (given that there are
m has RDRAND/RDSEED? Are there other sources that can
> be positively identified as providing randomness?
I am not sure I understand the question correctly. rndctl will show the
entropy available from the source. For cpu internal random sources,
on x86 cpuctl identify shows them:
# cpuctl identify 0
On Sun, Apr 04, 2021 at 11:14:31AM -0700, John Nemeth wrote:
> I understand the need for good random sources, and won't argue
> it. My question is, how can we tell what random sources a system
> actually has, i.e. is there some flag that cpuctl identify shows
> when a system has
On Apr 4, 9:49, Taylor R Campbell wrote:
}
} What NetBSD-current is telling you on your Xen system, on a CPU
} predating RDRAND/RDSEED, is the unfortunate truth that there is no
} reliable source of entropy available in your system -- annoying, yes,
} but when you talk about `matters so
1 - 100 of 161 matches
Mail list logo
