From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by mx.groups.io with SMTP id smtpd.web10.159.1668186219551048394 for ; Fri, 11 Nov 2022 09:03:39 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@zx2c4.com header.s=20210105 header.b=MI0nPoXT; spf=pass (domain: kernel.org, ip: 139.178.84.217, 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 dfw.source.kernel.org (Postfix) with ESMTPS id A00DB618C9 for ; Fri, 11 Nov 2022 17:03:38 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BC443C433C1 for ; Fri, 11 Nov 2022 17:03:37 +0000 (UTC) Authentication-Results: smtp.kernel.org; dkim=pass (1024-bit key) header.d=zx2c4.com header.i=@zx2c4.com header.b="MI0nPoXT" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=zx2c4.com; s=20210105; t=1668186214; 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=5jFPaLsQJ1xCnoFyOizg2tr0Hp/XmM84c99R3i7cb2c=; b=MI0nPoXT5lKmQULBiHJY9NZGGnug0fET1GUu/dgQ+K4//cHTFHlosMy5EZ/Qe1zUumSyV2 bDiccOPNDOXCw3IA6WTC2QYPG09HjIrDjhalY5A6DozBRANamgyi7tf0PPCOjasASOqMaw lwgT/HON0ui6coFK72W1fgypi6px70M= Received: by mail.zx2c4.com (ZX2C4 Mail Server) with ESMTPSA id 2e4fb96d (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO) for ; Fri, 11 Nov 2022 17:03:33 +0000 (UTC) Received: by mail-vk1-f177.google.com with SMTP id i15so2095170vka.0 for ; Fri, 11 Nov 2022 09:03:33 -0800 (PST) X-Gm-Message-State: ANoB5pniFfTXumeGOdt/2CJmEY7zyoNZvJrzxjS9chk9l4Hc2Q8ckn3h LeffCiYt0eZ9P5Kai/2v/Ln24Upf9u0mdhqkxxw= X-Google-Smtp-Source: AA0mqf4zkBbgO093ZimHMLIghvLqJqyhNy5Eu80U4q3TVzxBvetNf3s0nZeJUm5wOgzs1gn8/egAiREdVde5hlDNgiQ= X-Received: by 2002:a1f:170a:0:b0:3bb:ddbe:899d with SMTP id 10-20020a1f170a000000b003bbddbe899dmr1404355vkx.41.1668186212110; Fri, 11 Nov 2022 09:03:32 -0800 (PST) MIME-Version: 1.0 References: <20221110134738.3798618-1-ardb@kernel.org> In-Reply-To: From: "Jason A. Donenfeld" Date: Fri, 11 Nov 2022 18:03:20 +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 Fri, Nov 11, 2022 at 8:47 AM Ard Biesheuvel wrote: > > On Fri, 11 Nov 2022 at 03:41, Jason A. Donenfeld wrote: > > > > 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 > > > > Thanks. > > > 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. > > > > No, it is essentially arbitrary (but not random :-)) > > We already have special handling for the virtio RNG device in the BDS > code, because normally, EFI only dispatches drivers for devices that > it needs to boot (i..e, it walks the device path of the boot entry and > only connects a device to its driver at each stage if it needs to do > so to get to the next one) > > So connecting the virtio-rng device to its driver needs to be done > explicitly, or it may not be connected at all. We handle this in > ConnectVirtioPciRng() for x86 and some similar code exists in > ArmVirtPkg/Library/PlatformBootManagerLib/PlatformBm.c > > On ARM, the RngDxe wired up by this patch is backed by a hypervisor or > secure world firmware service, rather than by the VMM, so in the ARM > case, I think this one is the preferred one given that the VMM is > generally less trusted (although that distinction really only matters > for confidential compute). > > On x86, we use the RdRand instruction, which is also independent from > the VMM, so I'd assume this is the preferred choice, no? Or do you > have concerns about broken implementations? > > Another distinction is that the ARM version only implements > EFI_RNG_ALGORITHM_RAW, whereas x86 also implements > EFI_RNG_ALGORITHM_SP800_90_CTR_256_GUID. (virtio-rng also only > implements EFI_RNG_ALGORITHM_RAW). This likely does not matter at all, > but it is nevertheless good to call out while we decide which driver > to give precedence. > > Another thing to note is that we generally try very hard to do as > little as possible at boot time (although you might get a different > impression when looking at the code :-)). So simply skipping the > virtio-rng driver dispatch if some implementation of EFI_RNG_PROTOCOL > is already available seems appropriate from that angle as well. That all seems reasonable to me, your arguments about secure world etc. So in case there's another rng dxe available, we can just skip the (more expensive) virtio initialization, and this will make things generally simpler too. Sounds alright. Jason