From patchwork Wed Sep 26 03:24:55 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Louis Collard X-Patchwork-Id: 10615183 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 538EC14BD for ; Wed, 26 Sep 2018 03:25:21 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 3AA362987F for ; Wed, 26 Sep 2018 03:25:21 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 2C1102AC7C; Wed, 26 Sep 2018 03:25:21 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 9C9B72987F for ; Wed, 26 Sep 2018 03:25:20 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726242AbeIZJgE (ORCPT ); Wed, 26 Sep 2018 05:36:04 -0400 Received: from mail-pf1-f195.google.com ([209.85.210.195]:39293 "EHLO mail-pf1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726250AbeIZJgE (ORCPT ); Wed, 26 Sep 2018 05:36:04 -0400 Received: by mail-pf1-f195.google.com with SMTP id j8-v6so12625111pff.6 for ; Tue, 25 Sep 2018 20:25:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id; bh=zZBmsP5oO4UuC2hC+KXG/IKvs6WIY2otf7jRBtBAZ8E=; b=F+f/LTpnl8QT+P8uhnkPgBWN+k8ow+V1na64InfTfzwNsPLkO+QEracGOvwAtY7/jU 2l1p7u+CvRlBZEkxbeqtpZehWJR4AeHWugZoaKiDfNiNrecOATfAyRR/AC9DT4iuwAA2 n6vHKwhUZFvhSLtSswmCUw/cQ3Tpv4J9toHgA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=zZBmsP5oO4UuC2hC+KXG/IKvs6WIY2otf7jRBtBAZ8E=; b=Ec9Gz7jXu/6Uv9OZvKyQtak2s7JeXD12jT5TVD+DZUn7UP5ulag8xX2X+GE+ohvhCh atnZTOdonfYoKLf1NJ5GocuvGOsZgw686Exx67Wde2faOlHpC2wQEPe1HQHmzY1iFRDu 3Z8VzFEyi97Bj3JYfufvcp1l0SiDVbJ4N4wZwFWncrT0invP2yjC5Gb7oPwIZf0+21ID cfFVpnlmBoNeY3B6pLsfmdkq76N//g09mE4pV4GsSpzkAfjan1OpEb1+AdfOwYDjiIGQ nbBtS0+3PCy3lKNXJ13djS42E8iin65myrh0NOZNMOMTtAcI6Vn5hNyD3CbJCQ9//C4Z 6H7Q== X-Gm-Message-State: ABuFfohBtBp+qFylEezXS0WEfuOFj1/6CFjpX5EPm93TvQ20aSYqYppx An5Lg5nPSqbeQUXwLEerP1vmN2tllzc= X-Google-Smtp-Source: ACcGV63yguLyqlvnt4KY2vRi+GlIOk1AqjNXeqp3n03YDL4UrNAGYMVrC62bXcQpHVgBYU7h7W7PzA== X-Received: by 2002:a62:5343:: with SMTP id h64-v6mr4041255pfb.226.1537932318541; Tue, 25 Sep 2018 20:25:18 -0700 (PDT) Received: from excession.tpe.corp.google.com ([2401:fa00:1:10:199d:5882:860a:4adb]) by smtp.gmail.com with ESMTPSA id c80-v6sm4262620pfc.109.2018.09.25.20.25.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 25 Sep 2018 20:25:17 -0700 (PDT) From: Louis Collard To: linux-integrity@vger.kernel.org Cc: Arnd Bergmann , Greg Kroah-Hartman , linux-kernel@vger.kernel.org, Jarkko Sakkinen , apronin@chromium.org, Jason Gunthorpe , david.bild@xaptum.com Subject: [PATCH] Allow hwrng to initialize crng. Date: Wed, 26 Sep 2018 11:24:55 +0800 Message-Id: <20180926032455.224600-1-louiscollard@chromium.org> X-Mailer: git-send-email 2.13.5 Sender: linux-integrity-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-integrity@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Some systems, for example embedded systems, do not generate enough entropy on boot through interrupts, and boot may be blocked for several minutes waiting for a call to getrandom to complete. Currently, random data is read from a hwrng when it is registered, and is loaded into primary_crng. This data is treated in the same way as data that is device-specific but otherwise unchanging, and so primary_crng cannot become initialized with the data from the hwrng. This change causes the data initially read from the hwrng to be treated the same as subsequent data that is read from the hwrng if it's quality score is non-zero. The implications of this are: The data read from hwrng can cause primary_crng to become initialized, therefore avoiding problems of getrandom blocking on boot. Calls to getrandom (with GRND_RANDOM) may be using entropy exclusively (or in practise, almost exclusively) from the hwrng. Regarding the latter point; this behavior is the same as if a user specified a quality score of 1 (bit of entropy per 1024 bits) so hopefully this is not too scary a change to make. This change is the result of the discussion here: https://patchwork.kernel.org/patch/10453893/ Signed-off-by: Louis Collard Acked-by: Jarkko Sakkinen --- drivers/char/hw_random/core.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/drivers/char/hw_random/core.c b/drivers/char/hw_random/core.c index aaf9e5afaad4..47f358aa0c3d 100644 --- a/drivers/char/hw_random/core.c +++ b/drivers/char/hw_random/core.c @@ -24,6 +24,7 @@ #include #include #include +#include #define RNG_MODULE_NAME "hw_random" @@ -64,13 +65,17 @@ static size_t rng_buffer_size(void) static void add_early_randomness(struct hwrng *rng) { int bytes_read; - size_t size = min_t(size_t, 16, rng_buffer_size()); + /* Read enough to initialize crng. */ + size_t size = 2*CHACHA20_KEY_SIZE; mutex_lock(&reading_mutex); bytes_read = rng_get_data(rng, rng_buffer, size, 1); mutex_unlock(&reading_mutex); if (bytes_read > 0) - add_device_randomness(rng_buffer, bytes_read); + /* Allow crng to become initialized, but do not add + * entropy to the pool. + */ + add_hwgenerator_randomness(rng_buffer, bytes_read, 0); } static inline void cleanup_rng(struct kref *kref)