Re: regarding the changes to kernel entropy gathering

[Thor Lancelot Simon]

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) have RNGs; and there are some dedicated RNG devices like
> ualea(4).

Can we actually use the TPM RNG from in-kernel?  Whether we should is a
different, interesting question, given how it is typically implemented.

-- 
 Thor Lancelot Simon t...@panix.com
  "Whether or not there's hope for change is not the question.  If you
   want to be a free person, you don't stand up for human rights because
   it will work, but because it is right."  --Andrei Sakharov

Re: regarding the changes to kernel entropy gathering

[Thor Lancelot Simon]

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
> > entropy samples that have been added (which are in the per-cpu pools)
> > are propagated to the global pool.  Every stream RNG on the system then
> > rekeys itself - they are _not_ just using the entropy from the seed on
> > disk.  Even if nothing does so earlier, when rndctl -S runs as the system
> > shuts down, again all entropy samples that have been added (which, again,
> > are accumulating in the per-cpu pools) are propagated to the global pool;
> > all the stream RNGs rekey themselves again; then the seed is extracted.
> 
> That's all great, and more or less what I've assumed from all the
> previous discussion
> 
> Except it seems to be useless in practice without an initial seed,

Again there's really little I can do other than suggest you read the code.
You are certainly competent to do so, and the code does not do what you
keep claiming it does.  Read the code, all of it -- it's only a few hundred
lines -- and have a think.

When rndctl -L runs, or you perform a sufficiently long write to /dev/random,
all the per-CPU pools, which, counter to what you keep claiming, *do* accumulate
samples from all the same sources they used to, are coalesced into the global
pool.  When rndctl -S runs, all the per-CPU pools, which, counter to what you
keep claiming, *do* accumulate samples from all the same sources they used to,
are coalesced into the global pool.  If you'd like those samples coalesced
into the global pool more frequently, you can use the sysctl to do so.

Thor

Re: regarding the changes to kernel entropy gathering

[Greg A. Woods]

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 storage means "NO 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 storage
> for those anyway).

Or I don't ignore the issue and instead I fix the code so that it's
still possible to get entropy estimates from non-hardware-RNG devices
and then things keep working the way they used to, and there's still
some possibility of _real_ entropy being used to seed the PRNGs.

From what I've seen here so far I'm far from alone in wanting that
ability.

What's most confusing is to why there's such animosity and stubborn
unwillingness to even consider that the old way of getting some entropy
from a few less-than-perfect sources was good enough for many, or even
most, of us.

It's better than no entropy when there are no "perfect" sources, and
that's also a situation that includes many of us.

It doesn't have to be the default.

-- 
Greg A. Woods 

Kelowna, BC +1 250 762-7675   RoboHack 
Planix, Inc.  Avoncote Farms 


pgpgg9AaQiU92.pgp
Description: OpenPGP Digital Signature

Re: regarding the changes to kernel entropy gathering

[Martin Husemann]

On Wed, Apr 07, 2021 at 12:14:58PM -0700, Greg A. Woods wrote:
> > You run it once. Manually. And never again.
> 
> Nope, sorry, that's not a good enough answer.

It is for the typical and default installs.

>  It doesn't solve the
> problem of dealing with a lack of mutable 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 storage
for those anyway).

Martin

Re: regarding the changes to kernel entropy gathering

[Greg A. Woods]

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=/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 once. Manually. And never again.

Nope, sorry, that's not a good enough answer.  It doesn't solve the
problem of dealing with a lack of mutable storage.

A system _MUST_ be able to be booted and with no user intervention be
able to (eventually) get to the state where /dev/random and getrandom(2)
WILL NOT block, and it _MUST_ be able to do so without the help of any
hardware RNG, and without the ability to store (and read) a seed from a
file or other storage device.

I.e. we _MUST_ be _ABLE_ to choose to use other devices as sources for
entropy, even if they are not perfect.  We had this, it works fine, we
still need it.

--
Greg A. Woods 

Kelowna, BC +1 250 762-7675   RoboHack 
Planix, Inc.  Avoncote Farms 


pgpeaL6Xd0CAO.pgp
Description: OpenPGP Digital Signature

Re: regarding the changes to kernel entropy gathering

[Martin Husemann]

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 impression. :)

It does not happen on first boot. It needs a one-time fix after installation,
which is why I added the fix to the installer.

Martin

Re: regarding the changes to kernel entropy gathering

[matthew sporleder]

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 RNG, which is
> the far majority of everything but "newish" amd64 and a few arm and mips
> boards/SoC.
>
> It is unrelated to Xen.
>
> Martin

So on a brand new installation/first boot why isn't the clock a
sufficiently random thing? (anymore?)

Hung and unusable systems are a big problem.  Happening on the first
boot is not a good first impression. :)

Re: regarding the changes to kernel entropy gathering

[RVP]

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 output of /dev/random also influenced like this?



Ah, no need to answer this: it's already in rnd(4):

 The operating system continuously makes observations of hardware
 devices, such as network packet timings, disk seek delays,
 and keystrokes.  The observations are combined into a seed
 for a cryptographic pseudorandom number generator (PRNG) which
 is used to generate the outputs of both /dev/random and
 /dev/urandom.

-RVP

Re: regarding the changes to kernel entropy gathering

[Martin Husemann]

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 a few arm and mips
boards/SoC.

It is unrelated to Xen.

Martin

Re: regarding the changes to kernel entropy gathering

[matthew sporleder]

> On Apr 6, 2021, at 8:09 AM, Taylor R Campbell  wrote:
> 
> 
>> Date: Mon, 05 Apr 2021 10:58:58 +0700
>> From: Robert Elz 
>> I understand that some people desire highly secure systems (I'm not
>> convinced that anyone running NetBSD can really justify that desire,
>> but that's beside the point) and that's fine - make the system be able
>> to be as secure as possible, just don't require me to enable it, and
>> don't make it impossible or even difficuly to disable it - and allow
>> some kind of middle ground, just just "perfectly 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 getrandom() is more widely used, e.g. in Python when
> you do `import multiprocessing'.
> 
> Based on experience over the past year with a meaningful criterion for
> _detecting_ potential problems, I don't think that's a useful
> mechanism for _reporting_ them, which is why I added several other
> mechanisms -- a line in the /etc/security report, an `entropy' knob in
> /etc/rc.conf to wait or fail to single-user (default: neither) -- and
> proposed to remove the blocking behaviour of getrandom() in favour of
> focusing on feedback in system integration:
> 
> https://mail-index.netbsd.org/tech-userlevel/2021/01/11/msg012807.html
> 
> (main discussion after all the noise starts here:
> https://mail-index.netbsd.org/tech-userlevel/2021/01/15/msg012846.html)
> 
> But I ran out of steam to continue the discussion at the time.


Is the issue gaw saw exclusive to xen first boots?  Are there other ways to end 
up in his situation?

Re: regarding the changes to kernel entropy gathering

[Martin Husemann]

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:
> 
>   dd bs=32 if=/dev/zero of=/dev/random
> 
> because it makes the security implications more obvious.

Both ways are equally unclear to anyone not looking deep enough. Your
method could be read like "we start with empty state".

Martin

Re: regarding the changes to kernel entropy gathering

[Martin Husemann]

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 once. Manually. And never again.

Martin

Re: regarding the changes to kernel entropy gathering

[RVP]

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 output of /dev/random also 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 well-studied in the literature.



I should've been more precise :(. Back in the beginning of the year
when a related discussion re: initial seeding on devices w/o usable
audio devices got stuck, I said that when all else fails the user
can be asked to mash on the keyboard and jiggle the mouse. To which
nia@ responded that those old-fashioned methods weren't considered
good enough nowadays, and linked to a paper which discussed this.

I had in mind that (and similar stuff) when I wrote what I did--not
well-studied physical processes like jitter derived from comparing
a pair of free-running oscillators.

-RVP

Re: regarding the changes to kernel entropy gathering

[Greg A. Woods]

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
> > 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

No, that still leaves the question of _when_ to run it.  (And, at least
at the moment, where to put it.  /etc/rc.local?)

Isn't something the following better (assuming you choose your devices
carefully):

echo 'rndctl_flags="-t env;-t disk;-t tty"' >> /etc/rc.conf

That's what my patches fix and allow, and this way you don't have to
guess when you can safely use /dev/urandom as an entropy seed -- the
seeding happens in real time, and only as entropy bits are made
available from those given devices.

That can also be done by sysinst, assuming a reasonably well worded
question can be answered, and that it might only need to be asked if
there are no "rng" type devices already.

Doing this also requires no network access (ever).

It can even be done, ahead of time, for use on immutable systems.

--
Greg A. Woods 

Kelowna, BC +1 250 762-7675   RoboHack 
Planix, Inc.  Avoncote Farms 


pgpW4B04umieR.pgp
Description: OpenPGP Digital Signature

Re: regarding the changes to kernel entropy gathering

[Koning, Paul]

> On Apr 6, 2021, at 2:21 PM, Martin Husemann  wrote:
> 
> 
> [EXTERNAL EMAIL] 
> 
> 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 unlike what my patch _affords_).
> 
> 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:

dd bs=32 if=/dev/zero of=/dev/random

because it makes the security implications more obvious.

paul

Re: regarding the changes to kernel entropy gathering

[Koning, Paul]

> 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
>> 
>> It's no better.
> 
> So then I would say that in fact using some less trustworthy source of
> randomness (e.g. environmental sensors (including audio), clock skew,
> disk rotational latency, etc., even network jitter if there is no other
> source) as the initial seed entropy _is_ better, for most situations,
> and perhaps for _ALL_ situations where no hardware-RNG is available or
> possible.  Better in part because it prevents the brain-dead way of
> seeding, but also because it mixes real-world data in an algorithmically
> sound way.

I've pointed out in the past that mixing in more external stuff can't make the 
RNG any worse, assuming it was correctly designed to begin with.  So if you 
still in various external inputs, the worst that can happen is that you get no 
useful added entropy.

In my way of thinking, externals events timestamped with a high resolution 
(microsecond or better) system clock are likely to have at least a small amount 
of entropy.  It's certainly true that external inputs may be observable, but 
the nanosecond timestamp the system puts on the packet isn't predictable from 
the outside (the low order couple of bits, that is).  

paul

Re: regarding the changes to kernel entropy gathering

[Martin Husemann]

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 unlike what my patch _affords_).

Isn't it as simple as:

dd bs=32 if=/dev/urandom of=/dev/random

?

This is a one-time admin operation and it has to be an explicit choice.

Of course there are other possibilities to manualy transfer or create a
seed at installation time (and as has been noted, there once was a page
in sysinst that offered various ones, but was shot down due to user
interface complexity and overloading novice users with question they
were not expected to be able to answer).

Martin

Re: regarding the changes to kernel entropy gathering

[Greg A. Woods]

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 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'.

I think adding a uprintf(9) that the user who started the blocked
process (i.e. not just the admin) has a better chance of directly seeing
would be one step closer, and should be extremely easy.

--
Greg A. Woods 

Kelowna, BC +1 250 762-7675   RoboHack 
Planix, Inc.  Avoncote Farms 


pgpOvi5MZvUCj.pgp
Description: OpenPGP Digital Signature

