Issue Report

Bug

Container Linux Version

$ cat /etc/os-release
NAME="Container Linux by CoreOS"
ID=coreos
VERSION=1758.0.0+2018-04-25-2334
VERSION_ID=1758.0.0
BUILD_ID=2018-04-25-2334
PRETTY_NAME="Container Linux by CoreOS 1758.0.0+2018-04-25-2334 (Rhyolite)"
ANSI_COLOR="38;5;75"
HOME_URL="https://coreos.com/"
BUG_REPORT_URL="https://issues.coreos.com"
COREOS_BOARD="amd64-usr"

Environment

QEMU

Expected Behavior

First boot proceeds normally.

Actual Behavior

First boot blocks for an extended time on disk-uuid@.service and verity-setup.service. Typing random keys on the keyboard allows boot to proceed.

Reproduction Steps

1. Boot.

Other Information

Kernels 4.14.36 and 4.16.4 include a patch (coreos/linux@cd8d7a5) to fix CVE-2018-1108. This patch causes getrandom(2) and /dev/urandom to block until the crng is initialized, indicated byrandom: crng init done in dmesg.

On first boot, disk-uuid@00000000-0000-0000-0000-000000000001.service runs to randomize the boot disk's GUID, and it in turn is sequenced before verity-setup.service. The randomization is accomplished via sgdisk --disk-guid=R, which generates a GUID by calling uuid_generate() from util-linux's libuuid, which in turn makes a blocking getrandom(2) call. As a result, the entire boot blocks until sufficient entropy is available.

util-linux/util-linux@a9cf659, included in util-linux 2.32, causes libuuid to fall back to lower-quality entropy if the system entropy pool is not yet initialized. This should fix the problem.

Re the kernel behavior change, upstream's position is that userspace needs to stop depending on entropy early in boot. For now, we've worked around this issue by reverting the kernel patches for CVE-2018-1108. Updating to util-linux 2.32 would fix this particular service and may allow boot to proceed normally, but it's possible that some other service (perhaps a user-configured one) may still depend on entropy and block the boot.