linux-kernel - Re: [PATCH v2 0/2] Fix missing entropy on Zynq arch due to get

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f20bbd62-db3d-d0e0-aa28-888bdbbd4f9a@xilinx.com>
Date:   Tue, 27 Apr 2021 16:19:20 +0200
From:   Michal Simek <michal.simek@...inx.com>
To:     Andrea Merello <andrea.merello@...il.com>, <tglx@...utronix.de>,
        <daniel.lezcano@...aro.org>
CC:     Patrice Chotard <patrice.chotard@...com>,
        <linux-kernel@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        Michal Simek <michal.simek@...inx.com>,
        Sören Brinkmann <soren.brinkmann@...inx.com>
Subject: Re: [PATCH v2 0/2] Fix missing entropy on Zynq arch due to
 get_cycles() not supported

Hi,

On 4/6/21 3:00 PM, Andrea Merello wrote:
> Changes wrt v1:
>  - rebased on latest kernel tree
>  - fix cover letter: does -> doesn't
> 
> A real-world problem has been seen with a Zynq-based board running
> Debian 10, where ssh daemon takes a really long time to come up at boot.
> This is due to lack of random numbers.
> 
> Since commit 50ee7529ec450 ("random: try to actively add entropy rather
> than passively wait for it") we try to generate entropy whenever we are
> in short of random numbers and someone needs them.
> 
> This trick works only when CPU cycle counter is available. On ARM this
> means that get_cycles() works and in turn read_current_timer() works.
> 
> Zynq HW includes two "cadence TTC" timers and the "ARM global timer".
> All these pieces of HW are fed by the CPU clock, which dynamically
> changes whenever CPU frequency scaling is enabled.
> 
> In timer-cadence-ttc driver this scenario is handled by looking at parent
> clock changes and adjusting things when required. This is the only usable
> clocksource when CPU frequency scaling is in use. arm_global_timer driver
> is disabled in Kconfig when CPU_FREQ is enabled for Zynq arch.
> 
> Unfortunately timer-cadence-ttc driver doesn't register itself via
> register_current_timer_delay() and that ultimately ends up in get_cycles()
> to always return zero, causing the aforementioned lack of entropy problem.
> I believe that the reason for this is because Cadence TTC counter on Zynq
> silicon is only 16-bit wide.
> 
> This patchset works around this by implementing in ARM global timer driver
> a mechanism to compensate for parent clock variations, similarly to what
> it's done in Cadence TTC timer driver, so that it can be used together
> with CPU frequency scaling on Zynq arch.
> 
> This proved to finally fix the problem on my Zynq-based Z-turn board.
> 
> Signed-off-by: Andrea Merello <andrea.merello@...il.com>
> Cc: Patrice Chotard <patrice.chotard@...com>
> Cc: linux-kernel@...r.kernel.org
> Cc: linux-arm-kernel@...ts.infradead.org
> Cc: Michal Simek <michal.simek@...inx.com>
> Cc: Sören Brinkmann <soren.brinkmann@...inx.com>
> 
> Andrea Merello (2):
>   clocksource: arm_global_timer: implement rate compensation whenever
>     source clock changes
>   arm: zynq: don't disable CONFIG_ARM_GLOBAL_TIMER due to
>     CONFIG_CPU_FREQ anymore
> 
>  arch/arm/mach-zynq/Kconfig             |   2 +-
>  drivers/clocksource/Kconfig            |  14 +++
>  drivers/clocksource/arm_global_timer.c | 122 +++++++++++++++++++++++--
>  3 files changed, 127 insertions(+), 11 deletions(-)
> 
> --
> 2.17.1
> 

I have no problem with these patches. I have tested it on zc706 board
and I see performance improvement when I generate random numbers.

Only question what I have is if ARM_GT_INITIAL_PRESCALER_VAL=2 make
sense also for others SoC with multi_v7_defconfig.

Other than this feel free to add my
Acked-by: Michal Simek <michal.simek@...inx.com>
Tested-by: Michal Simek <michal.simek@...inx.com> (on Zynq)

Daniel: Can you please take a look at this series?

Thanks,
Michal