Re: regarding the changes to kernel entropy gathering

[Greg A. Woods]

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
randomness (e.g. environmental sensors (including audio), clock skew,
disk rotational latency, etc., even network jitter if there is no other
source) as the initial seed entropy _is_ better, for most situations,
and perhaps for _ALL_ situations where no hardware-RNG is available or
possible.  Better in part because it prevents the brain-dead way of
seeding, but also because it mixes real-world data in an algorithmically
sound way.

> But what you're missing is that neither does what you
> think.  When rndctl -L runs after the system comes up multiuser, all
> entropy samples that have been added (which are in the per-cpu pools)
> are propagated to the global pool.  Every stream RNG on the system then
> rekeys itself - they are _not_ just using the entropy from the seed on
> disk.  Even if nothing does so earlier, when rndctl -S runs as the system
> shuts down, again all entropy samples that have been added (which, again,
> are accumulating in the per-cpu pools) are propagated to the global pool;
> all the stream RNGs rekey themselves again; then the seed is extracted.

That's all great, and more or less what I've assumed from all the
previous discussion

Except it seems to be useless in practice without an initial seed,

And the stock implementation 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_).

So, in all practical ways my two patches together (plus perhaps one or
two other related changes to calls to rnd_attach_source() which don't
currently use RND_FLAG_DEFAULT, such as the one in uvm_page.c), leaves
the default system behaving _exactly_ the same way as before, but for
the fact that now "rndctl -e -d blah" actually does something useful and
doesn't lie about what it has done and the kernel doesn't lie about what
it has been told to do, and in fact entropy can be gathered and used on
systems that don't have hardware RNG devices/instructions.

No change in default security as compared to before the patches.
I.e. the patched system still won't "estimate"/"count" any entropy bits
from any untrusted (non-hardware-RNG) devices.

No less secure than any earlier releases (i.e. from before the entropy
re-tooling) if the admin does decide to gather entropy the old way from
untrusted devices.  (with the caveat that device drivers are no more
aggressive about offering entropy bits to be counted than they should be)

No hacks required for systems without hardware-RNGs -- just a simple
config line in /etc/rc.conf.

No lies from, or apparent bugs in, the kernel.

No other changes required.

> It is neither the case that samples added with a 0 entropy estimate go
> nowhere, nor that they do not add entropy to the seed file such that it
> is _not_ "reusing the same entropy on every boot".

This is good, but, again, useless if there's no seed in the first place.

> If you'd like to propagate samples from the per-CPU pool to the global
> pool and force the stream generators to rekey more often, you can
> sysctl -w kern.entropy.consolidate=1 from cron.

So, are you telling me this should seed the global entropy pool from the
collected samples?  That's not exactly how I've understood it so far.

If so this doesn't seem to do anything whatsoever, no matter how often I
call it, or how long between, or how active the system is, etc., etc.,
etc.  kern.entropy.needed never goes down, /dev/random never unblocks.

17:10 [1.804] # sysctl kern.entropy
kern.entropy.collection = 1
kern.entropy.depletion = 0
kern.entropy.consolidate = -23552
kern.entropy.gather = -23552
kern.entropy.needed = 256
kern.entropy.pending = 0
kern.entropy.epoch = 26
17:10 [1.805] # sysctl -w kern.entropy.consolidate=1
kern.entropy.consolidate: 0 -> 1
17:10 [1.806] # sysctl kern.entropy
kern.entropy.collection = 1
kern.entropy.depletion = 0
kern.entropy.consolidate = -23552
kern.entropy.gather = -23552
kern.entropy.needed = 256
kern.entropy.pending = 0
kern.entropy.epoch = 27
17:10 [1.807] # uptime
 4:57PM  up 23 days, 16:42, 2 users, load averages: 0.01, 0.01, 0.00


BTW, there seems to be a bug somewhere too since when I set it the
change is "0 -> 1", but when I view it the value is always some
incomprehensible meaningless negative number.

# sysctl -M kern.entropy
kern.entropy (1.1260): CTLTYPE_NODE, children 7/8, size 96, flags 
0x0, ver=431
kern.entropy.collection (1.1260.1261): CTLTYPE_BOOL, size 1, flags 
0x70, ver=425
kern.entropy.depletion (1.1260.1262): CTLTYPE_BOOL, size 1, flags 
0x70, ver=426
kern.entropy.consolidate (1.1260.1263): CTLTYPE_INT, size

Re: regarding the changes to kernel entropy gathering

[Greg Troxel]

Thanks - that is useful information.

I think the big point is that the new seed file is generated from
urandom, not from the internal state, so the new seed doesn't leaak
internal state.  The "save entropy" language didn't allow me to conclude
that.

Also, your explanation is about updating, but it doesn't address
generation of a file for the first time.  Presumably that just takes
urandom without the old seed that isn't there and doesn't overwrite the
old seed that isnt' there.

Interestingly, I have a machine running current, running as a dom0
sometimes, and haven't had problems.  I now realize that's only because
the machine had a seed file created under either 7 or 9 (installed 7,
updated to 9, updated to current).  So it has trusted, untrustworthy
entropy (even though surely after all this time some of it must have
been unobserved).


signature.asc
Description: PGP signature

Re: regarding the changes to kernel entropy gathering

[Taylor R Campbell]

> Date: Tue, 06 Apr 2021 07:55:54 -0400
> From: Greg Troxel 
> 
> Thor Lancelot Simon  writes:
> 
> > shuts down, again all entropy samples that have been added (which, again,
> > are accumulating in the per-cpu pools) are propagated to the global pool;
> > all the stream RNGs rekey themselves again; then the seed is extracted.
> 
> It seems obvious to me that "extracting" the seed should be done in such
> a way that the state of the internal rng is still unpredictable from the
> saved seed, even if the state of the newly-booted rng will be
> predictable.  Perhaps by pulling 256 bytes from urandom, perhaps by
> something more direct and then some sort of hash/rekey to get back
> traffic protection.
> 
> Probably this is already done in a way much better thought out than my
> 30s reaction, the man page doesn't really say this, at least that I
> could follow; rndctl -S says "save entropy pool".

`rndctl -L' follows the procedure outlined in

Niels Ferguson, Bruce Schneier, and Tadayoshi Kohno,
_Cryptography Engineering_, Wiley, 2010, Sec. 9.6.2 `Update
Seed File', p. 156

to safely update the seed file.  The procedure is roughly:

1. Load the old seed.
2. Feed the old seed into the kernel.
3. Generate and write a new seed.
4. Erase the old seed if we can.

Some details specific to NetBSD:

- The new seed file is derived by hashing the old seed file together
  with output from /dev/urandom, after consolidating entropy in the
  per-CPU pools.

- The new seed file is written and fsync'd, and then moved into place
  with rename(), and then the old seed file is zero'd and fsync'd
  in-place.

This would be a lot of detail to put in the man page.  But I did add a
note that the file doesn't disclose past secrets -- does that help?

Re: regarding the changes to kernel entropy gathering

[Taylor R Campbell]

