Bug#923675: Add related bug #916690 info

[Petter Reinholdtsen]

[Ben Hutchings]
> haveged or jitterentropy-rngd are likely to be better.

Is there any hope to run them within d-i in Buster before /target/ is
set up?

-- 
Happy hacking
Petter Reinholdtsen

Bug#923675: Add related bug #916690 info

[Cyril Brulebois]

Ben Hutchings  (2019-04-16):
> On Tue, 2019-04-16 at 13:57 +0200, Petter Reinholdtsen wrote:
> > [Ben Hutchings]
> > > This is a pretty terrible approach.  Especially as the world has moved
> > > on to SSDs and they provide very little entropy from interrupts.
> > 
> > Absolutely.  But it has solved the  problem with too little entropy since 
> > 2011.
> > Do you have any better ways to force the kernel to add some entropy when 
> > running
> > low?
> 
> haveged or jitterentropy-rngd are likely to be better.

The former was on my list of things to try; thanks for mentioning the latter.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#923675: Add related bug #916690 info

[Ben Hutchings]

On Tue, 2019-04-16 at 13:57 +0200, Petter Reinholdtsen wrote:
> [Ben Hutchings]
> > This is a pretty terrible approach.  Especially as the world has moved
> > on to SSDs and they provide very little entropy from interrupts.
> 
> Absolutely.  But it has solved the  problem with too little entropy since 
> 2011.
> Do you have any better ways to force the kernel to add some entropy when 
> running
> low?

haveged or jitterentropy-rngd are likely to be better.

Ben.

-- 
Ben Hutchings
Make three consecutive correct guesses and you will be considered
an expert.



signature.asc
Description: This is a digitally signed message part

Bug#923675: Add related bug #916690 info

[Thorsten Glaser]

Daniel Lange dixit:

> Thorsten Glaser (CC) has produced a prototype early-rng-init-tools (cf.
> https://lists.debian.org/debian-devel/2019/02/msg00327.html) which could be
> extended to try reading entropy off the network when it doesn't have a
> carried-over seed (as in the Debian Installer case).

Sorry, this is deliberately out of scope.

My early-rng-init-tools is exactly for the use case of carrying a random
seed between boots and making it available to the system earlier (as a
stopgap until all bootloaders support passing it to the kernel before
the latter is even run) and *deliberately* does not touch the part where
entropy is collected.

FWIW, downloading entropy can be done (we have this in the MirBSD
installer) but has privacy concerns, so it should perhaps be optional.
This is easily done in d-i components, except for the little fact that
busybox wget in d-i lacks https support.

I’ve built myself a locally patched 'monolith' installer with extra
entropy over the network, but that’s site-dependent.

Also, please don’t assume everyone has amd64. The m68k people will,
among others, thank you ;-)

bye,
//mirabilos
--  
When he found out that the m68k port was in a pretty bad shape, he did
not, like many before him, shrug and move on; instead, he took it upon
himself to start compiling things, just so he could compile his shell.
How's that for dedication. -- Wouter, about my Debian/m68k revival

Bug#923675: Add related bug #916690 info

[Petter Reinholdtsen]

[Ben Hutchings]
> This is a pretty terrible approach.  Especially as the world has moved
> on to SSDs and they provide very little entropy from interrupts.

Absolutely.  But it has solved the  problem with too little entropy since 2011.
Do you have any better ways to force the kernel to add some entropy when running
low?

-- 
Happy hacking
Petter Reinholdtsen

Bug#923675: Add related bug #916690 info

[Ben Hutchings]

On Tue, 2019-04-16 at 12:19 +0200, Petter Reinholdtsen wrote:
> Debian Edu ran into this problem when installing Kerberos as a server from 
> d-i, 
> and solved it by running a process in the background to monitor the entropy 
> level, 
> and when it was running low, it would flush the file buffers and run 'find 
> /target' to force some IO operations that would add entropy to the kernel.
[...]

This is a pretty terrible approach.  Especially as the world has moved
on to SSDs and they provide very little entropy from interrupts.

Ben.

-- 
Ben Hutchings
Make three consecutive correct guesses and you will be considered
an expert.



signature.asc
Description: This is a digitally signed message part

Bug#923675: Add related bug #916690 info

[Petter Reinholdtsen]

Debian Edu ran into this problem when installing Kerberos as a server from d-i, 
and solved it by running a process in the background to monitor the entropy 
level, 
and when it was running low, it would flush the file buffers and run 'find 
/target' to force some IO operations that would add entropy to the kernel.

The code can be found in
https://salsa.debian.org/debian-edu/debian-edu-config/blob/master/share/debian-edu-config/d-i/finish-install
 >
and look like this:


# Try to add entropy when running low
(
   cd /
   while true ; do
   entropy="$(cat /proc/sys/kernel/random/entropy_avail)"
   if [ 130 -gt "$entropy" ] ; then
   log "low on entropy, pool is $entropy. trying to add more"
   # Disk IO add entropy to the kernel.  Flush cache to ensure find and 
   # touch/rm causes disk IO.
   sync
   echo 3 > /proc/sys/vm/drop_caches
   find /target > /dev/null || true
   touch /target/var/tmp/foo
   sync
   rm /target/var/tmp/foo
   sync
   entropy="$(cat /proc/sys/kernel/random/entropy_avail)"
   log "entropy pool is $entropy after trying to add"
   fi
   sleep 20
   done ) < /dev/null 2>&1 3>/dev/null 4>&3 5>&3 6>&3 | logger -t 
edu-entropy-add 
& epid=$!

... install stuff ...

# Ignore errors in case the entropy gathering is no longer running
if kill $epid ; then
:
else
log "error: killing the entropy gathering job failed - exited?"
fi

Perhaps a similar approach could be inserted into the default Debian Installer?

-- 
Happy hacking
Petter Reinholdtsen

Bug#923675: Add related bug #916690 info

[Daniel Lange]

This is related to #916690.

getrandom() essentially blocks during many use cases where the system
does not have enough entropy. This is somewhat mitigated by the Debian 
kernel now trusting the RDRAND (CONFIG_RANDOM_TRUST_CPU) for AMD64 
(https://lists.debian.org/debian-devel/2019/02/msg00170.html) which has 
this CPU instruction on somewhat recent hardware. Other architectures 
and a number of virtualization setups on AMD64 are still running into 
this issue.


The Debian Installer variant of this issue is the hardest* to solve.
So I fear we're in "add it to the release notes"-land again.

For Bullseye (or a point release) we should solve the problem more 
comprehensively.


* The Debian Installer media cannot have a (carried over consecutive 
boots) seed file embedded. This makes it the hardest case to solve as 
one needs to "reach out" for entropy sources.
Downloading some random bytes from {random.org | random.debian.org} and 
feeding to the entropy pool proper (ioctl RNDADDENTROPY) would solve 
this for networked hosts, able to reach such an external entropy source. 
Of course there is an attack vector added by reaching out to the net. So 
this would need proper configurability to make it safe to use. Note: we 
cannot use cryptography to protect this ... the PRNG is the very thing 
in need of proper initialization here.
And for non-network hosts or ones shielded from the Internet and not run 
in a proper data center environment (that would probably supply a 
random.the-hoster.tld service) this will not improve the situation.


Thorsten Glaser (CC) has produced a prototype early-rng-init-tools (cf. 
https://lists.debian.org/debian-devel/2019/02/msg00327.html) which could 
be extended to try reading entropy off the network when it doesn't have 
a carried-over seed (as in the Debian Installer case).