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.web11.1306.1668134506656969881 for ; Thu, 10 Nov 2022 18:41:47 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@zx2c4.com header.s=20210105 header.b=F1V+fOI4; spf=pass (domain: kernel.org, ip: 145.40.68.75, mailfrom: srs0=23hl=3l=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 31388B823CA for ; Fri, 11 Nov 2022 02:41:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B4DBBC433D7 for ; Fri, 11 Nov 2022 02:41:42 +0000 (UTC) Authentication-Results: smtp.kernel.org; dkim=pass (1024-bit key) header.d=zx2c4.com header.i=@zx2c4.com header.b="F1V+fOI4" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zx2c4.com; s=20210105; t=1668134500; 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=bNgai+ZnE+jEYlqpX1T4iJDMblFsazAkPS/c/lan0tM=; b=F1V+fOI4uMr5+wuom9AT0PyYIhn7RU92QBtbgxo7WOvCSWOxySPiFb/wbr782Z8Lfs2rOy FzKicQr/xIeMVksSVfIPiK89q2TGmKGdl/dDqxHVSjolM8RnJrwhd0LBYksK8wqqPFXbjL NvxmVgDv5f5HP6fuvq5if01tAArG/oQ= Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id e8f44412 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for ; Fri, 11 Nov 2022 02:41:40 +0000 (UTC) Received: by mail-vs1-f44.google.com with SMTP id d185so4136764vsd.0 for ; Thu, 10 Nov 2022 18:41:39 -0800 (PST) X-Gm-Message-State: ACrzQf0o21lIcvme8Sry4I0kvNLuFvM9ElEcU+NO0aBVDiR70so9VGr5 TDx4elUSv7/2yxO/f28m1obxlc9spZ3K7B1UaGg= X-Google-Smtp-Source: AMsMyM4/4hfWQMPXhUkHQhEw3PMAAES6TyY/hpVquV2cQWnhm+TNYxuEA6cqO+gIPNAwHgBHloMgQJeBMX2WtD0IxBo= X-Received: by 2002:a05:6102:18c:b0:3aa:2fb3:dcac with SMTP id r12-20020a056102018c00b003aa2fb3dcacmr3875098vsq.55.1668134499017; Thu, 10 Nov 2022 18:41:39 -0800 (PST) MIME-Version: 1.0 References: <20221110134738.3798618-1-ardb@kernel.org> In-Reply-To: <20221110134738.3798618-1-ardb@kernel.org> From: "Jason A. Donenfeld" Date: Fri, 11 Nov 2022 03:41:27 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 0/3] OVMF: support EFI_RNG_PROTOCOL without virtio-rng To: Ard Biesheuvel Cc: devel@edk2.groups.io, Liming Gao , Rebecca Cran , Pierre Gondois , Leif Lindholm , Sami Mujawar , Gerd Hoffmann Content-Type: text/plain; charset="UTF-8" Hi Ard, On Thu, Nov 10, 2022 at 2:48 PM Ard Biesheuvel wrote: > > Currently, we only expose EFI_RNG_PROTOCOL when running under QEMU if it > exposes a virtio-rng device. This means that generic EFI apps or > loaders have no access to an entropy source if this device is > unavailable, unless they implement their own arch-specific handling to > figure out whether any CPU instructions or monitor calls can be used > instead. > > So let's wire those up as EFI_RNG_PROTOCOL implementations as well, > using the existing drivers and libraries. I tested this series on x86 and it appears to work as expected. Thanks for putting this together. So, Tested-by: Jason A. Donenfeld On very brief inspection, this also looks good, though I'm not really an EDK2 expert and my review isn't very thorough. But in case it helps, which you can take or leave, Reviewed-by: Jason A. Donenfeld My only question is how it chooses which RNG source to use in the event that multiple are available. I would think preferring virtio-rng if available is the right thing there. If it's based on the order of the items in the .dsc file, then it looks like this series is doing the right thing. Jason