> Date: Mon, 05 Apr 2021 10:58:58 +0700
> From: Robert Elz 
> 
> I understand that some people desire highly secure systems (I'm not
> convinced that anyone running NetBSD can really justify that desire,
> but that's beside the point) and that's fine - make the system be able
> to be as secure as possible, just don't require me to enable it, and
> don't make it impossible or even difficuly to disable it - and allow
> some kind of middle ground, just just "perfectly 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 getrandom() is more widely used, e.g. in Python when
you do `import multiprocessing'.

Based on experience over the past year with a meaningful criterion for
_detecting_ potential problems, I don't think that's a useful
mechanism for _reporting_ them, which is why I added several other
mechanisms -- a line in the /etc/security report, an `entropy' knob in
/etc/rc.conf to wait or fail to single-user (default: neither) -- and
proposed to remove the blocking behaviour of getrandom() in favour of
focusing on feedback in system integration:

https://mail-index.netbsd.org/tech-userlevel/2021/01/11/msg012807.html

(main discussion after all the noise starts here:
https://mail-index.netbsd.org/tech-userlevel/2021/01/15/msg012846.html)

But I ran out of steam to continue the discussion at the time.

Re: regarding the changes to kernel entropy gathering

[Taylor R Campbell]

> Date: Mon, 5 Apr 2021 01:16:56 + (UTC)
> From: RVP 
> 
> Then, the issue here is one of predictability. NetBSD doesn't want,
> for extremely valid reason, to incorporate any perturbation sources
> which have been pooh-poohed in the technical literature.

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.

We just don't _count_ these sources for the purpose of detecting and
reporting the potential security problem of low entropy, because we
don't have a good model by which we can confidently claim they are
actually unpredictable to an adversary.

> Or, perhaps statistical tests of the raw in-kernel sources will
> demonstrate exactly why things like timing jitter have been
> pooh-poohed in the literature?

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 well-studied in the literature.

We even try to use something like it by default in NetBSD when nothing
else is available -- we use the periodic hardclock interrupt timer to
sample the CPU cycle counter, in the hope that these clocks are driven
by independent oscillators with some timing jitter.

However, this is a generic mechanism that works on any machine -- and
on some machines, there is no CPU cycle counter so it might fall back
to using the hardclock timer as a substitute, defeating the purpose.
And even if there is a CPU cycle counter, it might be clocked by the
same oscillator as the hardclock timer,   So we conservatively
count the hardclock entropy source as having zero entropy.

Re: regarding the changes to kernel entropy gathering

[Greg Troxel]

Thor Lancelot Simon  writes:

> shuts down, again all entropy samples that have been added (which, again,
> are accumulating in the per-cpu pools) are propagated to the global pool;
> all the stream RNGs rekey themselves again; then the seed is extracted.

It seems obvious to me that "extracting" the seed should be done in such
a way that the state of the internal rng is still unpredictable from the
saved seed, even if the state of the newly-booted rng will be
predictable.  Perhaps by pulling 256 bytes from urandom, perhaps by
something more direct and then some sort of hash/rekey to get back
traffic protection.

Probably this is already done in a way much better thought out than my
30s reaction, the man page doesn't really say this, at least that I
could follow; rndctl -S says "save entropy pool".


signature.asc
Description: PGP signature

Re: regarding the changes to kernel entropy gathering

[nia]

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, 0.00, 0.00
> 16:19 [1.794] # sysctl kern.entropy
> kern.entropy.collection = 1
> kern.entropy.depletion = 0
> kern.entropy.consolidate = -23552
> kern.entropy.gather = -23552
> kern.entropy.needed = 256
> kern.entropy.pending = 0
> kern.entropy.epoch = 24
> 16:19 [1.795] # rndctl -l
> Source Bits Type  Flags
> ipmi0-Temp0 env  estimate, collect, v, t, dv, dt

You should update your rndctl to get my recent changes:

$ priv rndctl -l
Source   Estimated bitsSamples Type   Flags
cgd0  04458546 disk   collect, v, t
/dev/random   0  0 ???collect, v
ld0   0118 disk   collect, v, t
wd0   06160391 disk   collect, v, t
acpibat1-discha   0   5908 power  collect, v, t
acpibat1-charge   0   4212 power  collect, v, t
acpibat0-discha   0   1140 power  collect, v, t
acpibat0-charge   0   1698 power  collect, v, t
[...]
seed256  2 ???estimate, collect, v
rdrand/rdseed   512  1 rngestimate, collect, v

Re: regarding the changes to kernel entropy gathering

[Thor Lancelot Simon]

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:
> > >
> > > 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.
> 
> Sorry, I was eluding to the idea of sticking the following in
> /etc/rc.local as the brain-dead way to work around the problem:
> 
>   echo -n "" > /dev/random
> 
> However I have not yet read and understood enough of the code to know
> if:
> 
>   dd if=/dev/urandom of=/dev/random bs=32 count=1

It's no better.  But what you're missing is that neither does what you
think.  When rndctl -L runs after the system comes up multiuser, all
entropy samples that have been added (which are in the per-cpu pools)
are propagated to the global pool.  Every stream RNG on the system then
rekeys itself - they are _not_ just using the entropy from the seed on
disk.  Even if nothing does so earlier, when rndctl -S runs as the system
shuts down, again all entropy samples that have been added (which, again,
are accumulating in the per-cpu pools) are propagated to the global pool;
all the stream RNGs rekey themselves again; then the seed is extracted.

It is neither the case that samples added with a 0 entropy estimate go
nowhere, nor that they do not add entropy to the seed file such that it
is _not_ "reusing the same entropy on every boot".

If you'd like to propagate samples from the per-CPU pool to the global
pool and force the stream generators to rekey more often, you can
sysctl -w kern.entropy.consolidate=1 from cron.

Re: regarding the changes to kernel entropy gathering

[Greg A. Woods]

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.
>
> 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.

Sorry, I was eluding to the idea of sticking the following in
/etc/rc.local as the brain-dead way to work around the problem:

echo -n "" > /dev/random

However I have not yet read and understood enough of the code to know
if:

dd if=/dev/urandom of=/dev/random bs=32 count=1

is any more "secure" -- I'm guessing (hoping?) it depends on exactly
when this might be run, and also depends on which, if any, other device
sources are enabled for "collecting".  If in some rare case none were
enabled, or if it were run before any were able to "stir the pool", then
I'm guessing it would be no more secure than writing a fixed string.

--
Greg A. Woods 

Kelowna, BC +1 250 762-7675   RoboHack 
Planix, Inc.  Avoncote Farms 


pgpgF42U_yi8i.pgp
Description: OpenPGP Digital Signature

Re: regarding the changes to kernel entropy gathering

[Thor Lancelot Simon]

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.

Re: regarding the changes to kernel entropy gathering

[Greg A. Woods]

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'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, 0.00, 0.00
16:19 [1.794] # sysctl kern.entropy
kern.entropy.collection = 1
kern.entropy.depletion = 0
kern.entropy.consolidate = -23552
kern.entropy.gather = -23552
kern.entropy.needed = 256
kern.entropy.pending = 0
kern.entropy.epoch = 24
16:19 [1.795] # rndctl -l
Source Bits Type  Flags
ipmi0-Temp0 env  estimate, collect, v, t, dv, dt
ipmi0-Temp1   0 env  estimate, collect, v, t, dv, dt
ipmi0-Temp2   0 env  estimate, collect, v, t, dv, dt
ipmi0-Temp3   0 env  estimate, collect, v, t, dv, dt
ipmi0-Ambient-T   0 env  estimate, collect, v, t, dv, dt
ipmi0-Planar-Te   0 env  estimate, collect, v, t, dv, dt
ipmi0-FAN-MOD-1   0 env  estimate, collect, v, t, dv, dt
ipmi0-FAN-MOD-1   0 env  estimate, collect, v, t, dv, dt
ipmi0-FAN-MOD-2   0 env  estimate, collect, v, t, dv, dt
ipmi0-FAN-MOD-2   0 env  estimate, collect, v, t, dv, dt
ipmi0-FAN-MOD-3   0 env  estimate, collect, v, t, dv, dt
ipmi0-FAN-MOD-3   0 env  estimate, collect, v, t, dv, dt
ipmi0-FAN-MOD-4   0 env  estimate, collect, v, t, dv, dt
ipmi0-Status  0 ???  estimate, collect, t, dt
ipmi0-Voltage 0 power estimate, collect, v, t, dv, dt
ipmi0-Voltage10 power estimate, collect, v, t, dv, dt
ipmi0-Status1 0 ???  estimate, collect, t, dt
ipmi0-Intrusion   0 ???  estimate, collect, t, dt
ipmi0-Temp4   0 env  estimate, collect, v, t, dv, dt
ipmi0-Temp5   0 env  estimate, collect, v, t, dv, dt
ipmi0-Temp6   0 env  estimate, collect, v, t, dv, dt
ipmi0-FAN-MOD-4   0 env  estimate, collect, v, t, dv, dt
ipmi0-FAN-MOD-5   0 env  estimate, collect, v, t, dv, dt
ipmi0-FAN-MOD-5   0 env  estimate, collect, v, t, dv, dt
ipmi0-Ambient-T   0 env  estimate, collect, v, t, dv, dt
ipmi0-Ambient-T   0 env  estimate, collect, v, t, dv, dt
ums0  0 tty  estimate, collect, v, t, dt
ukbd0 0 tty  estimate, collect, v, t, dt
/dev/random   0 ???  estimate, collect, v
sd2   0 disk estimate, collect, v, t, dt
sd1   0 disk estimate, collect, v, t, dt
sd0   0 disk estimate, collect, v, t, dt
cpu0  0 vm   estimate, collect, v, t, dv
hardclock 0 skew estimate, collect, t
pckbd00 tty  estimate, collect, v, t, dt
system-power  0 power estimate, collect, v, t, dt
autoconf  0 ???  estimate, collect, t
seed  0 ???  estimate, collect, v
16:19 [1.796] # dd if=/dev/random bs=1 count=1
[ 1970935.9749573] load: 0.00  cmd: dd 14493 [entropy] 0.00u 0.00s 0% 520k
0+0 records in
0+0 records out
0 bytes transferred in 1.839 secs (0 bytes/sec)
[ 1970946.3951782] load: 0.00  cmd: dd 14493 [entropy] 0.00u 0.00s 0% 540k
0+0 records in
0+0 records out
0 bytes transferred in 12.263 secs (0 bytes/sec)
[ 1971074.4681828] load: 0.08  cmd: dd 14493 [entropy] 0.01u 0.01s 0% 540k
0+0 records in
0+0 records out
0 bytes transferred in 140.335 secs (0 bytes/sec)

... and it stays that way for, effectively, ever

After seeing this, on real hardware, I did read the code.  I found a
fix.  It prevents what I show above.

My fix essentially does what you suggested in your other message and
allows the administrator to, on a per-system basis, enable estimation /
counting of entropy bits from any of the available less trusted sources.

My fix might be a bit "aggressive" (even with the accompanying change to
RND_FLAG_DEFAULT), but it does what I need it to do and, if I understand
correctly, it is still far more secure than:

 echo -n "" > /dev/random

I do trust the entropy from my fans and other environmental sources, and
for most of my systems I would also trust the disk and network sources
too, even in VMs.  If you can observe or influence those then you're
probably in my house already and have access to the physical hardware.

Also if I understand correctly the trick of doing "dd if=/dev/urandom
of=/dev/random bs=32 count=1" still suffers the same problem you mention
about non-hardware-RNG devices sources, even with "stirring" from these
same non-hardware-RNG sources:  _when_ should it be done?  When is the
pool stirred enough?  IFF the entropy from non-hardware-RNG sources is
needed to 

Re: regarding the changes to kernel entropy gathering

[Thor Lancelot Simon]

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 such a knob.
> > echo 0123456789abcdef0123456789abcdef > /dev/random
> >
> > will get you back to the state we had in netbsd-9, with (pseudo-)randomness
> > collected from devices.
> 
> Well, no, not quite so much randomness.  Definitely pseudo though!
> 
> My patch on the other hand can at least inject some real randomness into
> the entropy pool, even if it is observable or influenceable by nefarious
> dudes who might be hiding out in my garage.

No.  You are confused.

All those inputs are *already* being injected into the entropy pool.  If you
don't understand that, you need to read the code more.

All echoing crap into /dev/random does is goose the system's entropy estimate
so it will give you the _output_ of the pool when it thought it shouldn't yet.

Thor

Re: regarding the changes to kernel entropy gathering

[Thor Lancelot Simon]

On Sun, Apr 04, 2021 at 01:08:20PM -0700, Greg A. Woods wrote:
> 
> I trust the randomness and in-observability and isolation of the
> behaviour of my system's fans far more than I would trust Intel's RDRAND
> or RDSEED instructions.

I do not.  However, I do differ with Taylor in that 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 inputs and turn
the gain all the way up, then feed that in as entropy samples (we do not
currently have a device driver to do this, but you could from userslace)
I'd make the same argument, since if you don't get all-zeroes, you're then
sampling the amplifier noise.

I also think there is a case to be made for skew sources since measuring
independently sourced clocks against one another is a basic technique in
many hardware RNGs; but I am not sure the one we have is good enough.

It's important to note that most hardware RNG designs *do not* come with
a real physics model alleging to _compute_ their underlying entropy; rather
they come with an explanation in physical terms of where the entropy comes
from, an explanation of how it is sampled (since this can impact the degree
to which samples are truly independent of one another), and _empirically
derived_ estimates of the minimum expected output entropy.  These are usually
obtained by taking the output data prior to any hashing or "whitening" stage
and running specialized statistical tests, compressing it, etc.

I would _personally_ support counting the entropy from environmental sources,
certainly fans but possibly also thermal sensors, if someone wanted to do the
work of characterizing it in a way which is as rigorous as what's done for
commercial RNGs (the Hifn 799x paper on this is a relatively simple worked
example) _and_ empirically general across a wide array of systems.  And I
think the audio thing is worth exploring.

There is also Peter Gutmann's view that what matters is not really what
mathematicians call "entropy" but, really, the work required for an adversary
to predict the output.  This line of thought can lead to very different
views of what bits should count, on a per-system basis; and I think it would
not be wrong to let the system administrator override this with rndctl,
source by source, as previously they could - but the problem remains that
nobody knows _when_ to count such samples and it is very hard to know you
are not overcounting.

Re: regarding the changes to kernel entropy gathering

[Manuel Bouyer]

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 such a knob.
> > echo 0123456789abcdef0123456789abcdef > /dev/random
> >
> > will get you back to the state we had in netbsd-9, with (pseudo-)randomness
> > collected from devices.
> 
> Well, no, not quite so much randomness.  Definitely pseudo though!
> 
> My patch on the other hand can at least inject some real randomness into
> the entropy pool, even if it is observable or influenceable by nefarious
> dudes who might be hiding out in my garage.

As I understand it, once /dev/random has been seeded, randomness
from other devices will be taken into account (with or without your patch).

In your case, /dev/random reads did block because it didn't get
an initial seed.

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--

Re: regarding the changes to kernel entropy gathering

[Greg A. Woods]

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 says it does (from rndctl(8)):

-L  Load saved entropy from file save-file and overwrite it with a
 seed derived by hashing it together with output from /dev/urandom
 so that the new seed has at least as much entropy as either the
 old seed had or the system already has.  If interrupted, either
 the old seed or the new seed will be in place.

The code seems to concur.

Also the system re-saves the $random_file via /etc/security
(unconditionally, i.e. always, but only if $random_file is set).

--
Greg A. Woods 

Kelowna, BC +1 250 762-7675   RoboHack 
Planix, Inc.  Avoncote Farms 


pgpJ2gB7j21GX.pgp
Description: OpenPGP Digital Signature

Re: regarding the changes to kernel entropy gathering

[Greg A. Woods]

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 to all others that I have ever seen. The
> number of times I've logged into systems that have stalled on boot and
> made them finish booting by running "ls -lR /" over the past 20 years
> are too many to count. I don't know if I just needed to wait longer
> for the boot to finish, or if generating entropy was the fix, and I
> will never know. This is nuts.

Indeed!

> We can use the message to point the system administrator to a manual
> page that tells them what to do, and by "tells them what to do", I
> mean in plain simple language, right at the top of the page, without
> scaring them.

Excellent idea!  :-)

However I have been wondering if sending the message just to the
console, and logging it, say in /var/log/kern, is sufficient.

It still took me a very long time to find the existing new message
because I don't hang out on the console -- this is a VM, after all, and
it's running in a city almost exactly 4200km driving distance from me
too!  As-is I feel I hang out on the console more often than the average
admin who doesn't use a physical console, and of course infinitely more
often than any user who doesn't admin his own server.

I have added the following comment to the kernel to remind me to think
more about this, as a uprintf(9) at the same time would pop right up on
the actual user's session too:

--- kern_entropy.c.~1.30.~  2021-03-07 17:23:05.0 -0800
+++ kern_entropy.c  2021-04-03 11:25:31.667067667 -0700
@@ -1306,7 +1306,7 @@

/* Wait for some entropy to come in and try again.  */
KASSERT(E->stage >= ENTROPY_WARM);
-   printf("entropy: pid %d (%s) blocking due to lack of entropy\n",
+   printf("entropy: pid %d (%s) blocking due to lack of 
entropy\n", /* xxx uprintf() instead/also? */
   curproc->p_pid, curproc->p_comm);

if (ISSET(flags, ENTROPY_SIG)) {


--
Greg A. Woods 

Kelowna, BC +1 250 762-7675   RoboHack 
Planix, Inc.  Avoncote Farms 


pgpbil_4h9ofy.pgp
Description: OpenPGP Digital Signature

Re: regarding the changes to kernel entropy gathering

[Greg A. Woods]

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 we had in netbsd-9, with (pseudo-)randomness
> collected from devices.

Well, no, not quite so much randomness.  Definitely pseudo though!

My patch on the other hand can at least inject some real randomness into
the entropy pool, even if it is observable or influenceable by nefarious
dudes who might be hiding out in my garage.

--
Greg A. Woods 

Kelowna, BC +1 250 762-7675   RoboHack 
Planix, Inc.  Avoncote Farms 


pgpdkEisDB6Js.pgp
Description: OpenPGP Digital Signature

Re: regarding the changes to kernel entropy gathering

[Greg A. Woods]

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 rdrand or rdseed feature exposed to domu's by xen.  This
> observation is confirmed by looking at the xen command line reference
> page: https://xenbits.xen.org/docs/unstable/misc/xen-command-line.html

The problem in the domU was really just the very tip of the iceberg.

The dom0 exhibits the exact same problem and for the same reasons.

> and NetBSD doesn't trust the random sources provided by the xennet(4)
> and xbd(4) drivers.  Therefore, the only solution to get randomness
> working for the first time on a newlyinstalled domu is to write 32
> bytes to /dev/random.

It's not that the xbd(4) devices, etc. are not trusted as entropy
sources -- the new entropy system doesn't trust anything, real or
virtual, despite the documentation saying that it can be made to do so.

My patch fixes that bug.  It was very obvious once I understood the root
of the issue.

As a result my patch fixes the bug for Xen dom0 and domU.

Writing randomness to /dev/random is _NOT_ a general solution (though it
could be IFF it can be reliably taken from /dev/urandom AND IFF the rest
of the system and documentation is completely and adequately fixed to
match the new regime).

What perturbs me the most and makes me rather angry is that the rest of
the system, and the system documentation, continued to lie and mislead
me for days (and it didn't help that nobody who knew this was pointing
helpfully and clearly at the root of the problem).  So, my patch ALSO
restores the kernel's behaviour to match the documentation and tools
(specifically rndctl).  That the core of it it is just a two-line patch
makes this fix extremely satisfying.

--
Greg A. Woods 

Kelowna, BC +1 250 762-7675   RoboHack 
Planix, Inc.  Avoncote Farms 


pgpWiXqui7McJ.pgp
Description: OpenPGP Digital Signature

Re: regarding the changes to kernel entropy gathering

[Michael van Elst]

h...@netbsd.org (Havard Eidnes) writes:

>I also presented a workaround for this problem; if you are reasonably
>certain that you actually have mixed in a sufficient number of bits of
>sufficient quality into the randomness pool (see "rndctl -l -v"), you
>can do

Isn't that the same as before? Waiting some time and then assume things
are good enough ?

The difference is that previously it was done automatically based
on some _estimate_ of entropy created by system activity and random
physical processes (even based on thermal noise, that you consider
worthy). And now someone has to manually do this in an obscure way
and has no means to even guess about entropy.

We can surely argue about whether this estimate is correct or precise
and whether it is safe to use. Some people would decide that it's
not good enough and _ignore entropy estimation_ as necessary, just
like we ignored entropy estimation for network devices. In the current
virtualized world I would even agree that it's necessary to ignore many
of the estimates by default.

We could also argue about finding other estimators, just like you would
replace the PRNG if it doesn't meet some standard.

But that's not the point.

That choice was deliberately removed based on crystal clear arguments
like being "unscientific" or "fabulated" or "a lie" or whatever
other mockery words could be found.

And that's why the thread ends here.

Re: regarding the changes to kernel entropy gathering

[Manuel Bouyer]

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 confirmed by looking at the xen command 
> line reference
> page: https://xenbits.xen.org/docs/unstable/misc/xen-command-line.html

Actually, if the CPU supports rdrand or rdseed, they are available
to domUs:
cpu0: Running on hypervisor: Xen
cpu0: "Intel(R) Xeon(R) Silver 4208 CPU @ 2.10GHz"
cpu0: Intel Xeon Scalable (Skylake, Cascade Lake, Copper Lake) (686-class)
cpu0: family 0x6 model 0x55 stepping 0x7 (id 0x50657)
[...]
cpu0: features1 0xf6f81203
cpu0: features2 0x810
cpu0: features5 0xd18f2369

Source Bits Type  Flags
xbd04010273 disk estimate, collect, v, t, dt
xennet0   0 net  v, t, dt
cpu0  88774 vm   estimate, collect, v, t, dv
system-power  0 power estimate, collect, v, t, dt
autoconf  1 ???  estimate, collect, t, dt
printf0 ???  collect
callout 108 skew estimate, collect, v, dv
cpurng 4096 rng  estimate, collect, v


-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--

Re: regarding the changes to kernel entropy gathering

[Manuel Bouyer]

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 appropriate sysinst warnings of course.

If I understood it properly, there's no need for such a knob.
echo 0123456789abcdef0123456789abcdef > /dev/random

will get you back to the state we had in netbsd-9, with (pseudo-)randomness
collected from devices.

-- 
Manuel Bouyer 
 NetBSD: 26 ans d'experience feront toujours la difference
--

Re: regarding the changes to kernel entropy gathering

[Michael van Elst]

h...@uninett.no (Havard Eidnes) writes:

>Well, if I'm not mistaken, the actual implementation was tested,
>not just a theoretical study of the design.  And, as I said,
>thermal noise is one of the well-known physical systems which
>provide actual entropy.

That's probably why other sources of thermal noise are considered are
confabulation.

Re: regarding the changes to kernel entropy gathering

[John Nemeth]

On Apr 4, 23:09, Taylor R Campbell wrote:
} 
} > 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:
} > >
} > > 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 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.
} 
} 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 it.
} 
} But users who don't go messing around with obscure rndctl settings in
} rc.conf will be proverbially shot in the foot by this change -- except
} they won't notice because there is practically guaranteed to be no
} feedback whatsoever for a security disaster until their systems turn
} up in a paper published at Usenix like .

 Or, get a repeat of the Debian weak SSH key debacle when they
