linux-kernel - [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-next>] [day] [month] [year] [list]

Message-Id: <20210406130045.15491-1-andrea.merello@gmail.com>
Date:   Tue,  6 Apr 2021 15:00:43 +0200
From:   Andrea Merello <andrea.merello@...il.com>
To:     tglx@...utronix.de, daniel.lezcano@...aro.org
Cc:     Andrea Merello <andrea.merello@...il.com>,
        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: [PATCH v2 0/2] Fix missing entropy on Zynq arch due to get_cycles() not supported

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