linux-kernel - Re: [PATCH 1/2] hwrng: add driver for MediaTek TRNG SMC

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: <84de90f5-da77-d3f2-c14a-d2e5c53bbf1c@collabora.com>
Date:   Thu, 16 Feb 2023 11:03:58 +0100
From:   AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>
To:     Daniel Golle <daniel@...rotopia.org>,
        Sean Wang <sean.wang@...iatek.com>,
        Olivia Mackall <olivia@...enic.com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        Matthias Brugger <matthias.bgg@...il.com>,
        Conor Dooley <conor.dooley@...rochip.com>,
        Mingming Su <Mingming.Su@...iatek.com>,
        linux-crypto@...r.kernel.org, linux-mediatek@...ts.infradead.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] hwrng: add driver for MediaTek TRNG SMC

Il 15/02/23 14:27, Daniel Golle ha scritto:
> Add driver providing kernel-side support for the Random Number
> Generator hardware found on Mediatek SoCs which have a driver in ARM
> TrustedFirmware-A allowing Linux to read random numbers using a
> non-standard vendor-defined Secure Monitor Call.
> 
> Signed-off-by: Daniel Golle <daniel@...rotopia.org>

Hello Daniel,

incidentally, I've also done some research on this one some months ago, when
I was deep in adding support for the Helio X10 SoC (MT6795) on Xperia M5.

The rng-v2 is simply the same rng but hypervised by the TF-A... and the only
difference is, well, as you're also pointing out, that we're using secure
monitor calls instead of direct MMIO handling.

There's also not much more than what you've implemented here and the only kind
of addition that we will ever see on this one will be about changing the SIP
command (as some older SoCs use a different one)... so...

...I don't think that adding an entirely new driver is worth the noise, hence
I propose to simply add handling for the Secure RNG to mtk-rng.c instead: it's
shorter and we would only need to address one if branch on that probe function
to set a different callback.

The clock should then be optional for *some* of those "v2 handling" devices,
as if I recall correctly, some do need the clock to be handled from Linux
anyway... otherwise this v2 driver will be "soon" looking bloody similar to
the "v1", adding a bit of code duplication around.

What do you think?

Regards,
Angelo

> ---
>   MAINTAINERS                         |  1 +
>   drivers/char/hw_random/Kconfig      | 16 +++++++
>   drivers/char/hw_random/Makefile     |  1 +
>   drivers/char/hw_random/mtk-rng-v2.c | 74 +++++++++++++++++++++++++++++
>   4 files changed, 92 insertions(+)
>   create mode 100644 drivers/char/hw_random/mtk-rng-v2.c
>