screwed up their crypto.  I don't expect NetBSD to withstand an
attack by a nation state actor, but I do expect it to stand up to
a wardialing script kiddie.

}-- End of excerpt from Taylor R Campbell

Re: regarding the changes to kernel entropy gathering

[nia]

On Mon, Apr 05, 2021 at 12:51:44AM +0200, Joerg Sonnenberger wrote:
> On Sun, Apr 04, 2021 at 02:16:41PM -0700, Paul Goyette wrote:
> > 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 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.
> 
> Joerg

Are you sure? AFAIK the estimation is saved inside the entropy file
that gets written on shutdown, and loaded on next boot. If the
estimation was zero, it stays zero, and you get blocking.

Martin had a patch that added a menu to sysinst providing
various options if estimation == 0, but IIRC it was disabled
pending further discussion.

Re: regarding the changes to kernel entropy gathering

[RVP]

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 would be an earthshattering
development in the cryptography literature, which would be hotly
discussed in much more significant forums than NetBSD mailing lists,
and (b) we would stop using this PRNG and switch to another one.



Right. Well, it's been quite a few years since I ran this sort of test
on /dev/*random, and things, obviously, have been fixed. (Back in the
early 2000s, the tests I mentioned turned up their noses at /dev/random
data from the Linux kernel.)

Then, the issue here is one of predictability. NetBSD doesn't want, for
extremely valid reason, to incorporate any perturbation sources which
have been pooh-poohed in the technical literature. But, its /dev/random
is good enough that no statistical tests of randomness will fail it.

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 appropriate sysinst warnings of course.

Or, perhaps statistical tests of the raw in-kernel sources will demonstrate
exactly why things like timing jitter have been pooh-poohed in the
literature?

-RVP

PS: As an aside, I'm perfectly OK with the choices currently made in 9.99:
``if there's any doubt, leave it out''

Re: regarding the changes to kernel entropy gathering

[Lloyd Parkes]

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 or an rng device, and if not then it 
prints a warning and then generates some simplistic entropy with "ls -lR 
/ ; dd if=/dev/urandom of=/dev/random bs=32 count=1 ; sysctl -w 
kern.entropy.consolidate=1". The system owner has been warned and the 
system proceeds to run.


Secondly we could fix what I see as the biggest problem with the new 
implementation that I see right now and that is that it is unreasonably 
difficult for people to work out how to make their system go forwards 
once it has stopped. Note that making the system go forwards is easy, 
it's work out what to do that's hard. We can fix that.


The current implementation prints out a message whenever it blocks a 
process that wants randomness, which immediately makes this 
implementation superior to all others that I have ever seen. The number 
of times I've logged into systems that have stalled on boot and made 
them finish booting by running "ls -lR /" over the past 20 years are too 
many to count. I don't know if I just needed to wait longer for the boot 
to finish, or if generating entropy was the fix, and I will never know. 
This is nuts.


We can use the message to point the system administrator to a manual 
page that tells them what to do, and by "tells them what to do", I mean 
in plain simple language, right at the top of the page, without scaring 
them.


How about this..

"entropy: pid %d (%s) blocking due to lack of entropy, see entropy(4)"

and then in entropy(4) we can start with something like

"If you are reading this because you have read a kernel message telling 
you that a process is blocking due to a lack of entropy then it is 
almost certainly because your hardware doesn't have a reliable source of 
randomness. If you have no particular requirements for cryptographic 
security on your system, you can generate some entropy and then tell the 
kernel that this entropy is 'enough' with the commands

    ls -lR /
    dd if=/dev/urandom of=/dev/random bs=32 count=1
    sysctl -w kern.entropy.consolidate=1
If have strong requirements for cryptographic security on your system 
then you should run 'rndctl -S /root/seed' on a system with hardware 
random number generate (most modern CPUs), copy the seed file over to 
this system as /var/db/entropy-file and then run 'rndctl -L 
/var/db/entropy-file'.


This only needs to be done once since scripts in rc.d will take care of 
saving and restoring system entropy in /var/db/entropy-file across reboots."


We could even do both of these things.

Re: regarding the changes to kernel entropy gathering

[Robert Elz]

Date:Mon, 5 Apr 2021 01:14:01 +0200
From:Joerg Sonnenberger 
Message-ID:  

  | That is discussed in the security model Taylor presented a long time
  | ago. In short: nothing. In most use cases, you are screwed at this point
  | anyway

This is where the disconnect is happening I think.   Many of you are
simply not understanding the point.

I am not screwed, I just don't care.Is that so hard to understand?

Let me make it plainer.

I run systems on which I allow root logins with no password.   I have run
systems where root ssh access is permitted, put those together and you
get root access from over the net (and telnet would allow that as well).

Alternatively I can aim for greater security, and configure a root
password ... like say the system's host name.

NetBSD allows me to do all that - it might not be the standard configuration,
but it is possible.   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 little saner, but equally
as simple to use).

The logic behind that makes no sense to me.

I understand that some people desire highly secure systems (I'm not
convinced that anyone running NetBSD can really justify that desire,
but that's beside the point) and that's fine - make the system be able
to be as secure as possible, just don't require me to enable it, and
don't make it impossible or even difficuly to disable it - and allow
some kind of middle ground, just just "perfectly secure" and "hopeless".

kre

Re: regarding the changes to kernel entropy gathering

[Mouse]

> 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 NetBSD qua NetBSD cannot tell where
between those two extremes any particular case falls.  Compounding this
is that most sysadmins are not competent to accurately describe where a
given install falls, even were NetBSD to provide a means to do so.
(Though I suspect that most who understand the issues could provide a
usefully high lower bound on the entry provided.  For example, I'd be
satisfied with one millibit per event - network packet or disk transfer
- and in my environment I am confident that is an understimate.)

> As I mentioned elsewhere, a lot of the classic entropy sources are
> surprisingly bad nowadays when someone can observe the kernel,
> especially in a virtualized environment.

Yes...but, as gwoods indirectly but correctly pointed out, that may not
matter: other VMs under the same hypervisor can be anywhere from "known
to be actively hostile" to "fully trusted", depending on the site.

/~\ The ASCII Mouse
\ / Ribbon Campaign
 X  Against HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Re: regarding the changes to kernel entropy gathering

[Brian Buhrow]

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: https://xenbits.xen.org/docs/unstable/misc/xen-command-line.html

So, it seems the best answer is to update our documentation to say that 
the xen
hypervisor, by default, doesn't provide the rdrand and rdseed instructions to 
the xen guests
and NetBSD doesn't trust the random sources provided by the xennet(4) and 
xbd(4) drivers.
Therefore, the only solution to get randomness working for the first time on a 
newlyinstalled
domu is to write 32 bytes to /dev/random.
-thanks
-Brian

Re: regarding the changes to kernel entropy gathering

[Joerg Sonnenberger]

On Sun, Apr 04, 2021 at 11:47:10PM +0700, Robert Elz wrote:
> If not, what prevents someone from reading (copying) the file from the
> system while it is stopped (assessing the storage device via other methods)
> and then knowing exactly what the seed is going to be when the system boots?

That is discussed in the security model Taylor presented a long time
ago. In short: nothing. In most use cases, you are screwed at this point
anyway since various other cryptographic material like the host ssh key
is also lost. There is one special case here where this has to be taken
under consideration 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 pool, so any entropy that actually did get
added during the boot process still remains.

> I think I'd prefer possibly insecure, but difficult to obtain from outside
> like disk drive interrupt timing low order bits than that.   Regardless of
> how unproven that method might be.

See above, that's still the case. Noone said anything about not using
sources of potential entropy. All that changed is that we don't pretend
it provides entropy. As I mentioned elsewhere, a lot of the classic
entropy sources are surprisingly bad nowadays when someone can observe
the kernel, especially in a virtualized environment.

Joerg

Re: regarding the changes to kernel entropy gathering

[Joerg Sonnenberger]

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 nothing like RDRAND/RDSEED?  Are
> > > they, effectively, totally 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.
> 
> BTW, to me reusing the same entropy on every reboot seems less secure.

Except that's not what the system is doing. It removes the seed file on
boot and creates a new one on shutdown.

> > Systems without persistent storage and also without RDRAND/RDSEED
> > will however be ... a more challenging problem.
> 
> Leaving things like that would be totally silly.
> 
> With my patch the old way of gathering entropy from devices works just
> fine as it always did, albeit with the second patch it does require a
> tiny bit of extra configuration.

You keep repeating yourself. It doesn't make your claims any less false.
At this point, can we please just stop this thread?

Joerg

Re: regarding the changes to kernel entropy gathering

[RVP]

On Sun, 4 Apr 2021, Greg A. Woods wrote:


At Sun, 4 Apr 2021 09:49:58 +, Taylor R Campbell  
wrote:


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 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 on RDRAND/RDSEED-based and estimator-based as in your
patch) would be useful here.

Binary packages already have the dieharder RNG tester. Then, there
is John Walker's ent for PRNGs: https://fourmilab.ch/random/

NIST has some too, I believe (I can't locate them right now).

-RVP

PS. Is there a way to get the bit-stream from the various in-kernel
sources so that we can run them through these sort of tests? That
way we can check--not intuit--how random the bit-streams they
produce really are.

Re: regarding the changes to kernel entropy gathering

[Joerg Sonnenberger]

On Mon, Apr 05, 2021 at 12:07:49AM +0200, Havard Eidnes wrote:
> I am still of the fairly firm beleif that the mistrust in the
> hardware vendors' ability to make a reasonable and robust
> implementation is without foundation.

It's not without foundation. Remember the first hardware RNG 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

Re: regarding the changes to kernel entropy gathering

[Mouse]

>> 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 "saved and" part of the above.  (I still think it's
misguided, but I don't expect NetBSD to agree.  It's been a long time
since NetBSD and I saw eye to eye on...well, on many points.)

/~\ The ASCII Mouse
\ / Ribbon Campaign
 X  Against HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Re: regarding the changes to kernel entropy gathering

[Mouse]

> I am still of the fairly firm beleif that the mistrust in the
> hardware vendors' ability to make a reasonable and robust
> implementation is without foundation.

I don't doubt the ability.  I don't doubt that they _can_.

I question whether they _do_.  (And, indeed, there has been at 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 the system to consider RDRAND and its ilk same as
any potential other source of entropy: trusted to generate real
unpredictability only when specifically configured that way.  (The
question of what the default should be is a separate one.)

Of course, in a situation like that, I would also want to do all the
relevant processing on CPUs (and, where applicable, other hardware) old
enough to predate the reasons for caring about that level of
unpredictability, because it makes them significantly less likely to
have been trojaned.

/~\ The ASCII Mouse
\ / Ribbon Campaign
 X  Against HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Re: regarding the changes to kernel entropy gathering

[Mansour Moufid]

On Sun, Apr 4, 2021 at 7:14 PM Havard Eidnes  wrote:

> Well.  That depends on what you mean by "entropy".

Hit the nail on the head.

Although there is only one definition of entropy in information theory
/ cryptography, it has different colloquial meanings, especially on
the web. It makes communication impossible and these arguments come up
over and over again...

Anyway, the NetBSD definition and implementation are correct. :)

Re: regarding the changes to kernel entropy gathering

[Greg A. Woods]

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 it.

I don't have random data easily available at install time.

I don't have random data easily available every time I boot a machine
with non-persistent storage (e.g. a test ISO image).

I _do_ trust well enough the sources of randomness in some device
drivers to provide me with a secure enough amount of entropy, for my
purposes.

And so with my fix(es) I don't need to feed supposedly random data to
every system on every install and/or every reboot.

What's worse?  My fixes, or something like this in /etc/rc.local:

   echo -n "" > /dev/random

> But users who don't go messing around with obscure rndctl settings in
> rc.conf will be proverbially shot in the foot by this change -- except
> they won't notice because there is practically guaranteed to be no
> feedback whatsoever for a security disaster until their systems turn
> up in a paper published at Usenix like <https://factorable.net/>.

You're really stretching your argument thinly if you are assuming
everyone _needs_ perfect entropy here.

Also, that's only if the default RND_FLAG_ESTIMATE_* bits are turned off.

AND only if the system doesn't have some true hardware RNG.

> What your change does is equivalent to going around to every device
> driver that previously said `this provides zero entropy, or I don't
> know how much entropy it provides' and replacing that claim by `this
> is a sample of an independent and perfectly uniform random string of
> bits', which is a much stronger (and falser) claim than even the old
> `entropy estimation' confabulation that NetBSD used to do.

No, only if the default RND_FLAG_ESTIMATE_* bits are ***NOT*** turned off.

AND only if the user is like me and stuck with some poor second-grade
ancient hardware that doesn't have some fancy new true hardware RNG.

In the mean time a more productive approach would be to figure out
what's best for those of us who don't need perfection every time and/or
to fix those device drivers that could feed sufficiently random data to
the entropy pool, and then to recommend a suitable value for
rndctl_flags in /etc/rc.conf.

--
Greg A. Woods 

Kelowna, BC +1 250 762-7675   RoboHack 
Planix, Inc.  Avoncote Farms 


pgpnOADtmWrjC.pgp
Description: OpenPGP Digital Signature

Re: regarding the changes to kernel entropy gathering

[Greg A. Woods]

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)
> or other VMs on the same machine (in case of a hypervisor) or local
> machines on the same network (in case of network interrupts).

It _Just_ _Doesn't_ _Matter_  (i.e. for many of us, most of the time).

Now ideally in the hypervisor scenario we would have a backend device
that read from /dev/random and offered it to the VM guest as a virtual
hardware RNG.  Or maybe it's as simple as passing a those few bytes
through a custom Xenstore string and having a script in the VM read them
and inject them into /dev/random.  But that's not been done yet.

BTW, personally, on at least on some machines, I don't have any worry
whatsoever at the moment about one VM guest spying on, or influencing
the PRNG, in another.  Zero worry.  They're all _me_.  I don't need some
theoretically perfect level of protection from myself.

--
Greg A. Woods 

Kelowna, BC +1 250 762-7675   RoboHack 
Planix, Inc.  Avoncote Farms 


pgpFPOplfhwSl.pgp
Description: OpenPGP Digital Signature

Re: regarding the changes to kernel entropy gathering

[Taylor R Campbell]

> Date: Sun, 4 Apr 2021 21:24:56 + (UTC)
> From: RVP 
> 
> I think running the /dev/random bit-stream through some statistical
> tests, (both on RDRAND/RDSEED-based and estimator-based as in your
> patch) would be useful here.

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 would be an earthshattering
development in the cryptography literature, which would be hotly
discussed 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 wherever we can, e.g. to detect the
AMD RDRAND bugs.)

Re: regarding the changes to kernel entropy gathering

[Havard Eidnes]

>> > 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 how much of it there really was.
>
> Clearly there was no entropy being contributed in any way shape or form.

Well.  That depends on what you mean by "entropy".

Samples are still being collected and mixed into the pool from your
listed sources.  By your statement, that should have contributed some
"randomness" into the pool, some might call this "entropy".

However, since the quality of those samples are unknown, and there is
no reliable model to estimate the actual quality of those samples,
they are in NetBSD-current not being counted as contributing to the
"entropy estimate" counter.  That is by design: the entropy estimation
is now quite conservative, as you have noticed.

I also presented a workaround for this problem; if you are reasonably
certain that you actually have mixed in a sufficient number of bits of
sufficient quality into the randomness pool (see "rndctl -l -v"), you
can do

# dd if=/dev/urandom of=/dev/random count=1

since if this is done by root, it counts as the "/dev/random" source,
and the bits fed in there by root are counted 1:1 as contributing to
the entropy estimate.  After this, your system will not block anymore
reading on /dev/random, and this state of affairs will be preserved
across reboots as long as you save and restore the entropy pool on
reboot.  (Which, admittedly, requires r/w storage for the relevant
file/directory, ref. your other ongoing thread.)

> I told the system to "count" the entropy being gathered by the
> appropriate driver(s), but it was being ignored entirely.

Well, you are now counting bitstrings of unknown and perhaps dubious
quality as contributing 1:1 to the "entropy estimate".  It's by design
that we don't do that anymore.

> After my fix the system behaved as I told it to.

But now with perhaps questionable estimation of the actual entropy
sitting in your pool.

Regards,

- Håvard

Re: regarding the changes to kernel entropy gathering

[Taylor R Campbell]

> 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 gathering
> >
> > 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 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.

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 it.

But users who don't go messing around with obscure rndctl settings in
rc.conf will be proverbially shot in the foot by this change -- except
they won't notice because there is practically guaranteed to be no
feedback whatsoever for a security disaster until their systems turn
up in a paper published at Usenix like <https://factorable.net/>.

What your change does is equivalent to going around to every device
driver that previously said `this provides zero entropy, or I don't
know how much entropy it provides' and replacing that claim by `this
is a sample of an independent and perfectly uniform random string of
bits', which is a much stronger (and falser) claim than even the old
`entropy estimation' confabulation that NetBSD used to do.

Re: regarding the changes to kernel entropy gathering

[Joerg Sonnenberger]

On Sun, Apr 04, 2021 at 09:24:56PM +, RVP wrote:
> PS. Is there a way to get the bit-stream from the various in-kernel
> sources so that we can run them through these sort of tests? That
> way we can check--not intuit--how random the bit-streams they
> produce really are.

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)
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 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.

Joerg

Re: regarding the changes to kernel entropy gathering

[Taylor R Campbell]

> Date: Sun, 4 Apr 2021 11:14:31 -0700
> From: John Nemeth 
> 
>  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 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 system
have provided any entropy.  The system generally tries to read from
HWRNGs as soon as possible at boot, so unless something is wrong you
will see such sources listed next to nonzero bits of entropy in
`rndctl -l' as soon as you can run that.

You can grep the code for rnd_add_data and rnd_add_data_sync to find
the drivers that pass nonzero values as the last argument, which is
the number of bits of entropy in the process that generated the sample
being fed in.

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) have RNGs; and there are some dedicated RNG devices like
ualea(4).

Re: regarding the changes to kernel entropy gathering

[Taylor R Campbell]

> Date: Sun, 04 Apr 2021 23:47:10 +0700
> From: Robert Elz 
> 
> Date:Sun, 4 Apr 2021 15:28:13 +
> From:Taylor R Campbell 
> Message-ID:  <20210404152814.3c56360...@jupiter.mumble.net>
> 
>   | you can let NetBSD take care of it automatically
>   | on subsequent boots by running `/etc/rc.d/random_seed stop' to save a
>   | seed to disk.)
> 
> Is that file encrypted?   If it is, where does the decryption key come from?

No.  If the adversary can bypass file system privileges to read (and,
most likely, write) arbitrary 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 entropy since a network
eavesdropper could read it.

(Side note: Disclosure of the _current_ seed file does not enable
retroactive recovery of _past_ secrets generated from /dev/urandom.)

> I think I'd prefer possibly insecure, but difficult to obtain from outside
> like disk drive interrupt timing low order bits than that.   Regardless of
> how unproven that method might be.

The seed is hashed together with disk drive interrupt timings, so you
get security from either or both, along with RDRAND/RDSEED output if
available.  The kernel also uses the hardclock timer to periodically
sample a cycle counter as a makeshift ring oscillator, if nothing else
is available.  Every device listed in `rndctl -l' has the opportunity
to influence the output of /dev/urandom; for security it is enough
that any one of them be adequately unpredictable.

> And what's the scheme for cheap low-end devices that have no
> writable storage?  (The proverbial internet toaster, for example).

If the device has a HWRNG, great.  If not, this may be a difficult
problem for the system engineer designing the device to solve.
There's no free lunch.

> Lastly, why would anyone presume that RDRAND generates less predictable
> bits (less predictable to someone who knows how it works) than any of
> the other methods that are used.

We generally take the vendor's word in hardware documentation about
what's actually behind the device registers, just like we do for any
other device we have a driver for (e.g., we generally expect devices
not to leak the contents of arbitrary RAM across the network).

In the case of Intel RDRAND, the design is documented in

Intel Digital Random Number Generator Software Implementation
Guide, Revision 2.1, October 17, 2019.

https://web.archive.org/web/20190404022757/https://software.intel.com/sites/default/files/managed/98/4a/DRNG_Software_Implementation_Guide_2.1.pdf

The design samples from ring oscillators -- two independently clocked
circuits, one of which rapidly alternates between states and the other
of which periodically samples the first, so the state is determined by
the random timing jitter between the two clocks, influenced by
unpredictable thermal noise in the silicon.  This class of designs is
reasonably well-studied in the literature -- much moreso than, e.g.,
disk seek times or network packet times.

We also incorporate new information about the devices if available.
For example, on certain AMD CPUs, RDRAND and/or RDSEED sometimes gets
into bad states, which the device driver checks for; in this event the
driver counts zero entropy.

We sometimes do a bit of science on the devices too.  See
https://nxr.netbsd.org/xref/src/sys/arch/mips/cavium/dev/octeon_rnm.c
for some notes on the Cavium Octeon HWRNG, and
https://nxr.netbsd.org/xref/src/sys/arch/arm/sunxi/sun8i_crypto.c for
an example of a driver for a thing that might be an OK HWRNG but is
not clearly endorsed by vendor documentation and has a very nonuniform
distribution so we obviously need more than 256 bits of sample
material to get 256 bits of entropy -- but how much more is not clear,
which is why it counts as zero entropy for now.

> 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.

...right

FYI: If you really want, you can stop the kernel from counting any
particular entropy source by setting rndctl_flags in /etc/rc.conf:

rndctl_flags="-E -d rdrand; -E -d rdseed; -E -d rdrand/rdseed; -E -d seed"

Then any attempt to read from /dev/random will block until some other
entropy source has provided enough entropy.

Re: regarding the changes to kernel entropy gathering

[Joerg Sonnenberger]

On Sun, Apr 04, 2021 at 02:16:41PM -0700, Paul Goyette wrote:
> > Personally, I'm happy with anything that your average high school
> > student is unlikely to be able to crack in an hour.   I don't run
> > a bank, or a military installation, and I'm not the NSA.   If someone
> > is prepared to put in the effort required to break into my systems,
> > then let them, it isn't worth the cost to prevent that tiny chance.
> > That's the same way that my house has ordinary locks - I'm sure they
> > can be picked by someone who knows what they're doing, and better
> > security is available, at a price, but a nice happy medium is what
> > fits me best.
> 
> FWIW, I used to work for a company whose marketing motto was
> 
>   Good enough isn't!
> 
> But I definitely agree with you - what we used to have is "good
> 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 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.

Joerg

Re: regarding the changes to kernel entropy gathering

[Greg A. Woods]

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 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.

> Systems without persistent storage and also without RDRAND/RDSEED
> will however be ... a more challenging problem.

Leaving things like that would be totally silly.

With my patch the old way of gathering entropy from devices works just
fine as it always did, albeit with the second patch it does require a
tiny bit of extra configuration.

--
Greg A. Woods 

Kelowna, BC +1 250 762-7675   RoboHack 
Planix, Inc.  Avoncote Farms 


pgpgeBbtqrqWg.pgp
Description: OpenPGP Digital Signature

Re: regarding the changes to kernel entropy gathering

[Greg A. Woods]

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 being counted as contributing to the
> entropy estimate, because the quality of the samples is at best
> unknown.

Perhaps we're talking past each other?

Until I made the fix no amount of time or activity or of me telling the
system to make use of the driver inputs was unblocking getrandom(2) or
/dev/random, so it doesn't really matter if anything was being "mixed
into the pool" so to speak as the pool was empty.

> A possible workaround is, once you have some uptime and some bits
> mixed into the pool, you can do:

I don't need a work-around -- I found a fix.  I corrected some code that
was purposefully ignoring my orders for how it should behave.

> I am still of the fairly firm beleif that the mistrust in the
> hardware vendors' ability to make a reasonable and robust
> implementation is without foundation.

Well there are still millions of systems out there without the fancy
newer hardware RNGs available to make them more secure than Fort Knox.
At least a small handful of them run NetBSD for me, and want them to
work for my needs and I was, and am, quite happy with using entropy that
can be collected from various devices that my systems (virtual and real)
actually have.

--
Greg A. Woods 

Kelowna, BC +1 250 762-7675   RoboHack 
Planix, Inc.  Avoncote Farms 


pgpw8NF4N8YCU.pgp
Description: OpenPGP Digital Signature

Re: regarding the changes to kernel entropy gathering

[Greg A. Woods]

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 contributed.  What wasn't
> happening was the random driver code recognizing and acknowledging that
> entropy, because it had no way to tell how much of it there really was.

Clearly there was no entropy being contributed in any way shape or form.

It wasn't the driver code at fault.

It was the code I fixed with my patch that was at fault.

I told the system to "count" the entropy being gathered by the
appropriate driver(s), but it was being ignored entirely.

After my fix the system behaved as I told it to.

--
Greg A. Woods 

Kelowna, BC +1 250 762-7675   RoboHack 
Planix, Inc.  Avoncote Farms 


pgpKRv3dDs3Kt.pgp
Description: OpenPGP Digital Signature

Re: regarding the changes to kernel entropy gathering

[Havard Eidnes]

>> 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?

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

Re: regarding the changes to kernel entropy gathering

[Havard Eidnes]

>> 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 randomness
>> data once the system has seen a bit of uptime (given that there are
>> actual other sources of (unverified) entropy which aren't all of too
>> low quality).
>
> No amount of uptime and activity was increasing the entropy in my system
> before I patched it.

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 being counted as contributing to the
entropy estimate, because the quality of the samples is at best
unknown.

> The unpatched implementation completely and entirely prevents
> the system from ever using any of those sources, despite
> showing that they are enabled for use.

As far as I know, those samples are still being *used*, but as
said above, not counted as contributing to the entropy count.

A possible workaround is, once you have some uptime and some bits
mixed into the pool, you can do:

% su
# dd if=/dev/urandom of=/dev/random count=1

If you then ensure that the entropy is saved and restored on
reboot, as is typically done, after this initialization, neither
/dev/random nor /dev/urandom will block(!).  Ref. the attachment.

>> Besides, the implementation has been thoroughly vetted.  E.g. the
>> reference [7] from the wikipedia article states in the conclusion on
>> page 20
>>
>>Overall, the Ivy Bridge RNG is a robust design with a large
>>margin of safety that ensures good random data is generated even
>>if the Entropy Source is not operating as well as predicted.
>
> "design" != implementation

Well, if I'm not mistaken, the actual implementation was tested,
not just a theoretical study of the design.  And, as I said,
thermal noise is one of the well-known physical systems which
provide actual entropy.

I am still of the fairly firm beleif that the mistrust in the
hardware vendors' ability to make a reasonable and robust
implementation is without foundation.

Regards,

- Håvard
b# uname -a
NetBSD b.urc.uninett.no 9.99.81 NetBSD 9.99.81 (GENERIC) #0: Sat Apr  3 
23:24:06 UTC 2021  
mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/i386/compile/GENERIC i386
b# rndctl -l
Source Bits Type  Flags
/dev/random   0 ???  estimate, collect, v
wd0   0 disk estimate, collect, v, t, dt
cd0   0 disk estimate, collect, v, t, dt
cpu0  0 vm   estimate, collect, v, t, dv
hardclock 0 skew estimate, collect, t
bge0  0 net  estimate, v, t, dt
system-power  0 power estimate, collect, v, t, dt
autoconf  0 ???  estimate, collect, t
seed256 ???  estimate, collect, v
b# rndctl -s
0 bits mixed into pool
  256 bits currently stored in pool (max 256)
0 bits of entropy discarded due to full pool
0 hard-random bits generated
0 pseudo-random bits generated
b# dd if=/dev/random of=/dev/null count=1024
0+1024 records in
64+0 records out
32768 bytes transferred in 0.021 secs (1560380 bytes/sec)
b# rndctl -s
0 bits mixed into pool
  256 bits currently stored in pool (max 256)
0 bits of entropy discarded due to full pool
0 hard-random bits generated
0 pseudo-random bits generated
b#
b# rndctl -lv
Source Bits Type  Flags
/dev/random   0 ???  estimate, collect, v
Dt samples = 0
Dt bits = 0
Dv samples = 0
Dv bits = 0
wd0   0 disk estimate, collect, v, t, dt
Dt samples = 5559
Dt bits = 0
Dv samples = 5869
Dv bits = 0
cd0   0 disk estimate, collect, v, t, dt
Dt samples = 0
Dt bits = 0
Dv samples = 0
Dv bits = 0
cpu0  0 vm   estimate, collect, v, t, dv
Dt samples = 183
Dt bits = 0
Dv samples = 183
Dv bits = 0
hardclock 0 skew estimate, collect, t
Dt samples = 853
Dt bits = 0
Dv samples = 0
Dv bits = 0
bge0  0 net  estimate, v, t, dt
Dt samples = 0
Dt bits = 0
Dv samples = 0
Dv bits = 0
system-power  0 power estimate, collect, v, t, dt
Dt samples = 0
Dt bits = 0
Dv samples = 0
Dv bits = 0
autoconf  0 ???  estimate, collect, t
Dt samples = 43
Dt bits = 0
Dv samples = 0
Dv bits = 0
seed256 ???  estimate, collect, v
Dt samples = 0
Dt bits = 0
Dv samples = 1
Dv bits = 256
b#

Re: regarding the changes to kernel entropy gathering

[Paul Goyette]

Personally, I'm happy with anything that your average high school
student is unlikely to be able to crack in an hour.   I don't run
a bank, or a military installation, and I'm not the NSA.   If someone
is prepared to put in the effort required to break into my systems,
then let them, it isn't worth the cost to prevent that tiny chance.
That's the same way that my house has ordinary locks - I'm sure they
can be picked by someone who knows what they're doing, and better
security is available, at a price, but a nice happy medium is what
fits me best.


FWIW, I used to work for a company whose marketing motto was

Good enough isn't!

But I definitely agree with you - what we used to have is "good
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 to /dev/rnd
to prevent future blocking.



++--+---+
| Paul Goyette   | PGP Key fingerprint: | E-mail addresses: |
| (Retired)  | FA29 0E3B 35AF E8AE 6651 | p...@whooppee.com |
| Software Developer | 0786 F758 55DE 53BA 7731 | pgoye...@netbsd.org   |
++--+---+

Re: regarding the changes to kernel entropy gathering

[Mouse]

> 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 how much of it there really was.

/~\ The ASCII Mouse
\ / Ribbon Campaign
 X  Against HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Re: regarding the changes to kernel entropy gathering

[Mouse]

> 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 Mouse
\ / Ribbon Campaign
 X  Against HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Re: regarding the changes to kernel entropy gathering

[Greg A. Woods]

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 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
> actual other sources of (unverified) entropy which aren't all of too
> low quality).

No amount of uptime and activity was increasing the entropy in my system
before I patched it.  /dev/random remained blocked after days of busy
system activity.  I would argue that most, if not all, of the sources of
entropy identified by rndctl(8) on my systems are high-quality and
secure sources in my circumstances and for my uses.

Perhaps the unpatched implementation isn't doing exactly what you think
it is?

The unpatched implementation completely and entirely prevents the system
from ever using any of those sources, despite showing that they are
enabled for use.

> However, in the new scheme of things, because most of the
> traditional sources have unknown quality, and we have no reliable
> method to estimate how much "actual entropy" those sources
> provide, they no longer count towards the *estimate* of what is
> now a lower bound on the "real" entropy available in the pool.

It really doesn't matter what can be determined in general and from a
distance.

What matters is what a given administrator can determine in particular
for a given application in a given circumstance.

Before my patch the system was not behaving as documented and could not
be made to behave as the documentation said it could be made to behave.

With my patch I can choose which to trust from amongst the available
sources.  Without that patch my choices are ignored and the system lies
to me about using my choices.  I would argue my patch fixes a critical
bug.

> Besides, the implementation has been thoroughly vetted.  E.g. the
> reference [7] from the wikipedia article states in the conclusion on
> page 20
>
>Overall, the Ivy Bridge RNG is a robust design with a large
>margin of safety that ensures good random data is generated even
>if the Entropy Source is not operating as well as predicted.

"design" != implementation

--
Greg A. Woods 

Kelowna, BC +1 250 762-7675   RoboHack 
Planix, Inc.  Avoncote Farms 


pgpjs3QaPXmot.pgp
Description: OpenPGP Digital Signature

Re: regarding the changes to kernel entropy gathering

[Greg A. Woods]

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.

Indeed, I concur.

I trust the randomness and in-observability and isolation of the
behaviour of my system's fans far more than I would trust Intel's RDRAND
or RDSEED instructions.

I even trust the randomness of the timings of the virtual disks in my
Xen domU virtual machines more-so, even with multiple sibling guests,
even if some of those other guests can be influenced by untrusted third
parties at critical times.

> Personally, I'm happy with anything that your average high school
> student is unlikely to be able to crack in an hour.   I don't run
> a bank, or a military installation, and I'm not the NSA.   If someone
> is prepared to put in the effort required to break into my systems,
> then let them, it isn't worth the cost to prevent that tiny chance.
> That's the same way that my house has ordinary locks - I'm sure they
> can be picked by someone who knows what they're doing, and better security
> is available, at a price, but a nice happy medium is what fits me best.

Indeed again.

--
Greg A. Woods 

Kelowna, BC +1 250 762-7675   RoboHack 
Planix, Inc.  Avoncote Farms 


pgpvuqMttwSyI.pgp
Description: OpenPGP Digital Signature

Re: regarding the changes to kernel entropy gathering

[Greg A. Woods]

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 create a long-lived
> > situation where the system documentation and the behaviour and actions
> > of system commands is completely out of sync with the behaviour of the
> > kernel, and in fact lies to the administrator about the abilities of the
> > system.
>
> It would help if you could identify specifically what you are calling
> a lie.
>
> > @@ -1754,21 +1766,21 @@
> >  rnd_add_uint32(struct krndsource *rs, uint32_t value)
> >  {
> >
> > -   rnd_add_data(rs, , sizeof value, 0);
> > +   rnd_add_data(rs, , sizeof value, sizeof value * ABBY);
> >  }
>
> The rnd_add_uint32 function is used by drivers to feed in data from
> sources _with no known model for their entropy_.

Indeed -- that's the idea.

> It's how drivers
> toss in data that might be helpful but might totally predictable, and
> the driver has no way to know.

Yeah, so?  They don't need to know this.  I'm not actually asking random
drivers to decide the amount of physical entropy they can collect.
That is controlled elsewhere.

> 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 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.

An addition change, one which I would also find totally acceptable,
would be to disable the current default of allowing "estimation" on
devices which are not true hardware RNGs.  I.e. maybe this simple change
would suffice (though I haven't checked beyond a quick grep to see that
this flag is the mostly commonly used one -- perhaps some real RNG
devices could also be changed to use explicit flags to enable estimation
by default):

--- sys/sys/rndio.h.~1.2.~  2016-07-23 14:36:45.0 -0700
+++ sys/sys/rndio.h 2021-04-04 12:39:15.609936311 -0700
@@ -91,8 +91,7 @@
 #define RND_FLAG_ESTIMATE_TIME 0x4000  /* estimate entropy on time */
 #define RND_FLAG_ESTIMATE_VALUE0x8000  /* estimate entropy on 
