From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75])
 by mx.groups.io with SMTP id smtpd.web10.17296.1669120203991733670
 for <devel@edk2.groups.io>;
 Tue, 22 Nov 2022 04:30:04 -0800
Authentication-Results: mx.groups.io;
 dkim=pass header.i=@zx2c4.com header.s=20210105 header.b=CKIwDPBb;
 spf=pass (domain: kernel.org, ip: 145.40.68.75, mailfrom: srs0=2rl2=3w=zx2c4.com=jason@kernel.org)
Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by ams.source.kernel.org (Postfix) with ESMTPS id E9B72B81AA0;
	Tue, 22 Nov 2022 12:30:01 +0000 (UTC)
Received: by smtp.kernel.org (Postfix) with ESMTPSA id 93A66C433D6;
	Tue, 22 Nov 2022 12:29:59 +0000 (UTC)
Authentication-Results: smtp.kernel.org;
	dkim=pass (1024-bit key) header.d=zx2c4.com header.i=@zx2c4.com header.b="CKIwDPBb"
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zx2c4.com; s=20210105;
	t=1669120197;
	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:
	 in-reply-to:in-reply-to:references:references;
	bh=+4NO04OJMbAp4umISiKZ3gZNtLPF48jbez+vyLFC5gk=;
	b=CKIwDPBbHjbtaKzYs3ZB6jxijTAu0HPvx4/pagAqQOOdrYKc/mhoXuq0GVMYdCxYX1b5xx
	IyptnIIxSJmfYlVnd10uhL26pzekthE7wrYqsK7T+vABBGVruyHwj1I1PYaU8KP344YQ+A
	G34Kb97dA9/5Z3+O/+dVplDfZuXQwEc=
Received: 
	by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id 17fc2e23 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO);
	Tue, 22 Nov 2022 12:29:57 +0000 (UTC)
Date: Tue, 22 Nov 2022 13:29:55 +0100
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
To: Pedro Falcato <pedro.falcato@gmail.com>
Cc: devel@edk2.groups.io, ardb@kernel.org,
	Liming Gao <gaoliming@byosoft.com.cn>,
	Rebecca Cran <rebecca@bsdio.com>,
	Pierre Gondois <pierre.gondois@arm.com>,
	Leif Lindholm <quic_llindhol@quicinc.com>,
	Sami Mujawar <sami.mujawar@arm.com>,
	Gerd Hoffmann <kraxel@redhat.com>
Subject: Re: [edk2-devel] [PATCH 3/3] OvmfPkg/OvmfX86: Enable RDRAND based EFI_RNG_PROTOCOL implementation
Message-ID: <Y3zAw3pHZ430OKF+@zx2c4.com>
References: <20221110134738.3798618-1-ardb@kernel.org>
 <20221110134738.3798618-4-ardb@kernel.org>
 <CAKbZUD30=NA-7uD-qQvLC0r4cYrDJStsB47q_MyLf75kh67cKw@mail.gmail.com>
MIME-Version: 1.0
In-Reply-To: <CAKbZUD30=NA-7uD-qQvLC0r4cYrDJStsB47q_MyLf75kh67cKw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline

Hi again,

On Tue, Nov 22, 2022 at 11:35:06AM +0000, Pedro Falcato wrote:
> We should probably also test for stupidly broken rdrand implementations
> like the notorious Zen 3 which always return 0xFFFFFFFF (per xkcd 221 ;)).

On this topic, if you did want to improve this part of that DXE, the
kernel's test for this is super dumb and basic but I think basically
gets the job done for the most pathological scenarios.

>>From arch/x86/kernel/cpu/rdrand.c:

  void x86_init_rdrand(struct cpuinfo_x86 *c)
  {
    enum { SAMPLES = 8, MIN_CHANGE = 5 };
    unsigned long sample, prev;
    bool failure = false;
    size_t i, changed;
  
    if (!cpu_has(c, X86_FEATURE_RDRAND))
      return;
  
    for (changed = 0, i = 0; i < SAMPLES; ++i) {
      if (!rdrand_long(&sample)) {
        failure = true;
        break;
      }
      changed += i && sample != prev;
      prev = sample;
    }
    if (changed < MIN_CHANGE)
      failure = true;
  
    if (failure) {
      clear_cpu_cap(c, X86_FEATURE_RDRAND);
      clear_cpu_cap(c, X86_FEATURE_RDSEED);
      pr_emerg("RDRAND is not reliable on this platform; disabling.\n");
    }
  }

Feel free to lift that into the DXE if you want. That should probably be
a different patch to this series, though, as I mentioned in my last
email. The CPUID check that you mentioned, however, seems like an
important prerequisite to this series.

Jason