From patchwork Wed Apr 19 17:01:34 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andre Przywara X-Patchwork-Id: 13217152 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 121A9C77B73 for ; Wed, 19 Apr 2023 17:01:55 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232996AbjDSRBy (ORCPT ); Wed, 19 Apr 2023 13:01:54 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56796 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231901AbjDSRBx (ORCPT ); Wed, 19 Apr 2023 13:01:53 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 6053426B6 for ; Wed, 19 Apr 2023 10:01:51 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E57571424; Wed, 19 Apr 2023 10:02:34 -0700 (PDT) Received: from donnerap.arm.com (donnerap.cambridge.arm.com [10.1.197.42]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2A04A3F5A1; Wed, 19 Apr 2023 10:01:50 -0700 (PDT) From: Andre Przywara To: Will Deacon , Julien Thierry Cc: kvm@vger.kernel.org, Alexandru Elisei , Sami Mujawar , Jean-Philippe Brucker , Marc Zyngier Subject: [PATCH kvmtool v2 0/2] Fix virtio/rng handling in low entropy situations Date: Wed, 19 Apr 2023 18:01:34 +0100 Message-Id: <20230419170136.1883584-1-andre.przywara@arm.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: kvm@vger.kernel.org At the moment kvmtool uses the /dev/random device to back the randomness provided by our virtio/rng implementation. We run it in non-blocking mode, so are not affected by the nasty "can block indefinitely" behaviour of that file. However: - If /dev/random WOULD block, it returns EAGAIN, and we reflect that by adding 0 bytes of entropy to the virtio queue. However the virtio 1.x spec clearly says this is not allowed, and that we should always provide at least one random byte. - If the guest is waiting for the random numbers, we still run into an effective blocking situation, because the buffer will only be filled very slowly, effectively stalling or blocking the guest. EDK II shows that behaviour, when servicing the EFI_RNG_PROTOCOL runtime service call, called by the kernel very early on boot. Those two patches fix those problems, and allow to boot a Linux kernel MUCH quicker when the host lacks good entropy sources. On a particular system the kernel took 10 minutes to boot because of /dev/random effectively blocking, this runs now at full speed. The block is avoided by using /dev/urandom, there is a proper rabbit hole in the internet out there why this is safe, even for cryptographic applications. Patch 2 aims to fix the corner case when the /dev/urandom read fails for whatever reason: we just try once more in this case, since it should only happen when the call is interrupted by a signal. This is not 100% bullet proof, I am happy to hear any suggestions or whether we just don't care about that very rare case. Please have a look! Cheers, Andre Changelog v1 ... v2: - Drop O_NONBLOCK from the /dev/urandom open() call - Drop block/unblock sequence after failed read, just retry once Andre Przywara (2): virtio/rng: switch to using /dev/urandom virtio/rng: return at least one byte of entropy virtio/rng.c | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-)