linux-kernel - Re: [PATCH v3 2/2] hwrng: Add Arm SMCCC TRNG based driver

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]

Date:   Tue, 27 Jul 2021 01:30:04 +0100
From:   Andre Przywara <andre.przywara@....com>
To:     Mark Brown <broonie@...nel.org>
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 Mon, 26 Jul 2021 23:37:38 +0100
Mark Brown <broonie@...nel.org> wrote:

> On Mon, Jul 26, 2021 at 06:56:10PM +0100, Andre Przywara wrote:
> 
> > +static int smccc_trng_init(struct hwrng *rng)
> > +{
> > +	return 0;
> > +}  
> 
> If this can be empty (looking at the core it seems like it can) then
> best just remove it.

Ah, you are right! Actually this is explicitly mentioned in the
struct hwrng comments. Thanks for the heads up.

> 
> > +	platform_set_drvdata(pdev, trng);
> > +	ret = devm_hwrng_register(&pdev->dev, trng);
> > +	if (!ret)
> > +		dev_info(&pdev->dev,
> > +			 "ARM SMCCC TRNG firmware random number generator\n");  
> 
> Is the log message needed given that we're not announcing any version
> information here or anything?  A brief sampling of other drivers
> suggests it's not a standard thing for the subsystem.

Yeah, that was indeed more a leftover of the version print. I
thought about querying the version again explicitly, but this would
have brought back the SMCCC calls that I could so nicely delete. Plus,
the hwrng driver is just a (secondary) user of this interface, I think
announcing the version should be done in smccc.c. Which is probably
beyond the scope of this patch.

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...

Cheers,
Andre