Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #65569 > unrolled thread

Dropping haveged from the installer

Back to article view | Back to linux.debian.kernel

Contents

  Dropping haveged from the installer Ben Hutchings <ben@decadent.org.uk> - 2019-11-07 20:10 +0100
    Re: Dropping haveged from the installer Cyril Brulebois <kibi@debian.org> - 2019-11-07 22:40 +0100
      Re: Dropping haveged from the installer Ben Hutchings <ben@decadent.org.uk> - 2019-11-09 23:00 +0100
        Re: Dropping haveged from the installer Cyril Brulebois <kibi@debian.org> - 2020-03-14 08:20 +0100
          Re: Dropping haveged from the installer Ben Hutchings <ben@decadent.org.uk> - 2020-03-15 20:20 +0100
            Re: Dropping haveged from the installer Cyril Brulebois <kibi@debian.org> - 2020-03-16 04:40 +0100

#65569 — Dropping haveged from the installer

[Multipart message — attachments visible in raw view] — view raw

Linux 5.4 introduces an in-kernel jitter-entropy implementation for
systems without a usable hardware RNG, which should remove the need for
haveged.

We could possibly cherry-pick that change on to 5.3, to avoid the need
for further changes to haveged packaging.

Ben.

-- 
Ben Hutchings
Logic doesn't apply to the real world. - Marvin Minsky

[toc] | [next] | [standalone]

#65571

[Multipart message — attachments visible in raw view] — view raw

Hi Ben,

Ben Hutchings <ben@decadent.org.uk> (2019-11-07):
> Linux 5.4 introduces an in-kernel jitter-entropy implementation for
> systems without a usable hardware RNG, which should remove the need for
> haveged.
> 
> We could possibly cherry-pick that change on to 5.3, to avoid the need
> for further changes to haveged packaging.

Oh, great.

Feel free to either follow-up on this bug report once you have
backported it to 5.3, or alternatively once 5.4 trunk has reached
experimental, so that the switch away from haveged can be tested.


Cheers,
-- 
Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

[toc] | [prev] | [next] | [standalone]

#65596

[Multipart message — attachments visible in raw view] — view raw

On Thu, 2019-11-07 at 22:36 +0100, Cyril Brulebois wrote:
> Hi Ben,
> 
> Ben Hutchings <ben@decadent.org.uk> (2019-11-07):
> > Linux 5.4 introduces an in-kernel jitter-entropy implementation for
> > systems without a usable hardware RNG, which should remove the need for
> > haveged.
> > 
> > We could possibly cherry-pick that change on to 5.3, to avoid the need
> > for further changes to haveged packaging.
> 
> Oh, great.
> 
> Feel free to either follow-up on this bug report once you have
> backported it to 5.3, or alternatively once 5.4 trunk has reached
> experimental, so that the switch away from haveged can be tested.

This is included in 5.3.9-1, which is currently building.

Ben.

-- 
Ben Hutchings
Everything should be made as simple as possible, but not simpler.
                                                      - Albert Einstein

[toc] | [prev] | [next] | [standalone]

#66538

[Multipart message — attachments visible in raw view] — view raw

Hey,

Ben Hutchings <ben@decadent.org.uk> (2019-11-09):
> > Ben Hutchings <ben@decadent.org.uk> (2019-11-07):
> > > Linux 5.4 introduces an in-kernel jitter-entropy implementation
> > > for systems without a usable hardware RNG, which should remove the
> > > need for haveged.
> > > 
> > > We could possibly cherry-pick that change on to 5.3, to avoid the
> > > need for further changes to haveged packaging.
> > 
> > Oh, great.
> > 
> > Feel free to either follow-up on this bug report once you have
> > backported it to 5.3, or alternatively once 5.4 trunk has reached
> > experimental, so that the switch away from haveged can be tested.
> 
> This is included in 5.3.9-1, which is currently building.

I know it's been available for a while, but merging this right before
D-I Bullseye Alpha 2 feels a little wrong.

Anyway, to get the ball rolling, I've performed some tests to see how it
would go. I've tried dropping haveged-udeb from pkg-lists and that seems
to be working fine: there are no obvious delays with either the
all-HTTPS scenario or the encrypted LVM one. I'm seeing the “random:
crng init done” message after 23 or 52 seconds respectively, likely when
the first entropy-needing operations are happening. Can you confirm this
is the expected behaviour?

Next, I might try disabling the fc-cache trick at build time to see if
the kernel-level mechanism makes that a moot point as well (I would
assume it does, but I'd like to double check: this is happening rather
early in the boot sequence).

  https://debamax.com/blog/2018/05/25/debugging-black-screen-in-debian-installer/
  https://salsa.debian.org/installer-team/debian-installer/commit/59e1a9af0ce29da7afb55aecce6d54094c3f214f


Cheers,
-- 
Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

[toc] | [prev] | [next] | [standalone]

#66541

[Multipart message — attachments visible in raw view] — view raw

On Sat, 2020-03-14 at 08:13 +0100, Cyril Brulebois wrote:
[...]
> Anyway, to get the ball rolling, I've performed some tests to see how it
> would go. I've tried dropping haveged-udeb from pkg-lists and that seems
> to be working fine: there are no obvious delays with either the
> all-HTTPS scenario or the encrypted LVM one. I'm seeing the “random:
> crng init done” message after 23 or 52 seconds respectively, likely when
> the first entropy-needing operations are happening. Can you confirm this
> is the expected behaviour?
[...]

Yes, that's what I would expect.

However: I've just run a test where the initramfs script reads one byte
of /dev/random then reports the time and relevant log messages.  On
5.5, with random.trust_cpu=N, it still hangs for many minutes. 
Eventually I stopped waiting and pressed keys, and that un-stuck it. 
So I think the in-kernel entropy generator might not be reliable (yet).

Ben.

-- 
Ben Hutchings
Humour is the best antidote to reality.

[toc] | [prev] | [next] | [standalone]

#66543

[Multipart message — attachments visible in raw view] — view raw

Ben Hutchings <ben@decadent.org.uk> (2020-03-15):
> On Sat, 2020-03-14 at 08:13 +0100, Cyril Brulebois wrote:
> [...]
> > Anyway, to get the ball rolling, I've performed some tests to see
> > how it would go. I've tried dropping haveged-udeb from pkg-lists and
> > that seems to be working fine: there are no obvious delays with
> > either the all-HTTPS scenario or the encrypted LVM one. I'm seeing
> > the “random: crng init done” message after 23 or 52 seconds
> > respectively, likely when the first entropy-needing operations are
> > happening. Can you confirm this is the expected behaviour?
> [...]
> 
> Yes, that's what I would expect.
> 
> However: I've just run a test where the initramfs script reads one
> byte of /dev/random then reports the time and relevant log messages.
> On 5.5, with random.trust_cpu=N, it still hangs for many minutes.
> Eventually I stopped waiting and pressed keys, and that un-stuck it.
> So I think the in-kernel entropy generator might not be reliable
> (yet).

OK, I'll postpone the change then, and keep haveged-udeb for now. Feel
free to let us/me know when you think this is reliable enough for us to
implement the suggested change.

Thanks!


Cheers,
-- 
Cyril Brulebois (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web