[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: |
Fri, 18 May 2018 18:39:41 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) |
Hi!
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.
To be continued…
Ludo’.