From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthias Brugger Date: Thu, 16 May 2019 17:13:35 +0200 Subject: [U-Boot] [PATCH 4/4] lib: uuid: Improve randomness of uuid values on RANDOM_UUID=y In-Reply-To: <88881bd3-772b-9cd7-5ae1-d411fd3e17f6@gmx.de> References: <20190430025347.3097-1-erosca@de.adit-jv.com> <20190430025347.3097-5-erosca@de.adit-jv.com> <88881bd3-772b-9cd7-5ae1-d411fd3e17f6@gmx.de> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: u-boot@lists.denx.de On 30/04/2019 21:07, Heinrich Schuchardt wrote: > On 4/30/19 4:53 AM, Eugeniu Rosca wrote: >> The random uuid values (enabled via CONFIG_RANDOM_UUID=y) on our >> platform are always the same. Below is consistent on each cold boot: >> >>   => ### interrupt autoboot >>   => env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc >>   ... >>   uuid_gpt_misc=d117f98e-6f2c-d04b-a5b2-331a19f91cb2 >>   => env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc >>   ... >>   uuid_gpt_misc=ad5ec4b6-2d9f-8544-9417-fe3bd1c9b1b3 >>   => env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc >>   ... >>   uuid_gpt_misc=cceb0b18-39cb-d547-9db7-03b405fa77d4 >>   => env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc >>   ... >>   uuid_gpt_misc=d4981a2b-0478-544e-9607-7fd3c651068d >>   => env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc >>   ... >>   uuid_gpt_misc=6d6c9a36-e919-264d-a9ee-bd00379686c7 >> >> While the uuids do change on every 'gpt write' command, the values >> appear to be taken from the same pool, in the same order. >> >> As a user, I expect a trully random uuid value in the above example. >> Otherwise, system/RFS designers and OS people might assume they have >> a reliable/consistent uuid passed by the bootloader, while the truth >> is U-Boot simply lacks entropy to generate a random string. >> >> In its first attempt [1] to improve the uuid randomness, this patch >> updated the seed based on the output of get_timer(), similar to [2]. >> >> There are two problems with this approach: >>   - get_timer() has a poor _ms_ resolution >>   - when gen_rand_uuid() is called in a loop, get_timer() returns the >>     same result, leading to the same seed being passed to srand(), >>     leading to the same uuid being generated for several partitions >>     with different names >> >> This second patch addresses both drawbacks. >> >> My R-Car3 testing [3] consists of running 'gpt write mmc 1 $partitions' >> in a loop for several minutes collecting 8844 randomly generated UUIDS. >> Two consecutive cold boots are concatenated in the log. As a result, >> all uuid values are unique (scripted check). >> >> Thanks to Roman, who reported the issue and provided support in fixing. >> >> [1] https://patchwork.ozlabs.org/patch/1091802/ >> [2] commit da384a9d7628 ("net: rename and refactor eth_rand_ethaddr() function") >> [3] https://gist.github.com/erosca/2820be9d554f76b982edd48474d0e7ca >>   => while true; do \ >>      env default -a; \ >>      gpt write mmc 1 $partitions; \ >>      print; done >> >> Reported-by: Roman Stratiienko >> Signed-off-by: Eugeniu Rosca > > This patch may ameliorate the situation for GUIDs a bit. But I dislike: > > - This patch is a uuid only solution to introduce time ticks as source >   of entropy. > - With timer ticks you possibly introduce very little entropy. > - Our random number generator with only 32 state bits remains >   sub-standard. > > This is the current situation: > > net/bootp.c uses the MAC address to seed the random number generator and > uses random numbers for defining waits. > > lib/uuid.c is using it for UUID generation. > > In the UEFI sub-system I would like to implement the EFI_RNG_PROTOCOL. > Linux uses it for randomizing memory layout. iPXE needs it for secure > network connections. This requires a good random number generator with > sufficient entropy. > > We already have implemented a single hardware random number generator in > drivers/crypto/ace_sha.c (CONFIG_EXYNOS_ACE_SHA). > > Many other CPUs come with a hardware random number generator. In Linux's > drivers/char/hw_random/ I found, e.g. > > - meson-rng.c (Amlogic) > - mtk-rng.c (MediaTek) > - st-rng.c (STMicroelectronics) > - imx-rng.c (Freescale) > > I think we should have a u-class for hardware RNGs as one source of entropy. > Anyone working on this already? If not I can have a look. It could be used for RPi3 as well (drivers/char/hw_random/bcm2835-rng.c in the Linux kernel). :) Regards, Matthias > I would like a random number generator with a high number of state bits > (> 127) that we initialize with hardware RNG bits and other sources of > entropy. A nice discussion of how Linux does it can be found in [1]. > > Best regards > > Heinrich > > [1] > https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/LinuxRNG/LinuxRNG_EN.pdf > > > >> --- >> v2: >>   - Replaced get_timer(0) with get_ticks() and added rand() to seed value >>   - Performed extensive testing on R-Car3 (ARMv8) >> v1: >>   - https://patchwork.ozlabs.org/patch/1091802/ >> --- >>   lib/uuid.c | 2 ++ >>   1 file changed, 2 insertions(+) >> >> diff --git a/lib/uuid.c b/lib/uuid.c >> index fa20ee39fc32..2d4d6ef7e461 100644 >> --- a/lib/uuid.c >> +++ b/lib/uuid.c >> @@ -238,6 +238,8 @@ void gen_rand_uuid(unsigned char *uuid_bin) >>       unsigned int *ptr = (unsigned int *)&uuid; >>       int i; >> >> +    srand(get_ticks() + rand()); >> + >>       /* Set all fields randomly */ >>       for (i = 0; i < sizeof(struct uuid) / sizeof(*ptr); i++) >>           *(ptr + i) = cpu_to_be32(rand()); >> > > _______________________________________________ > U-Boot mailing list > U-Boot at lists.denx.de > https://lists.denx.de/listinfo/u-boot