From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id F050783CDA for ; Wed, 31 Jan 2024 14:08:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=18.9.28.11 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706710125; cv=none; b=JZQDtgdsMQHY4dgUlStrLKk3CqxVt8Q5xkaVYe60TmNmQvJDZiO55DbDECdFbBV6JyCJNXDzh5jDCn1P4eOw4+iEDNrD/qoFTgImICRfaOOIw93nYiH1ytlCo7brYt0g1tAEc0R5TtaOj3pBeRpG+3jL4wUmdcK41Ee+azxzvpc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706710125; c=relaxed/simple; bh=hJTI6Oqt+tvrDrRCKdy4Fv4/v/exHoBoefP7wGq2GPs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Q2IvVvnwCwLay7WwmafUsX7DAipFuNKkBzJle5CIUpNs/VK568sQ+vRQ41F/HgpMFOHFPu15vw4IqAUfXiDQ2l6TlZ3hWEFgkg4y/rMYVAKOPvJVHxut34UAaPqevUrG9J7sxchPKc4aNqs6+rDfBsn3rifOjo38DkUsR/4edsc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=mit.edu; spf=pass smtp.mailfrom=mit.edu; dkim=pass (2048-bit key) header.d=mit.edu header.i=@mit.edu header.b=L6G1T/Sp; arc=none smtp.client-ip=18.9.28.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=mit.edu Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=mit.edu Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=mit.edu header.i=@mit.edu header.b="L6G1T/Sp" Received: from cwcc.thunk.org (pool-173-48-116-252.bstnma.fios.verizon.net [173.48.116.252]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 40VE7u72016816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 31 Jan 2024 09:07:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1706710083; bh=3jBxU9JGxDt+piXZr4pBKK0kAm/pYnikufO2RLtXeAM=; h=Date:From:Subject:Message-ID:MIME-Version:Content-Type; b=L6G1T/SpkbuN99nevYXm2O9FspvsdZWzSBUmHtyziTUUOC8ZGozpeC4J+UE2j7blo GKhQx+DpJEKT2lE2S9NiUt8tckt8Za5Mj7AHUP2Jn8z5xAaE8cV9ga3i7+hGqbfw2p LUJ0ug7Fi3yFZkM3DcNsdivyLraGFNVLeKgLhLblAxffEux+yb2lZZyqLPKjQv46rq MzyxXf0jneqVNrHe5HYEMIS+MsZfchuD4GE6iO8BDdJ4ye7wwuQvU6m155FAUsXax1 ut4S6IvT+kHVmrmSi3ejB9cJYwgE5bNXzhlRVE1kwBetkZ231gQMVkmxmZHJGVH7lL 4jgq6EMGBKmSg== Received: by cwcc.thunk.org (Postfix, from userid 15806) id C5F0D15C0667; Wed, 31 Jan 2024 09:07:56 -0500 (EST) Date: Wed, 31 Jan 2024 09:07:56 -0500 From: "Theodore Ts'o" To: "Jason A. Donenfeld" Cc: "Reshetova, Elena" , "Kirill A. Shutemov" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , "H. Peter Anvin" , "x86@kernel.org" , Kuppuswamy Sathyanarayanan , "Nakajima, Jun" , Tom Lendacky , "Kalra, Ashish" , Sean Christopherson , "linux-coco@lists.linux.dev" , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH 1/2] x86/random: Retry on RDSEED failure Message-ID: <20240131140756.GB2356784@mit.edu> References: <20240130083007.1876787-1-kirill.shutemov@linux.intel.com> Precedence: bulk X-Mailing-List: linux-coco@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: What about simply treating boot-time initialization of the /dev/random state as special. That is, on x86, if the hardware promises that RDSEED or RDRAND is available, we use them to initialization our RNG state at boot. On bare metal, there can't be anyone else trying to exhaust the on-chip RNG's entropy supply, so if RDSEED or RDRAND aren't working available --- panic, since the hardware is clearly busted. On a guest OS, if confidential compute is enabled, and if RDSEED and RDRAND don't work after N retries, and we know CC is enabled, panic, since the kernel can't provide the promised security gaurantees, and the CC developers and users are cordially invited to sharpen their pitchforks and to send their tender regards to the Intel RNG engineers. For non-confidential compute guests, the question is what is the appropriate reaction if another VM, possibly belonging to a different user/customer, is carrying out a RDRAND DOS attack. I'd argue that in these cases, if the guest VM is using virtio-random, then the host's /dev/random should be able to cover for cases of Intel RNG exhaustion, and allowing other customer to be able to prevent other user's VM's from being able to boot is the the greater evil, so we shouldn't treat boot-time RDRAND/RDSEED failures as panic-worthy. - Ted