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 31C423B190 for ; Thu, 1 Feb 2024 04:48:19 +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=1706762902; cv=none; b=fOLz/GWHO1aiU1AQd4BGpvuka/oqRVcRPtU7Q6v7Lb0oQyTWoh6s+V1vqkwTi4nAGyCzCelj9mL4pGnxmSlJCUPBr30Q7vyTNPNqBFxgM0q1E5Z6X8P3uWyYj7eBt29RL12sxAJElDYsUv5qZ4dEs15QHxHFs9ofgkmb9TTmGxQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706762902; c=relaxed/simple; bh=/6YbQjizUZMS23f4SnahTuQrczLTdM9PS2UdU1MpK0Y=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=kmbUxOXzMWoZ/ej+dWczEek+XvXJB/Dd08e7ptPwkBxwfBdGqWbi10Ms08v0Uxi1rhDKRvxxVoaStyx0APhOCiSjgbyjbePfbuCQm/LBz79nt14gXREv/lKCRFKMWJHXsl4ARx8NnTxmLnh9WkZeCherr/1WXKLNJmiMJhzPjwo= 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=mJ30WTYx; 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="mJ30WTYx" 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 4114lZfQ008107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 31 Jan 2024 23:47:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1706762860; bh=BFvwTRtGW9jE9hJ9zWULwsFsLtUy+2JhKU5qj42LjRA=; h=Date:From:Subject:Message-ID:MIME-Version:Content-Type; b=mJ30WTYxc+jicP7NtTK/sK5Qfp95EW8SIPC2VIt9Hzvo9pTY5TmZllPzbBdvk4ZUo UYSUOxqKUp5oiWbSqQ4fLsWLNA+3TypHcQyeiC6pMUGXELlycJAK2TaI3D0ffRaLr2 P7roc1WYEgo3lj+yK0jfWco5SSFrlRma8WYGCUyA2lt/8/dLbYLJbBR8CWcR2/MIqq uEHH2OuzMoxaxAee9TKjipvL/uyGMktk1sdCKRS0A2EqBVzNSs95apz28LMfoHxakU ig/XuRLSYNTpATsbWP9GAevXLr3TCr7olt7sb8FJ90hrMiMIqRa/OhLWBrEjuIYdVN 3MlsY+rvHfWSA== Received: by cwcc.thunk.org (Postfix, from userid 15806) id 8C87115C0667; Wed, 31 Jan 2024 23:47:35 -0500 (EST) Date: Wed, 31 Jan 2024 23:47:35 -0500 From: "Theodore Ts'o" To: "Dr. Greg" Cc: "Jason A. Donenfeld" , "Reshetova, Elena" , "Daniel P. Berrang??" , "Hansen, Dave" , "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 2/2] x86/random: Issue a warning if RDRAND or RDSEED fails Message-ID: <20240201044735.GC2356784@mit.edu> References: <20240130083007.1876787-1-kirill.shutemov@linux.intel.com> <20240130083007.1876787-2-kirill.shutemov@linux.intel.com> <88a72370-e300-4bbc-8077-acd1cc831fe7@intel.com> <20240131203531.GA12035@wind.enjellic.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: <20240131203531.GA12035@wind.enjellic.com> On Wed, Jan 31, 2024 at 02:35:32PM -0600, Dr. Greg wrote: > I think it would demonstrate a lack of appropriate engineering > diligence on the part of our community to declare RDRAND 'busted' at > this point. > > While it appeares to be trivially easy to force RDSEED into depletion, > there does not seem to be a suggestion, at least in the open > literature, that this directly or easily translates into stalling > output from RDRAND in any type of relevant adversarial fashion. > > If this were the case, given what CVE's seem to be worth on a resume, > someone would have rented a cloud machine and come up with a POC > against RDRAND in a multi-tenant environment and then promptly put up > a web-site called 'Random Starve' or something equally ominous. I suspect the reason why DOS attacks aren't happening in practice, is because of concerns over the ability to trust the RDRAND (how do you prove that the NSA didn't put a backdoor into the hardware with Intel's acquisence --- after all, the NSA absolutely positively didn't encourage the kneecaping of WEP and absolutely didn't put a trapdoor into DUAL_EC_DRBG...) since it can not externally audited and verfied by a third party, in contrast to the source code for the /dev/random driver or the RNG used in OpenSSL. As a result, most random number generators use RDRAND in combination with other techniques. If RDRAND is absolutely trustworthy, the extra sources won't hurt --- and if it isn't trustworthy mixing in other sources will likely make things harder for Fort Meade. And even if these other sources might be observable for someone who can listen in on the inter-packet arrival times on the LAN (for example), it might not be so easy for an analyst sitting at their desk in Fort Meade. And once you do _that_, you don't need to necessarily loop on RDRAND, because it's one of multiple sources of entropies that are getting mixed togethwer. Hence, even if someone drives RDRAND into depletion, if they are using getrandom(2), it's not a big deal. There's a special case with Confidential Compute VM's, since the assumption is that you want to protect against even a malicious hypervisor who could theoretically control all other sources of timing uncertainty. And so, yes, in that case, the only thing we can do is Panic if RDRAND fails. - Ted