Re: [OE-core] [PATCH] rng-tools: move to meta-oe

[Randy MacLeod <randy.macleod@windriver.com>]

[-- Attachment #1: Type: text/plain, Size: 4127 bytes --]

On 2024-01-15 4:50 p.m., Scott Murray wrote:
> On Mon, 15 Jan 2024, Randy MacLeod via lists.openembedded.org wrote:
>
>> On 2024-01-15 11:58 a.m., Alexandre Belloni via lists.openembedded.org wrote:
>>> This is breaking meta-agl-core until this gets into meta-oe:
>>>
>>> https://autobuilder.yoctoproject.org/typhoon/#/builders/120/builds/3849/steps/14/logs/stdio
>> Thanks Alexandre.
>>
>>
>> Stephane, Jan-Simon,
>>
>> Is rng-tools actually still a requirement for meta-agl ?
>> It was added back in 2018 but the kernel algorithm improved as of 5.6:
>> https://lists.openembedded.org/g/openembedded-core/message/178518
> The kernel no longer blocking does mean things won't get stuck on boot,
> but it seems like any distro with an eye towards security still needs
> either rngd or haveged present to feed in entropy on hardware that does
> not have a hardware RNG (and potentially even when there is a hardware
> RNG to improve the quality of the pool).  We definitely support some
> platforms in AGL that do not have a hardware RNG, so we'll have to work
> out whether we're going to need to eat making meta-oe a hard requirement
> for using meta-agl-core or do something else.

For anyone who missed it...

We restored rng-tools in oe-core as described here:
https://git.openembedded.org/openembedded-core/commit/?id=828afafb3bff54079fcba9bdab2ec87ac13e4ce6


Scott,

Any news on a qemu/HW boot test case?

Testing randomness is a little different as described in my notes below.
If anyone has some expertise in this area, please help!


There are a few tests in rng-tools, that could be wrapped in ptest:
❯ ls tests/
Makefile.am  rngtestjitter.sh  rngtesturandom.sh  rngtestzero.sh

I haven't played with rngtest much but I was wondering how we'd even 
construct a test of randomness that would *always* pass.

The example below shows that if you run runtest with a blockcount of 
10,000, and do that 10 times, you get failures some of the time:

❯ for i in `seq 10`; do cat /dev/urandom | rngtest -c 10000 --pipe 2>&1 
 >/dev/null |rg failures; done
rngtest: FIPS 140-2 failures: 6
rngtest: FIPS 140-2 failures: 5
rngtest: FIPS 140-2 failures: 9
rngtest: FIPS 140-2 failures: 4
rngtest: FIPS 140-2 failures: 6
rngtest: FIPS 140-2 failures: 8
rngtest: FIPS 140-2 failures: 9
rngtest: FIPS 140-2 failures: 11
rngtest: FIPS 140-2 failures: 9
rngtest: FIPS 140-2 failures: 5


We could say that we accept up to 20 failures but even then, there would 
be a chance that the YP AB would
occasionally see that fail due the the inherit randomness being tested.

If I run the test 1000 times  you can see that on my laptop (6.6.10), 20 
failures never happens:
❯ cut -d":" -f3 /tmp/rt.log | sort -n | uniq -c
       3  1
       7  2
      34  3
      54  4
     101  5
     131  6
     138  7
     124  8
     114  9
     101  10
      75  11
      48  12
      36  13
      16  14
      10  15
       6  16
       1  17
       1  19

and on an older headless server running 5.15 with fewer process and 
likely less entropy available:
       2  1
      12  2
      29  3
      60  4
      95  5
     117  6
     133  7
     121  8
     139  9
      99  10
      81  11
      50  12
      28  13
      14  14
       9  15
       5  16
       4  17
       2  20


I guess we could raise the limit to ~30 (42!) and failures would be 
extremely unlikely.

We would have a similar problem with measuring the boot time that is 
dependent on the entropy pool not being depleted
since we can't completely rule out a boot sequence taking 3x as long as 
the average time
and it would be worse in qemu given that it's competing with other 
processes on the YP AB machines!

../Randy "It's a good day because I made some graphs to understand a 
problem."  MacLeod



>
> Scott
>

-- 
# Randy MacLeod
# Wind River Linux

[-- Attachment #2.1: Type: text/html, Size: 7159 bytes --]

[-- Attachment #2.2: v6jmaP3xqLBLr8JU.png --]
[-- Type: image/png, Size: 19258 bytes --]