value */
 #defineRND_FLAG_HASENABLE  0x0001  /* has enable/disable 
fns */
-#define RND_FLAG_DEFAULT   (RND_FLAG_COLLECT_VALUE|RND_FLAG_COLLECT_TIME|\
-RND_FLAG_ESTIMATE_TIME)
+#define RND_FLAG_DEFAULT   (RND_FLAG_COLLECT_VALUE|RND_FLAG_COLLECT_TIME)

 #defineRND_TYPE_UNKNOWN0   /* unknown source */
 #defineRND_TYPE_DISK   1   /* source is physical disk */


There are a vast number of ways this re-tooling of entropy collection
could have been done better.

I'm asking for discussion on what amount to some VERY simple changes
which completely and totally solve many real-world uses of this code
while at the same time not just allowing, but defaulting to, the very
strict and secure operation for special situations.

--
Greg A. Woods 

Kelowna, BC +1 250 762-7675   RoboHack 
Planix, Inc.  Avoncote Farms 


pgpXj_p1tBVqr.pgp
Description: OpenPGP Digital Signature

Re: regarding the changes to kernel entropy gathering

[Havard Eidnes]

> Is that file encrypted?

As I understand it, no.

> I think I'd prefer possibly insecure, but difficult to obtain from outside
> like disk drive interrupt timing low order bits than that.   Regardless of
> how unproven that method might be.

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 randomness
data once the system has seen a bit of uptime (given that there are
actual other sources of (unverified) entropy which aren't all of too
low quality).

