From patchwork Fri Feb 20 04:37:21 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andre Wolokita X-Patchwork-Id: 5854471 X-Patchwork-Delegate: herbert@gondor.apana.org.au Return-Path: X-Original-To: patchwork-linux-crypto@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 1BC3EBF440 for ; Fri, 20 Feb 2015 04:53:03 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 0D2C120340 for ; Fri, 20 Feb 2015 04:53:02 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0734720328 for ; Fri, 20 Feb 2015 04:53:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753735AbbBTEw6 (ORCPT ); Thu, 19 Feb 2015 23:52:58 -0500 Received: from mail-bn1bon0094.outbound.protection.outlook.com ([157.56.111.94]:18017 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753688AbbBTEw5 (ORCPT ); Thu, 19 Feb 2015 23:52:57 -0500 Received: from BY2PR03MB508.namprd03.prod.outlook.com (10.141.143.27) by BY2PR03MB457.namprd03.prod.outlook.com (10.141.141.141) with Microsoft SMTP Server (TLS) id 15.1.81.12; Fri, 20 Feb 2015 04:38:29 +0000 Received: from BN3PR0301CA0012.namprd03.prod.outlook.com (25.160.180.150) by BY2PR03MB508.namprd03.prod.outlook.com (10.141.143.27) with Microsoft SMTP Server (TLS) id 15.1.87.13; Fri, 20 Feb 2015 04:38:27 +0000 Received: from BN1BFFO11FD034.protection.gbl (2a01:111:f400:7c10::1:160) by BN3PR0301CA0012.outlook.office365.com (2a01:111:e400:4000::22) with Microsoft SMTP Server (TLS) id 15.1.99.9 via Frontend Transport; Fri, 20 Feb 2015 04:38:27 +0000 Received: from nwd2mta1.analog.com (137.71.25.55) by BN1BFFO11FD034.mail.protection.outlook.com (10.58.144.97) with Microsoft SMTP Server (TLS) id 15.1.99.6 via Frontend Transport; Fri, 20 Feb 2015 04:38:26 +0000 Received: from NWD2HUBCAS7.ad.analog.com (nwd2hubcas7.ad.analog.com [10.64.72.140]) by nwd2mta1.analog.com (8.13.8/8.13.8) with ESMTP id t1K4bk23017944 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Feb 2015 20:37:46 -0800 Received: from [10.122.9.130] (10.122.9.130) by NWD2HUBCAS7.ad.analog.com (10.64.72.140) with Microsoft SMTP Server (TLS) id 14.3.210.2; Thu, 19 Feb 2015 23:37:25 -0500 Message-ID: <54E6BA01.7090904@analog.com> Date: Fri, 20 Feb 2015 15:37:21 +1100 From: Andre Wolokita User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: , CC: , Subject: [PATCH v3] omap-rng: Change RNG_CONFIG_REG to RNG_CONTROL_REG when, checking and disabling TRNG X-EOPAttributedMessage: 0 Received-SPF: Pass (protection.outlook.com: domain of analog.com designates 137.71.25.55 as permitted sender) receiver=protection.outlook.com; client-ip=137.71.25.55; helo=nwd2mta1.analog.com; Authentication-Results: spf=pass (sender IP is 137.71.25.55) smtp.mailfrom=Andre.Wolokita@analog.com; vger.kernel.org; dkim=none (message not signed) header.d=none; X-Forefront-Antispam-Report: CIP:137.71.25.55; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009020)(6009001)(438002)(189002)(199003)(62966003)(50986999)(54356999)(87266999)(16796002)(229853001)(77096005)(46102003)(77156002)(36756003)(86362001)(33656002)(19580395003)(19580405001)(92566002)(80316001)(106466001)(6806004)(83506001)(15974865002)(64706001)(50466002)(59896002)(65956001)(47776003)(65816999)(65806001)(23676002)(64126003)(87936001)(3940600001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB508; H:nwd2mta1.analog.com; FPR:; SPF:Pass; PTR:nwd2mail10.analog.com; MX:1; A:1; LANG:en; X-Microsoft-Antispam: UriScan:;UriScan:; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB508; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005003); SRVR:BY2PR03MB508; X-Forefront-PRVS: 0493852DA9 X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB508; X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Feb 2015 04:38:26.5565 (UTC) X-MS-Exchange-CrossTenant-Id: eaa689b4-8f87-40e0-9c6f-7228de4d754a X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=eaa689b4-8f87-40e0-9c6f-7228de4d754a; Ip=[137.71.25.55] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB508 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB457; X-OriginatorOrg: analog.com Sender: linux-crypto-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-crypto@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP In omap4_rng_init(), a check of bit 10 of the RNG_CONFIG_REG is done to determine whether the RNG is running. This is suspicious firstly due to the use of RNG_CONTROL_ENABLE_TRNG_MASK and secondly because the same mask is written to RNG_CONTROL_REG after configuration of the FROs. Similar suspicious logic is repeated in omap4_rng_cleanup() when RNG_CONTROL_REG masked with RNG_CONTROL_ENABLE_TRNG_MASK is read, the same mask bit is cleared, and then written to RNG_CONFIG_REG. Unless the TRNG is enabled with one bit in RNG_CONTROL and disabled with another in RNG_CONFIG and these bits are mirrored in some way, I believe that the TRNG is not really shutting off, leaving the FROs running indefinitely which, in an extreme case, could lead to degredation of the hardware and potentially reduce the level of entropy generated. Apart from the strange logic, I have reason to suspect that the OMAP4 related code in this driver is driving an Inside Secure IP hardware RNG and strongly suspect that bit 10 of RNG_CONFIG_REG is one of the bits configuring the sampling rate of the FROs. This option is by default set to 0 and is not being set anywhere in omap-rng.c. Reading this bit during omap4_rng_init() will always return 0. It will remain 0 because ~(value of TRNG_MASK in control) will always be 0, because the TRNG is never shut off. This is of course presuming that the OMAP4 features the Inside Secure IP, which I strongly suspect. I'm interested in knowing what the guys at TI think about this, as only they can confirm or deny the detailed structure of these registers. Signed-off-by: Andre Wolokita Acked-by: Lokesh Vutla --- drivers/char/hw_random/omap-rng.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/char/hw_random/omap-rng.c b/drivers/char/hw_random/omap-rng.c index d14dcf7..67151cb 100644 --- a/drivers/char/hw_random/omap-rng.c +++ b/drivers/char/hw_random/omap-rng.c @@ -236,7 +236,7 @@ static int omap4_rng_init(struct omap_rng_dev *priv) u32 val; /* Return if RNG is already running. */ - if (omap_rng_read(priv, RNG_CONFIG_REG) & RNG_CONTROL_ENABLE_TRNG_MASK) + if (omap_rng_read(priv, RNG_CONTROL_REG) & RNG_CONTROL_ENABLE_TRNG_MASK) return 0; val = RNG_CONFIG_MIN_REFIL_CYCLES << RNG_CONFIG_MIN_REFIL_CYCLES_SHIFT; @@ -262,7 +262,7 @@ static void omap4_rng_cleanup(struct omap_rng_dev *priv) val = omap_rng_read(priv, RNG_CONTROL_REG); val &= ~RNG_CONTROL_ENABLE_TRNG_MASK; - omap_rng_write(priv, RNG_CONFIG_REG, val); + omap_rng_write(priv, RNG_CONTROL_REG, val); } static irqreturn_t omap4_rng_irq(int irq, void *dev_id)