[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20210727005922.GN4670@sirena.org.uk>
Date: Tue, 27 Jul 2021 01:59:22 +0100
From: Mark Brown <broonie@...nel.org>
To: Andre Przywara <andre.przywara@....com>
Cc: Matt Mackall <mpm@...enic.com>,
Herbert Xu <herbert@...dor.apana.org.au>,
Mark Rutland <mark.rutland@....com>,
Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
Sudeep Holla <sudeep.holla@....com>,
linux-crypto@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Ard Biesheuvel <ardb@...nel.org>,
Will Deacon <will@...nel.org>, Ali Saidi <alisaidi@...zon.com>,
Jon Nettleton <jon@...id-run.com>
Subject: Re: [PATCH v3 2/2] hwrng: Add Arm SMCCC TRNG based driver
On Tue, Jul 27, 2021 at 01:30:04AM +0100, Andre Przywara wrote:
> Now thinking about this, there would probably be some value in making
> the TRNG UUID somehow available, as this can be used to identify flawed
> implementations (general problems in the hardware or backend bugs). But
> this should be some query-able interface, rather than some line in
> dmesg. Any ideas? Might be beyond the scope of this series, though...
I guess you could append it to the name (eg, "SMCCC TRNG ${UUID}")
though it'd be a bit of an eyesore if anyone displays that in UIs much?
A separate version string queryable in parallel with name would be more
work but possibly a bit more sensible, some other hardware entropy
sources will have firmware version numbers or similar they could
usefully report I expect.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists