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 77E0714AD07 for ; Fri, 2 Feb 2024 16:06:17 +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=1706889983; cv=none; b=JMmoyTYUU1LtR1LfGQpplw8taCPf33js3PquLZBBdL/BX+Re+EGBlMZHrxA1c8FqWjrUOJd0gytN86pST+JxDASuPA2dvVSbeoe6Sh1w0Y1c/LKczMRYUBJTCBr+WwHIxxrbJzfohp3I/M6jaTYIr7Xh4HlgqdC9WuTm8H/kS2U= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706889983; c=relaxed/simple; bh=Dvndydm0WQiAr8SlU79W28MqK5iSck9hcErAZtsmIyY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=I/MyMnBZH5SEziA5w6cXf3qFn7JTFzgy04wYvlIPgoROQoF4uyv9hVEyeBXVI6totYfhrd8ALK0ZPTAOFnzRi7I4bEIi9OrBc/nLgDoIZdpGrwYREWKj9MuEYhT9AIbR+36OwQ/2OOz+Fp9VG9pRdeir2u3G4CCzafZhUSiA9+E= 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=XXcPMMbC; 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="XXcPMMbC" Received: from cwcc.thunk.org (pool-173-48-116-13.bstnma.fios.verizon.net [173.48.116.13]) (authenticated bits=0) (User authenticated as tytso@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 412G5FUn028060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 2 Feb 2024 11:05:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1706889920; bh=YNDwaYqILYROFbZ2T7wdnv8w+SAS5ZpbU073hZkeTiI=; h=Date:From:Subject:Message-ID:MIME-Version:Content-Type; b=XXcPMMbCQXCYHB/LLJaHRJrNlhp80U9c2YRyCNdycadKxv7zueJalMaApizf6gv1t z5l6HH5428VQbFp7BT1GMx3w8iiZIHFaCp+X+FNmjqXFUtrjibjupf6AzfI/+9HS91 Jtr+FgTOtX4Atz4KN4UwZlglm4rZbd5SbAG5DPOYKXLeDa/+ztBh9WD0bY5RvniO2Q Nhk4HXt6Uw5zh1+ZaLrC9b/dO41Er4QHPDGMBGoFBpBduyM1ybZ8IEZ/vCsIVb+Wip jSxLpDJckcw46RAkCyQEb2zfAV+xW2RseHs79eg2+ZoZOpQLNXI43iB+twSQunUJnH Gypz0AcZcNs/A== Received: by cwcc.thunk.org (Postfix, from userid 15806) id 536D015C02FC; Fri, 2 Feb 2024 11:05:15 -0500 (EST) Date: Fri, 2 Feb 2024 11:05:15 -0500 From: "Theodore Ts'o" To: James Bottomley Cc: "Jason A. Donenfeld" , "Reshetova, Elena" , Dave Hansen , "Kirill A. Shutemov" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "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: <20240202160515.GC119530@mit.edu> References: <20240131140756.GB2356784@mit.edu> <20240131171042.GA2371371@mit.edu> <20240201045710.GD2356784@mit.edu> 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: On Fri, Feb 02, 2024 at 04:47:11PM +0100, James Bottomley wrote: > > It's a lot to quote, so I cut it, but all of your solutions assume a > rdseed/rdrand failure equates to a system one but it really doesn't: in > most systems there are other entropy sources. In confidential > computing it is an issue because we have no other trusted sources. The > problem with picking on rdseed/rdrand is that there are bound to be > older CPUs somewhere that have rng generation bugs that this will > expose. I'm not sure what you're concerned about. As far as I know, all of the CPU's have some variant of Confidential Compute have some kind of RDRAND-like command. And while we're using the term RDRAND, I'd extend this to any CPU architecture-level RNG instruction which can return failure if it is subject to exhaustion attacks. > How about making the failure contingent on the entropy pool > not having any entropy when the first random number is requested? We have tried to avoid characterizing entropy sources as "valid" or "invalid". First of all, it's rarely quite so black-and-white. Something which is vulnerable to someone who can spy on inter-packet arrival times by having a hardware tap between the CPU and the network switch, or a wireless radio right next to the device being attacked, might not be easily carried out by someone who doesn't have local physical access. So we may be measuring various things that might or might not have "entropy". In the case of Confidential Compute, we have declared that none of those other sources constitute "entropy". But that's not a decision that can be made by the computer, or at least until we've tracked the AGI problem. (At which point, we might have other problems --- "I'm sorry, I'm afraid I can't do that.") - Ted