From patchwork Sat Apr 11 12:08:49 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Greg KH X-Patchwork-Id: 228103 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=3.0 tests=DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI, SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 902CEC2BBC7 for ; Sat, 11 Apr 2020 12:11:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 653FA21744 for ; Sat, 11 Apr 2020 12:11:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607096; bh=n9rmmBrENhy6TDpT9Axt8H10o6yNclgku19ixyVaLpM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=SaY9k/fTgZe2phTc2am+1AED3vhJlDkR0m/icAbtNdo04pGLTD3l87TbvwNhpmNiS folyPu2d9AcrrUpCbtuJ+JgbzsJ4x8kqrKxa7DH7md8GMvdM4dmTdxRsoB24dbVWes dXU/2ckBo2/e7wMVA7lSkxGNo9IOhP/oGbBhmP0U= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727001AbgDKMLf (ORCPT ); Sat, 11 Apr 2020 08:11:35 -0400 Received: from mail.kernel.org ([198.145.29.99]:43744 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726995AbgDKMLe (ORCPT ); Sat, 11 Apr 2020 08:11:34 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A029421D79; Sat, 11 Apr 2020 12:11:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586607095; bh=n9rmmBrENhy6TDpT9Axt8H10o6yNclgku19ixyVaLpM=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=wWpTJG5rONBIpixT0aLmnilQ4l881bMFlulp2j3A+Utk944D7jlvOB4V2vo3WUHes yf/dMDqTauICqcqYDLwQjYp93yqz6lGlxMvSL6ujT6fg6RNyPk53wJHCX2dw8mraLs f28JoHF1c0HHQUD7XQYeQRrrz2DiOZdIUNa4GcnM= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, "Jason A. Donenfeld" , Theodore Tso Subject: [PATCH 4.4 19/29] random: always use batched entropy for get_random_u{32, 64} Date: Sat, 11 Apr 2020 14:08:49 +0200 Message-Id: <20200411115411.092282795@linuxfoundation.org> X-Mailer: git-send-email 2.26.0 In-Reply-To: <20200411115407.651296755@linuxfoundation.org> References: <20200411115407.651296755@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org From: Jason A. Donenfeld commit 69efea712f5b0489e67d07565aad5c94e09a3e52 upstream. It turns out that RDRAND is pretty slow. Comparing these two constructions: for (i = 0; i < CHACHA_BLOCK_SIZE; i += sizeof(ret)) arch_get_random_long(&ret); and long buf[CHACHA_BLOCK_SIZE / sizeof(long)]; extract_crng((u8 *)buf); it amortizes out to 352 cycles per long for the top one and 107 cycles per long for the bottom one, on Coffee Lake Refresh, Intel Core i9-9880H. And importantly, the top one has the drawback of not benefiting from the real rng, whereas the bottom one has all the nice benefits of using our own chacha rng. As get_random_u{32,64} gets used in more places (perhaps beyond what it was originally intended for when it was introduced as get_random_{int,long} back in the md5 monstrosity era), it seems like it might be a good thing to strengthen its posture a tiny bit. Doing this should only be stronger and not any weaker because that pool is already initialized with a bunch of rdrand data (when available). This way, we get the benefits of the hardware rng as well as our own rng. Another benefit of this is that we no longer hit pitfalls of the recent stream of AMD bugs in RDRAND. One often used code pattern for various things is: do { val = get_random_u32(); } while (hash_table_contains_key(val)); That recent AMD bug rendered that pattern useless, whereas we're really very certain that chacha20 output will give pretty distributed numbers, no matter what. So, this simplification seems better both from a security perspective and from a performance perspective. Signed-off-by: Jason A. Donenfeld Reviewed-by: Greg Kroah-Hartman Link: https://lore.kernel.org/r/20200221201037.30231-1-Jason@zx2c4.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman --- drivers/char/random.c | 6 ------ 1 file changed, 6 deletions(-) --- a/drivers/char/random.c +++ b/drivers/char/random.c @@ -1824,9 +1824,6 @@ unsigned int get_random_int(void) __u32 *hash; unsigned int ret; - if (arch_get_random_int(&ret)) - return ret; - hash = get_cpu_var(get_random_int_hash); hash[0] += current->pid + jiffies + random_get_entropy(); @@ -1846,9 +1843,6 @@ unsigned long get_random_long(void) __u32 *hash; unsigned long ret; - if (arch_get_random_long(&ret)) - return ret; - hash = get_cpu_var(get_random_int_hash); hash[0] += current->pid + jiffies + random_get_entropy();