Re: [OE-core] [PATCH] rng-tools: disable the CPU affinity mask

["Mikko Rapeli" <mikko.rapeli@bmw.de>]

Hi,

On Mon, May 10, 2021 at 02:23:02PM +0100, Jack Mitchell wrote:
> On 10/05/2021 10:48, Richard Purdie wrote:
> > On Mon, 2021-05-10 at 10:33 +0800, Yu, Mingli wrote:
> >> From: Mingli Yu <mingli.yu@windriver.com>
> >>
> >> For the jitter entropy source, each task thread will create an internal
> >> counter timer thread when the system clock resolution is under 5MHz.
> >>
> >> But it will introduce high cpu usage for a long time and also make random
> >> data generate too slow if sets the CPU affinity mask of the internal counter
> >> timer thread.
> >>
> >> There is no solution until now and the Upstream recommends to disable
> >> the internal timer and think Jitter RNG will not work due to the coarse
> >> timer. Check [1] and [2] for more details.
> >>
> >> So disable the CPU affinity mask as a workaround to avoid lots of context
> >> switch and too high cpu load for a long time.
> >>
> >> [1] https://github.com/smuellerDD/jitterentropy-library/issues/37
> >> [2] https://github.com/nhorman/rng-tools/pull/123
> >>
> >> Signed-off-by: Mingli Yu <mingli.yu@windriver.com>
> >> ---
> >>  ...tter.c-disable-the-CPU-affinity-mask.patch | 48 +++++++++++++++++++
> >>  .../rng-tools/rng-tools_6.11.bb               |  1 +
> >>  2 files changed, 49 insertions(+)
> >>  create mode 100644 meta/recipes-support/rng-tools/rng-tools/0001-rngd_jitter.c-disable-the-CPU-affinity-mask.patch
> > 
> > Thanks for investigating this upstream. From an OE-Core perspective, I've very
> > reluctant to take what looks like a very board specific change which the upstream
> > is advising against. The issue is that this will affect all hardware, not just
> > the hardware which has the issue. I think we need to find a better solution.
> > 
> > Cheers,
> > 
> > Richard
> > 
> 
> FWIW I forcefully have to ensure nothing pulls in rng-tools in my builds
> which are for two different Rockchip chipsets (armv7 and armv8) as the
> rng-tools binary pegs the CPU at 100% for minutes after boot, every
> boot. It's particularly annoying as openssh brings it in by default
> which I've unsuccessfully argued is wrong before. I believe the problem
> is probably fairly widespread but just unnoticed.

Unfortunately this is better than not having ssh, TLS etc encrypted access
at all to/from the target HW since openssl and kernel refuse to proceed
due to lack of entropy.

If your HW has random number generators and driver support is in place,
then rng-tools isn't needed.

Cheers,

-Mikko