Project

General

Profile

Bug #15681

Check getrandom() status and potential problems

Added by intrigeri about 1 year ago. Updated about 1 year ago.

Status:
Resolved
Priority:
Elevated
Assignee:
-
Category:
-
Target version:
Start date:
06/23/2018
Due date:
% Done:

100%

Feature Branch:
Type of work:
Research
Blueprint:
Starter:
Affected tool:

Description

Look into potential regressions caused by the getrandom() fix for https://security-tracker.debian.org/tracker/CVE-2018-1108.

Related bugs (some mostly as examples, but some have fixes we might want):


Related issues

Related to Tails - Bug #15622: Upgrade to Linux 4.16+ in Tails 3.9 Resolved 05/28/2018
Related to Tails - Feature #15319: Grow system partition during boot when started from USB Resolved 10/16/2018
Related to Tails - Feature #15317: Randomize disk GUID of USB image during boot Resolved 02/17/2018
Blocks Tails - Feature #15334: Core work 2018Q3: Foundations Team Resolved 02/20/2018

History

#1 Updated by intrigeri about 1 year ago

#2 Updated by intrigeri about 1 year ago

  • Related to Bug #15622: Upgrade to Linux 4.16+ in Tails 3.9 added

#3 Updated by intrigeri about 1 year ago

  • Related to Feature #15319: Grow system partition during boot when started from USB added

#4 Updated by intrigeri about 1 year ago

  • Related to Feature #15317: Randomize disk GUID of USB image during boot added

#5 Updated by intrigeri about 1 year ago

  • Description updated (diff)
  • Status changed from Confirmed to In Progress

I've compared boot time between devel and 3.8 (tested in the same VM, with no virtio-rng device). The test suite runs in about the same time (and it enables no virtio-rng device either). devel takes ~10% longer to boot from syslinux to the Greeter; this minor difference might be explained away by an outdated SquashFS sort file (not very convincing though). In all my tests I've been careful not to use input devices, which could skew the results by making the rng init faster.

FTR on devel, I see the "random: crng init done" message in the Journal as soon as haveged has started, i.e. ~15s after the kernel was loaded; immediately after that, the "Show Plymouth Boot Screen" service is started. This matches the time when I see the Plymouth splash screen appear but may be purely coincidental as the splash screen is shown at the exact same time on stable.

So at first glance, we're not affected. Given haveged was mentioned as a possible workaround for this problem, I guess it's what saves us here.

It might be interesting to test if applying https://salsa.debian.org/debian/plymouth/commit/3f818f2f3e8ccf5789f53a293f0eb439733704a4#567819342d86b4fd114233c980808d6fb7281046_108_110 on devel changes anything to boot time but at this point, I'm inclined to just close this ticket as resolved and spend my time on actual problems instead :)

#6 Updated by intrigeri about 1 year ago

  • Description updated (diff)

#7 Updated by CyrilBrulebois about 1 year ago

  • Status changed from In Progress to Resolved

I've just read through your conclusions, and they look rather solid to me.

I was about to mention the fc-cache thing in plymouth[*] that could help, but as you mentioned, having haveged kick in during the boot sequence should make sure we don't hit this issue in practice.

As you mentioned, if we have timings reported by test suite, and if they don't double or so all of a sudden, there's not much to fix; it we get such a behaviour later on, we already know where we should start digging…

Marking as resolved accordingly.

[*] I had to borrow for use in the debian-installer build, to avoid similar issues. We were getting a black screen until many fontconfig timeouts happen, due to the font cache getting built at run-time, which leverages getrandom(), retries a few times with a delay before falling back to using /dev/*random. (I should follow up on https://debamax.com/blog/2018/05/25/debugging-black-screen-in-debian-installer/ by the way. ;))

#8 Updated by intrigeri about 1 year ago

  • Assignee deleted (intrigeri)
  • % Done changed from 0 to 100
  • QA Check set to Pass

Also available in: Atom PDF