Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp3801833pxb; Mon, 30 Aug 2021 10:57:50 -0700 (PDT) X-Google-Smtp-Source: ABdhPJy4vhI+JfoAbpbIXJZhuQoX+ImlpeRihU6vBjfDQYARxpZwjXHu7+fJmW7t36lmbQEAIV4q X-Received: by 2002:a17:906:909:: with SMTP id i9mr25801763ejd.16.1630346269881; Mon, 30 Aug 2021 10:57:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1630346269; cv=none; d=google.com; s=arc-20160816; b=s/4I2xAiZscV+lsV5LNm0qcOo4/CQswrDcT1bImOWBpwd4N7k3MiQFMYHRm9B+0lx+ H0maU8+EM9iGuWPTy5Sl8ZKmSudDJT1Lo1MkgFM9IJFdOeLCplPia3vimoIDJWW5r/oa v+zCYlfEvh0zKWwZS1STZCeNk6V8e4I9iu+hWEQl4/AUsnZaqQ1JMzgnjUPIqLk2fvod IEAfrcySphD7YgczMyn7rwU+TPAf1L7Jbn8/pRVCEAxpNPyTFhdLrFercbl7uyZBcH7B R+iELpyOkoLD/L8GfVUjZp11AgF+lhVUVrl25gdZJQq2gvbRrUso1PbNBTID54DwJLqi Jh7A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=eTE3MdWDa0ijyIr/n6yzy10jcQzO9lkr6PVD0Y4UoUY=; b=bIWt2nTGFyMKzF6lelDhg6loKP0DAUL4RxNpnn9Jj7yiHZSvdOpS+8Yci18lK6ZDeK ORXSdc3UWQ91GXcdK0V3Ntq8XEFwo8W5gmE9McLugqnwm1R7v9ZVE9+55EBO0Nm+uCix 9oAEi38JmmkA97HjHGwYmVktXfhVhiJ2SNwt/upiXLG+vPy0X+4xmYbwmZmjRxR0GXNt HR2Hf4f9k+Xuga9XAnqsmswgIekO/TuPhl70P3SypxEBEZIPKsDFaLQ2A7zdl9REEkZS IUHAwCPHlNLsEnPRljF4Zdg9/AR9i81xyMSoNzkmEmRP5LySlFkz8CpOhkVuBodbmm3x BQzw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@endian-se.20150623.gappssmtp.com header.s=20150623 header.b=uhp0aHQQ; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d3si13960581ejt.22.2021.08.30.10.57.15; Mon, 30 Aug 2021 10:57:49 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@endian-se.20150623.gappssmtp.com header.s=20150623 header.b=uhp0aHQQ; spf=pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-crypto-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238244AbhH3R6E (ORCPT + 99 others); Mon, 30 Aug 2021 13:58:04 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41390 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238200AbhH3R6E (ORCPT ); Mon, 30 Aug 2021 13:58:04 -0400 Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6308AC06175F for ; Mon, 30 Aug 2021 10:57:10 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id m28so2680366lfj.6 for ; Mon, 30 Aug 2021 10:57:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=endian-se.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=eTE3MdWDa0ijyIr/n6yzy10jcQzO9lkr6PVD0Y4UoUY=; b=uhp0aHQQuxkAg/lbFvL7BhuO82iq14fvJxGbehkYSmUHAZltMXDCpiemhqLKV4JTQL 4Y4+wwnVqGMTFClUtzA8kXbD9BviIpR6Pgup4dTqjKLj7ArRoPwbE+SA9sCAJTkCNCLl T5tsOylKz4vcxwHKfYcESxUYJHWO+sGL+Ri3rwzmrrFBSdXdiOUFMmOEi+n1MCzizohw RBnD1mDxmC8NouJQQ8MsdApGnasXep2FFeQJmfSX2nyZ6bAPOnGhVM09N2Hk4ZlwmjVs ddx2RWiDkNBPTdeGKuNsPvJ6WiPi8/qYgioe+GLMWbA+j54CB3ByOIKNECKuhOOyNflW X+uA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=eTE3MdWDa0ijyIr/n6yzy10jcQzO9lkr6PVD0Y4UoUY=; b=m+ecuzRcVrdRVVT/dK9NvKFZ5IP1ZzFxVK5Qn/F/obqsaU+fbxtRq7A/1t7H2FjCKk YEkNhtEeqof12tV1u+zTCXp4vEX2d34pEgb3wHUgtdhKU5xf4oP46snpgyNos03/CSGg m979WE58XtKSO+klzuuMEdS3p60caKJ1YYnafCifnII9f5efaY8sbr9C1TTKQicNRY9H ciOXxN8flUB+QeuGmoW2u61R+Y+gFa6JAb8ys/qyYWTyVTgGNDnFYWA2FAeYRg4paiOu 9mDbmFOEh4ZbDH0oZQ3W+FVi7V+vec2DZWWn8hssF0qGL3yqdZMtdjFlJLGTIyRSspLO jf2Q== X-Gm-Message-State: AOAM533/PdVromKT/TXedYtVcmJLuPCjFVuPLX0f7Qp65Ka2qkyZBmQy HSWtyYfhl6ococttlOmu41Cmvw== X-Received: by 2002:a05:6512:2308:: with SMTP id o8mr18245900lfu.546.1630346228687; Mon, 30 Aug 2021 10:57:08 -0700 (PDT) Received: from gmail.com ([185.213.154.232]) by smtp.gmail.com with ESMTPSA id h9sm1583193lfv.190.2021.08.30.10.57.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 30 Aug 2021 10:57:07 -0700 (PDT) Date: Mon, 30 Aug 2021 19:57:01 +0200 From: Fredrik Yhlen To: Fabio Estevam Cc: Horia Geanta Neag , Aymen Sghaier , Herbert Xu , "David S. Miller" , "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" , linux-kernel , Andrey Smirnov , Heiko Schocher Subject: Re: HRNG in CAAM isn't working properly on IMX6 SoloX Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org Hi, Excuse me, I meant Fabio - brain not with me today. :) Anyway, is anyone with more expertise in this area looking into fixing this? Best regards, Fredrik On Mon, Aug 30, 2021 at 06:28:04PM +0200, Fredrik Yhlen wrote: > Hi Pablo, > > It seems to be working with your suggested change and PR enabled: > ``` > root@xxxx:/dev# dd bs=256 count=10 if=/dev/hwrng of=/dev/null > 10+0 records in > 10+0 records out > 2560 bytes (2.6 kB, 2.5 KiB) copied, 14.5987 s, 0.2 kB/s > root@xxxx:/dev# > ``` > > Thanks! > > Best regards, > Fredrik > > On Mon, Aug 30, 2021 at 08:49:25AM -0300, Fabio Estevam wrote: > > Hi Fredrik, > > > > On Mon, Aug 30, 2021 at 8:22 AM Fredrik Yhlen wrote: > > > > > > Hi, > > > > > > We're having problems with hwrng on a board with imx6sx (soloX) running Linux > > > 5.10.x. mainline, and I have tracked it down to this commit > > > '358ba762d9f1d4ba99ab31ef12bc28014b22f4c9' as being the culprit. > > > > > > The caam_jr driver spits out lots of messages when attempting to read from /dev/hwrng: > > > ``` > > > [29717.629041] hwrng: no data available > > > [29727.859008] caam_jr 2101000.jr: 20003c5b: CCB: desc idx 60: RNG: Hardware error > > > ``` > > > > > > ``` > > > caam_jr 2101000.jr0: 2000025b: CCB: desc idx 2: RNG: Hardware error. > > > caam_jr 2101000.jr0: 20003c5b: CCB: desc idx 60: RNG: Hardware error. > > > caam_jr 2101000.jr0: 20003c5b: CCB: desc idx 60: RNG: Hardware error. > > > caam_jr 2101000.jr0: 20003c5b: CCB: desc idx 60: RNG: Hardware error. > > > caam_jr 2101000.jr0: 20003c5b: CCB: desc idx 60: RNG: Hardware error. > > > caam_jr 2101000.jr0: 20003c5b: CCB: desc idx 60: RNG: Hardware error. > > > ``` > > > > > > This also happens on Boundary's Nitrogen6_soloX board when running the same > > > kernel, and likewise with their latest Yocto release that uses 5.4.100 linux-imx kernel. > > > > > > ``` > > > root@nitrogen6sx:~# dd if=/dev/hwrng of=/tmp/random bs=256 count=10 > > > [ 113.940735] caam_jr 2101000.jr0: 20003c5b: CCB: desc idx 60: RNG: Hardware error > > > dd: /dev/hwrng: Invalid argument > > > root@nitrogen6sx:~# rm /tmp/random > > > root@nitrogen6sx:~# dd if=/dev/hwrng of=/tmp/random bs=256 count=10 > > > [ 125.300823] caam_jr 2101000.jr0: 20003c5b: CCB: desc idx 60: RNG: Hardware error > > > dd: /dev/hwrng: Invalid argument > > > root@nitrogen6sx:~# du -hs /tmp/random > > > 0 /tmp/random > > > root@nitrogen6sx:~# ls -l /tmp/random > > > -rw-r--r-- 1 root root 0 Dec 16 17:27 /tmp/random > > > root@nitrogen6sx:~# > > > ``` > > > > > > And then no data is available from /dev/hwrng. > > > > > > The problem occurs when adding OP_ALG_PR_ON(prediction resistance) when setting up > > > job descriptor for reading new random data in caamrng.c. There are also > > > some confusing parts about this commit that I'm not too sure about. > > > > > > 1. It's adding a conditional variable named 'pr_support', but I guess this only > > > indicates if the MC(Management Complex) supports prediction resistance, > > > since the following check can be bypassed when 'pr_support' is false. > > > > > > /* > > > * If SEC has RNG version >= 4 and RNG state handle has not been > > > * already instantiated, do RNG instantiation > > > * In case of SoCs with Management Complex, RNG is managed by MC f/w. > > > */ > > > if (!(ctrlpriv->mc_en && pr_support) && rng_vid >= 4) { > > > > > > > > > This will eventually lead to the following chain call: caam_probe() -> instantiate_rng() -> > > > build_instantiation_desc(), where OP_ALG_PR_ON will be used through DECO. > > > > > > static void build_instantiation_desc(u32 *desc, int handle, int do_sk) > > > { > > > u32 *jump_cmd, op_flags; > > > > > > init_job_desc(desc, 0); > > > > > > op_flags = OP_TYPE_CLASS1_ALG | OP_ALG_ALGSEL_RNG | > > > (handle << OP_ALG_AAI_SHIFT) | OP_ALG_AS_INIT | > > > OP_ALG_PR_ON; > > > ... > > > ... > > > ... > > > > > > Shouldn't it be named 'mc_pr_support' instead, or something similar? > > > > > > 2. PR is unconditionally used in caamrng.c(caam_jr module) when > > > reading new RNG data. Should this be the case? > > > > > > Removing OP_ALG_PR_ON in caam_init_desc() from drivers/crypto/caam/caamrng.c > > > seems to fix the problem we're experiencing, here's an example: > > > ``` > > > diff --git a/drivers/crypto/caam/caamrng.c b/drivers/crypto/caam/caamrng.c > > > index 77d048dfe5d0..f085a80b1b3c 100644 > > > --- a/drivers/crypto/caam/caamrng.c > > > +++ b/drivers/crypto/caam/caamrng.c > > > @@ -67,8 +67,7 @@ static u32 *caam_init_desc(u32 *desc, dma_addr_t dst_dma) > > > { > > > init_job_desc(desc, 0); /* + 1 cmd_sz */ > > > /* Generate random bytes: + 1 cmd_sz */ > > > - append_operation(desc, OP_ALG_ALGSEL_RNG | OP_TYPE_CLASS1_ALG | > > > - OP_ALG_PR_ON); > > > + append_operation(desc, OP_ALG_ALGSEL_RNG | OP_TYPE_CLASS1_ALG); > > > /* Store bytes: + 1 cmd_sz + caam_ptr_sz */ > > > append_fifo_store(desc, dst_dma, > > > CAAM_RNG_MAX_FIFO_STORE_SIZE, FIFOST_TYPE_RNGSTORE); > > > ``` > > > > We also observe this issue. > > > > Heiko on Cc tried increasing the RTSDCTL_ENT_DLY_MIN value > > and this seems to help: > > > > diff --git a/drivers/crypto/caam/regs.h b/drivers/crypto/caam/regs.h > > index af61f3a2c0d4..53c9fa04a24c 100644 > > --- a/drivers/crypto/caam/regs.h > > +++ b/drivers/crypto/caam/regs.h > > @@ -513,7 +513,7 @@ struct rng4tst { > > }; > > #define RTSDCTL_ENT_DLY_SHIFT 16 > > #define RTSDCTL_ENT_DLY_MASK (0xffff << RTSDCTL_ENT_DLY_SHIFT) > > -#define RTSDCTL_ENT_DLY_MIN 3200 > > +#define RTSDCTL_ENT_DLY_MIN 4800 > > #define RTSDCTL_ENT_DLY_MAX 12800 > > u32 rtsdctl; /* seed control register */ > > union { > > > > Does this help in your case? > > > > Thanks, > > > > Fabio Estevam