Received-SPF: pass (google.com: domain of linux-kernel+bounces-55498-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Date: Tue, 06 Feb 2024 10:49:59 -0800
From: "H. Peter Anvin" <hpa@zytor.com>
To: "Dr. Greg" <greg@enjellic.com>,
        "Daniel P. Berrang??" <berrange@redhat.com>
CC: "Reshetova, Elena" <elena.reshetova@intel.com>,
        "Jason A. Donenfeld" <Jason@zx2c4.com>,
        "Hansen, Dave" <dave.hansen@intel.com>,
        "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>,
        Borislav Petkov <bp@alien8.de>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        "x86@kernel.org" <x86@kernel.org>, "Theodore Ts'o" <tytso@mit.edu>,
        Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>,
        "Nakajima, Jun" <jun.nakajima@intel.com>,
        Tom Lendacky <thomas.lendacky@amd.com>,
        "Kalra, Ashish" <ashish.kalra@amd.com>,
        Sean Christopherson <seanjc@google.com>,
        "linux-coco@lists.linux.dev" <linux-coco@lists.linux.dev>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] x86/random: Issue a warning if RDRAND or RDSEED fails
User-Agent: K-9 Mail for Android
In-Reply-To: <20240206120445.GA1247@wind.enjellic.com>
References: <20240130083007.1876787-1-kirill.shutemov@linux.intel.com> <20240130083007.1876787-2-kirill.shutemov@linux.intel.com> <CAHmME9qsfOdOEHHw_MOBmt6YAtncbbqP9LPK2dRjuOp1CrHzRA@mail.gmail.com> <DM8PR11MB57507611D651E6D7CBC2A2F3E77D2@DM8PR11MB5750.namprd11.prod.outlook.com> <88a72370-e300-4bbc-8077-acd1cc831fe7@intel.com> <CAHmME9oSQbd3V8+qR0e9oPb7ppO=E7GrCW-a2RN8QNdY_ARbSQ@mail.gmail.com> <Zbk6h0ogqeInLa_1@redhat.com> <DM8PR11MB575052B985CA97B29A443F9AE77C2@DM8PR11MB5750.namprd11.prod.outlook.com> <20240206011247.GA29224@wind.enjellic.com> <ZcHoKUElwXGPzrWb@redhat.com> <20240206120445.GA1247@wind.enjellic.com>
Message-ID: <00DF289B-1450-4272-9142-60643FAA852C@zytor.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable

On February 6, 2024 4:04:45 AM PST, "Dr=2E Greg" <greg@enjellic=2Ecom> wrot=
e:
>On Tue, Feb 06, 2024 at 08:04:57AM +0000, Daniel P=2E Berrang?? wrote:
>
>Good morning to everyone=2E
>
>> On Mon, Feb 05, 2024 at 07:12:47PM -0600, Dr=2E Greg wrote:
>> >=20
>> > Actually, I now believe there is clear evidence that the problem is
>> > indeed Intel specific=2E  In light of our testing, it will be
>> > interesting to see what your 'AR' returns with respect to an official
>> > response from Intel engineering on this issue=2E
>> >=20
>> > One of the very bright young engineers collaborating on Quixote, who
>> > has been following this conversation, took it upon himself to do some
>> > very methodical engineering analysis on this issue=2E  I'm the messen=
ger
>> > but this is very much his work product=2E
>> >=20
>> > Executive summary is as follows:
>> >=20
>> > - No RDRAND depletion failures were observable with either the Intel
>> >   or AMD hardware that was load tested=2E
>> >=20
>> > - RDSEED depletion is an Intel specific issue, AMD's RDSEED
>> >   implementation could not be provoked into failure=2E
>
>> My colleague ran a multithread parallel stress test program on his
>> 16core/2HT AMD Ryzen (Zen4 uarch) and saw a 80% failure rate in
>> RDSEED=2E
>
>Interesting datapoint, thanks for forwarding it along, so the issue
>shows up on at least some AMD platforms as well=2E
>
>On the 18 core/socket Intel Skylake platform, the parallelized
>depletion test forces RDSEED success rates down to around 2%=2E  It
>would appear that your tests suggest that the AMD platform fairs
>better than the Intel platform=2E
>
>So this is turning into even more of a morass, given that RDSEED
>depletion on AMD may be a function of the micro-architecture the
>platform is based on=2E  The other variable is that our AMD test
>platform had a substantially higher core count per socket, one would
>assume that would result in higher depletion rates, if the operative
>theory of socket common RNG infrastructure is valid=2E
>
>Unless AMD engineering understands the problem and has taken some type
>of action on higher core count systems to address the issue=2E
>
>Of course, the other variable may be how the parallelized stress test
>is conducted=2E  If you would like to share your implementation source
>we could give it a twirl on the systems we have access to=2E
>
>The continuing operative question is whether or not any of this ever
>leads to an RDRAND failure=2E
>
>We've conducted some additional tests on the Intel platform where
>RDSEED depletion was driven low as possible, ~1-2% success rates,
>while RDRAND depletion tests were being run simultaneously=2E  No RDRAND
>failures have been noted=2E
>
>So the operative question remains, why worry about this if RDRAND is
>used as the randomness primitive=2E
>
>We haven't seen anything out of Intel yet on this, maybe AMD has a
>quantifying definition for 'astronomical' when it comes to RDRAND
>failures=2E
>
>The silence appears to be deafening out of the respective engineering
>camps=2E=2E=2E :-)
>
>> > - AMD's RDRAND/RDSEED implementation is significantly slower than
>> >   Intel's=2E
>
>> Yes, we also noticed the AMD impl is horribly slow compared to
>> Intel, had to cut test iterations x100=2E
>
>The operative question is the impact of 'slow', in the absence of
>artifical stress tests=2E
>
>It would seem that a major question is what are or were the
>engineering thought processes on the throughput of the hardware
>randomness instructions=2E
>
>Intel documents the following randomness throughput rates:
>
>RDSEED: 3 Gbit/second
>RDRAND: 6=2E4 Gbit/second
>
>If there is the possibility of over-harvesting randomness, why not
>design the implementations to be clamped at some per core value such
>as a megabit/second=2E  In the case of the documented RDSEED generation
>rates, that would allow the servicing of 3222 cores, if my math at
>0530 in the morning is correct=2E
>
>Would a core need more than 128 kilobytes of randomness, ie=2E one
>second of output, to effectively seed a random number generator?
>
>A cynical conclusion would suggest engineering acquiesing to marketing
>demands=2E=2E=2E :-)
>
>> With regards,
>> Daniel
>
>Have a good day=2E
>
>As always,
>Dr=2E Greg
>
>The Quixote Project - Flailing at the Travails of Cybersecurity
>              https://github=2Ecom/Quixote-Project

You do realize, right, that the "deafening silence" is due to the need for=
 research and discussions on our part, and presumably AMD's=2E

In addition, quite frankly, your rather abusive language isn't exactly enc=
ouraging people to speak publicly based on immediately available and theref=
ore inherently incomplete and/or dated information, meaning that we have ha=
d to take even what discussions we might have been able to have in public w=
ithout IP concerns behind the scenes=2E

Yes, we work for Intel=2E No, we don't know every detail about every Intel=
 chip ever created off the top of my head, nor do we necessarily know the e=
xact person that is *currently* in charge of the architecture of a particul=
ar unit, nor is it necessarily true that even *that* person knows all the e=
xact properties of the behavior of their unit when integrated into a partic=
ular SoC, as units are modular by design=2E