However, in the new scheme of things, because most of the
traditional sources have unknown quality, and we have no reliable
method to estimate how much "actual entropy" those sources
provide, they no longer count towards the *estimate* of what is
now a lower bound on the "real" entropy available in the pool.

> Lastly, why would anyone presume that RDRAND generates less predictable
> bits (less predictable to someone who knows how it works) than any of
> the other methods that are used.

Looking at

  https://en.wikipedia.org/wiki/RDRAND

and the reference [3] at

  
http://software.intel.com/sites/default/files/m/d/4/1/d/8/441_Intel_R__DRNG_Software_Implementation_Guide_final_Aug7.pdf

reveals that the on-chip entropy source samples thermal noise on
the chip, ref. page 12 where it says:

   The Entropy Source runs asynchronously on a self-timed circuit
   and uses thermal noise within the silicon to output a random
   stream of bits at the rate of 3GHz.

That bitstream is then fed through a "AES-CBC-MAC" based
conditioner and an AES-CTR based deterministic random bit
generator, before the result is given to the user via RDRAND.

If I'm not very much mistaken, thermal noise is one of the well-
known physical sources of actual entropy.

Besides, the implementation has been thoroughly vetted.  E.g. the
reference [7] from the wikipedia article states in the conclusion on
page 20

   Overall, the Ivy Bridge RNG is a robust design with a large
   margin of safety that ensures good random data is generated even
   if the Entropy Source is not operating as well as predicted.

