Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754546AbdGTNIz (ORCPT ); Thu, 20 Jul 2017 09:08:55 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:51611 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754387AbdGTNIv (ORCPT ); Thu, 20 Jul 2017 09:08:51 -0400 Subject: Re: [PATCH v1] crypto: caam - set hwrng quality level To: Oleksij Rempel , =?UTF-8?Q?Horia_Geant=c4=83?= Cc: Herbert Xu , "linux-kernel@vger.kernel.org" , Oleksij Rempel , Dan Douglass , "linux-crypto@vger.kernel.org" , "kernel@pengutronix.de" , Martin Schwidefsky , "David S. Miller" References: <20170719074458.9247-1-o.rempel@pengutronix.de> <20170719163248.sn7mvnq2s3fm2hvh@pengutronix.de> <20170719181303.rj4fyjj7qplatrzk@pengutronix.de> From: Harald Freudenberger Date: Thu, 20 Jul 2017 15:08:43 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170719181303.rj4fyjj7qplatrzk@pengutronix.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-TM-AS-GCONF: 00 x-cbid: 17072013-0040-0000-0000-000003C583FD X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17072013-0041-0000-0000-000025C1B2F3 Message-Id: <4e42d639-9f83-dcbb-9a2a-91686656c7dd@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-07-20_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1706020000 definitions=main-1707200202 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3465 Lines: 81 On 07/19/2017 08:13 PM, Oleksij Rempel wrote: > On Wed, Jul 19, 2017 at 04:53:21PM +0000, Horia Geantă wrote: >> On 7/19/2017 7:32 PM, Oleksij Rempel wrote: >>> On Wed, Jul 19, 2017 at 12:49:47PM +0000, Horia Geantă wrote: >>>> On 7/19/2017 10:45 AM, Oleksij Rempel wrote: >>>>> According documentation, it is NIST certified TRNG. >>>>> So, set high quality to let the HWRNG framework automatically use it. >>>>> >>>>> Signed-off-by: Oleksij Rempel >>>>> --- >>>>> drivers/crypto/caam/caamrng.c | 6 ++++++ >>>>> 1 file changed, 6 insertions(+) >>>>> >>>>> diff --git a/drivers/crypto/caam/caamrng.c b/drivers/crypto/caam/caamrng.c >>>>> index 41398da3edf4..684c0bc88dfd 100644 >>>>> --- a/drivers/crypto/caam/caamrng.c >>>>> +++ b/drivers/crypto/caam/caamrng.c >>>>> @@ -292,10 +292,16 @@ static int caam_init_rng(struct caam_rng_ctx *ctx, struct device *jrdev) >>>>> return 0; >>>>> } >>>>> >>>>> +/* >>>>> + * hwrng register struct >>>>> + * The trng is suppost to have 100% entropy, and thus >>>>> + * we register with a very high quality value. >>>>> + */ >>>>> static struct hwrng caam_rng = { >>>>> .name = "rng-caam", >>>>> .cleanup = caam_cleanup, >>>>> .read = caam_read, >>>>> + .quality = 999, >>>> Why not 1024, i.e. where is 999 coming from? >>> It comes from s390-trng.c driver. >>> Should I use 1024 instead? >>> >> AFAICT the range for quality is from 0 to 1024 (no entropy -> perfect >> entropy). >> >> 1024 should be used since I'd expect a HW TRNG to provide perfect >> entropy unless otherwise stated. > I assume 1024 can be given only on verified HW with accessible verilog > files and compared with resulting chip :) > May be this would be a good example https://www.sifive.com/ > Well, the header file says: ... /** * struct hwrng - Hardware Random Number Generator driver * @name: Unique RNG name. * @init: Initialization callback (can be NULL). * @cleanup: Cleanup callback (can be NULL). * @data_present: Callback to determine if data is available * on the RNG. If NULL, it is assumed that * there is always data available. *OBSOLETE* * @data_read: Read data from the RNG device. * Returns the number of lower random bytes in "data". * Must not be NULL. *OBSOLETE* * @read: New API. drivers can fill up to max bytes of data * into the buffer. The buffer is aligned for any type * and max is a multiple of 4 and >= 32 bytes. * @priv: Private data, for use by the RNG driver. * @quality: Estimation of true entropy in RNG's bitstream * (per mill). */ ... quality = estimation of true entropy per mill. I understand this as quality=1000 meaning 100% entropy. However, the core code currently does not really check this value. When more than one hwrng sources do register, simple the one with the higher quality value wins :-) The value is not even checked to be in a given range. I searched through some device drivers which do register at the hwrng and it looks like most of the drivers do not even set this value. My feeling is, you should use 999 when your hardware provides 'perfect' random. So there is a chance for an even 'more perfect' hardware coming up later to overrule your 'perfect' hardware. regards Harald Freudenberger