[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#31268: 'guix system vm-image' hangs
From: |
Ludovic Courtès |
Subject: |
bug#31268: 'guix system vm-image' hangs |
Date: |
Tue, 22 May 2018 18:23:35 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) |
Hello!
(+Cc: Leo for randomness input.)
address@hidden (Ludovic Courtès) skribis:
> Clément Lassieur <address@hidden> skribis:
>
>> Mark H Weaver <address@hidden> writes:
>
> [...]
>
>>> I suggest doing a git bisect on the 4.16.y branch of the linux-stable
>>> git repository, between the 4.16.3 and 4.16.4 tags.
>>
>> I did it, here is the result:
>
> Impressive, thanks a lot! Did you have a script to do that or
> something?
>
>> cd8d7a5778a4abf76ee8fe8f1bfcf78976029f8d is the first bad commit
>> commit cd8d7a5778a4abf76ee8fe8f1bfcf78976029f8d
>> Author: Theodore Ts'o <address@hidden>
>> Date: Wed Apr 11 13:27:52 2018 -0400
>>
>> random: fix crng_ready() test
>>
>> commit 43838a23a05fbd13e47d750d3dfd77001536dd33 upstream.
>>
>> The crng_init variable has three states:
>>
>> 0: The CRNG is not initialized at all
>> 1: The CRNG has a small amount of entropy, hopefully good enough for
>> early-boot, non-cryptographical use cases
>> 2: The CRNG is fully initialized and we are sure it is safe for
>> cryptographic use cases.
>>
>> The crng_ready() function should only return true once we are in the
>> last state. This addresses CVE-2018-1108.
>
> What happens I think is that libparted/fs/r/fat/fat.c:fat_create calls
> ‘generate_random_uint32’, which in turn indirectly calls
> ‘get_random_bytes’ from libuuid (package ‘e2fsprogs’). And I suppose
> that’s where it blocks, even though it’s supposed to be using
> /dev/urandom, which is not supposed to block.
I was looking at the wrong code: we’re using libuuid from util-linux,
which in turn uses getrandom(2). Since it doesn’t pass the
GRND_NONBLOCK flag, it ends up blocking forever because too little
entropy is available in the VM.
The following patches work around that:
1. Parted now explicitly uses getrandom(2) with GRND_NONBLOCK instead
of libuuid’s ‘uuid_generate’, which is good enough for this
purpose. I’ll submit it upstream.
2. e2fsprogs is changed to use a libuuid that passes GRND_NONBLOCK.
It does the job, but it’s quite inelegant.
Another approach I looked at was to seed the VM’s PRNG from /dev/hwrng,
which I thought was connected to the host via ‘virtio-rng-pci’, but I
get ENODEV while trying to read from /dev/hwrng in the guest like this:
diff --git a/gnu/system/vm.scm b/gnu/system/vm.scm
index b6561dfc7..3bfd6b4ca 100644
--- a/gnu/system/vm.scm
+++ b/gnu/system/vm.scm
@@ -319,6 +319,18 @@ the image."
(set-path-environment-variable "PATH" '("bin" "sbin") inputs)
+ ;; Try writing from /dev/hwrng into /dev/urandom.
+ ;; It seems that the file /dev/hwrng always exists, even
+ ;; when there is no hardware random number generator
+ ;; available. So, we handle a failed read or any other error
+ ;; reported by the operating system.
+ (let ((buf (call-with-input-file "/dev/hwrng"
+ (lambda (hwrng)
+ (get-bytevector-n hwrng 512)))))
+ (call-with-output-file "/dev/urandom"
+ (lambda (urandom)
+ (put-bytevector urandom buf))))
+
(let* ((graphs '#$(match inputs
(((names . _) ...)
names)))
Am I missing something, Leo?
In short, we’re almost done with this bug, now we just need to make sure
we have a reasonable fix.
Thanks,
Ludo’.
0003-gnu-e2fsprogs-Use-libuuid-with-non-blocking-random.patch
Description: Text Data
0001-gnu-parted-Use-weak-non-blocking-randomness-for-FAT-.patch
Description: Text Data
0002-vm-Use-a-deterministic-file-system-UUID-in-shared-st.patch
Description: Text Data