Personally, I as a non-expert can't find anything which seems
overly worrisome with RDRAND.

Best regards,

- Håvard

Re: regarding the changes to kernel entropy gathering

[Martin Husemann]

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 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 | fgrep RDRAND
cpu0: features1 0x7ffafbff
# cpuctl identify 0 | fgrep RDSEED
cpu0: features5 0x29c6fbf
# rndctl -l
Source Bits Type  Flags
[..]
system-power  0 power estimate, collect, v, t, dt
autoconf  0 ???  estimate, collect, t
seed256 ???  estimate, collect, v
rdrand/rdseed   512 rng  estimate, collect, v


or on a system with another cpu:

# rndctl -l
Source Bits Type  Flags
[..]
ualea0  512 rng  estimate, collect, v
[..]
system-power  0 power estimate, collect, v, t, dt
autoconf  0 ???  estimate, collect, t
seed256 ???  estimate, collect, v


and yet another with no trusted source, but properly seeded (also an
old and non-x86 system):

# rndctl -l
Source Bits Type  Flags
/dev/random   0 ???  estimate, collect, v
ucom7 0 tty  estimate, collect, v, t, dt
ucom6 0 tty  estimate, collect, v, t, dt
ucom5 0 tty  estimate, collect, v, t, dt
ucom4 0 tty  estimate, collect, v, t, dt
ucom3 0 tty  estimate, collect, v, t, dt
ucom2 0 tty  estimate, collect, v, t, dt
ucom1 0 tty  estimate, collect, v, t, dt
ucom0 0 tty  estimate, collect, v, t, dt
sd1   0 disk estimate, collect, v, t, dt
sd0   0 disk estimate, collect, v, t, dt
cpu0  0 vm   estimate, collect, v, t, dv
hardclock 0 skew estimate, collect, t
mvgbe00 net  estimate, v, t, dt
system-power  0 power estimate, collect, v, t, dt
autoconf  0 ???  estimate, collect, t
seed256 ???  estimate, collect, v


Martin

Re: regarding the changes to kernel entropy gathering

[Thomas Klausner]

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 RDRAND/RDSEED?  Are there other sources that can
> be positively identified as providing randomness?

That should do it:

# cpuctl identify 0 | grep -e RDRAND -e RDSEED 
cpu0: features1 0x7ed8320b
cpu0: features5 0x209c01a9

 Thomas

Re: regarding the changes to kernel entropy gathering

[John Nemeth]

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 important as system security and
} integrity' you might prefer to hear about this rather than have it
} swept under the rug.

 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 RDRAND/RDSEED?  Are there other sources that can
be positively identified as providing randomness?

}-- End of excerpt from Taylor R Campbell

Re: regarding the changes to kernel entropy gathering

[Robert Elz]

Date:Sun, 4 Apr 2021 15:28:13 +
From:Taylor R Campbell 
Message-ID:  <20210404152814.3c56360...@jupiter.mumble.net>

  | you can let NetBSD take care of it automatically
  | on subsequent boots by running `/etc/rc.d/random_seed stop' to save a
  | seed to disk.)

Is that file encrypted?   If it is, where does the decryption key come from?

If not, what prevents someone from reading (copying) the file from the
system while it is stopped (assessing the storage device via other methods)
and then knowing exactly what the seed is going to be when the system boots?

I think I'd prefer possibly insecure, but difficult to obtain from outside
like disk drive interrupt timing low order bits than that.   Regardless of
how unproven that method might be.

And what's the scheme for cheap low-end devices that have no writable storage?
(The proverbial internet toaster, for example).

Lastly, why would anyone presume that RDRAND generates less predictable
bits (less predictable to someone who knows how it works) than any of
the other methods that are used.   After all, all the chips are more or
less identical, what about them can absolutely guarantee unpredictable
data (a very rare thing for computers) and how can anyone be certain
that it has been correctly implemented without any bugs?

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.

Personally, I'm happy with anything that your average high school
student is unlikely to be able to crack in an hour.   I don't run
a bank, or a military installation, and I'm not the NSA.   If someone
is prepared to put in the effort required to break into my systems,
then let them, it isn't worth the cost to prevent that tiny chance.
That's the same way that my house has ordinary locks - I'm sure they
can be picked by someone who knows what they're doing, and better security
is available, at a price, but a nice happy medium is what fits me best.

kre

Re: regarding the changes to kernel entropy gathering

[Taylor R Campbell]

> Date: Sun, 4 Apr 2021 10:40:22 -0400 (EDT)
> From: Mouse 
> 
> > 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 --
> 
> Not quite.  That there is nothing which NetBSD, independent of the
> sysadmin, is confident is a reliable source of entropy.
> 
> It's entirely possible one or more of those sources actually does
> supply usable entropy, but NetBSD doesn't realize that (and, as I
> understand it, provides no way for the sysadmin to fix that, short of
> hacking on the source).

If the sysadmin knows something NetBSD doesn't, it is easy for the
sysadmin to convince NetBSD to unblock by writing 32 bytes to
/dev/random as root.  No need to hack any source.

(This shouldn't be an automatic recipe, though, because it depends on
specific knowledge of the system in question which the authors of the
device drivers and the rest of the software didn't know.  And if you
have done that once, you can let NetBSD take care of it automatically
on subsequent boots by running `/etc/rc.d/random_seed stop' to save a
seed to disk.)

Re: regarding the changes to kernel entropy gathering

[Mouse]

> 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 --

Not quite.  That there is nothing which NetBSD, independent of the
sysadmin, is confident is a reliable source of entropy.

It's entirely possible one or more of those sources actually does
supply usable entropy, but NetBSD doesn't realize that (and, as I
understand it, provides no way for the sysadmin to fix that, short of
hacking on the source).

/~\ The ASCII Mouse
\ / Ribbon Campaign
 X  Against HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Re: regarding the changes to kernel entropy gathering

[nia]

I have updated the rndctl(8) documentation so it reflects the current
model in the kernel and is no longer misleading.

It could still use some extra work (e.g. -l could print number of
samples collected).

On Sat, Apr 03, 2021 at 10:03:21PM +0200, Steffen Nurpmeso wrote:
> Btw i track 
> 
>   https://github.com/smuellerDD/jitterentropy-library.git
> 
> for about two years, and i "never" (which is a couple of years at
> least) understood why something like this isn't simply used.

The kernel already mixes in hardclock jitter, among other things,
to the entropy pool, but it doesn't increase the entropy estimate.
Nothing does except hardware RNGs and direct entropy fed from the
host machine, and there have been strong objections to re-introducing
any kind of estimator that is based purely on runtime statistical
gathering rather than models of hardware.

"Potential entropy gathering schemes" have been discussed to 
death. Please stay on-topic.

Re: regarding the changes to kernel entropy gathering

[Taylor R Campbell]

> Date: Sat, 03 Apr 2021 12:24:29 -0700
> From: "Greg A. Woods" 
> 
> Updating a system, even on -current, shouldn't create a long-lived
> situation where the system documentation and the behaviour and actions
> of system commands is completely out of sync with the behaviour of the
> kernel, and in fact lies to the administrator about the abilities of the
> system.

It would help if you could identify specifically what you are calling
a lie.

> @@ -1754,21 +1766,21 @@
>  rnd_add_uint32(struct krndsource *rs, uint32_t value)
>  {
> 
> - rnd_add_data(rs, , sizeof value, 0);
> + rnd_add_data(rs, , sizeof value, sizeof value * NBBY);
>  }

The rnd_add_uint32 function is used by drivers to feed in data from
sources _with no known model for their entropy_.  It's how drivers
toss in data that might be helpful but might totally predictable, and
the driver has no way to know.

Your change _creates_ the lie that every bit of data entered this way
is drawn from a source with independent uniform distribution.

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 important as system security and
integrity' you might prefer to hear about this rather than have it
swept under the rug.

What your patch does is shoot yourself in the foot by fantasizing that
_every_ source using rnd_add_uint32, even if it predictably always
supplies all-zero bits, has the maximum entropy possible.

Re: regarding the changes to kernel entropy gathering

[Steffen Nurpmeso]

Btw i track 

  https://github.com/smuellerDD/jitterentropy-library.git

for about two years, and i "never" (which is a couple of years at
least) understood why something like this isn't simply used.
For example in the myriads of times the scheduler runs each
second, a little bit of that can be done on pretty compact local
data.

Quite honestly speaking, this random and bits-worth shit always
annoyed me, not being mathematician, as most terrible pseudo
chatter.  Incorporating things like rdtsc with applied intermixing
etc. to pimpen an entropy that as such is never revealed in order,
not to talk about only serving bytes generated through it by
cryptographical checked digest algorithms.  I at least always
mixed low-order/high-order bits.  Wow.

Yes it is unscientific.  But whereas the new OpenSSL RNG
mysteriously can fail (which it never did in the past), the Linux
kernel now uses a pretty simple (last i looked) such wait-and-mix
thing to overcome the seeding-blocks problem.  So i (who still
uses random-entropy devastating Python Mailman to serve minor MLs)
have to use haveged, which, whereas the kernel with the I/O, the
network, the process starts, the mapping( addresse)s, the (VM host
served) timers etc., generates a bit of random in a second (or
something like that, last i looked), generates thousands and
thousands of bits of entropy at a glance.  That is sick.

Hopping off,

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)