From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by mx.groups.io with SMTP id smtpd.web11.26556.1673450591297707171 for ; Wed, 11 Jan 2023 07:23:11 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=bS0VLWK4; spf=pass (domain: redhat.com, ip: 170.10.129.124, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1673450590; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0jHTWf+R7nwxSi5Ge9KdVSdq8N+XI7Xpzpe4wTHjL+s=; b=bS0VLWK4DOvW8LPBEmd3d3dJh09+GEqjjGt1bmP5qND38y5xwFVa/VclhuOdpl9Tq6zKk+ 1Whk/nxAhj/kfxUA2UbqEHsIJ6b7Cloz0l3Q7dboiUZTliEz45oXJjQXbr3VJx4ayyjyg3 24y+rEAZ3x66izdBarcXz4GMbXT/OtU= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-581-zQ-930baNxKQrtGDbanlXQ-1; Wed, 11 Jan 2023 10:23:07 -0500 X-MC-Unique: zQ-930baNxKQrtGDbanlXQ-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id A8327101D22A; Wed, 11 Jan 2023 15:23:06 +0000 (UTC) Received: from [10.39.192.40] (unknown [10.39.192.40]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AB531422A4; Wed, 11 Jan 2023 15:23:04 +0000 (UTC) Message-ID: Date: Wed, 11 Jan 2023 16:23:03 +0100 MIME-Version: 1.0 Subject: Re: [edk2-devel] [PATCH 0/3] OVMF: support EFI_RNG_PROTOCOL without virtio-rng To: devel@edk2.groups.io, Jason@zx2c4.com, Ard Biesheuvel Cc: Liming Gao , Rebecca Cran , Pierre Gondois , Leif Lindholm , Sami Mujawar , Gerd Hoffmann , pedro.falcato@gmail.com References: <20221110134738.3798618-1-ardb@kernel.org> From: "Laszlo Ersek" In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.5 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 1/10/23 19:19, Jason A. Donenfeld via groups.io wrote: > Could we get this merged? Sorry to barge in -- I have *zero* complaints regarding this particular series, so whatever I'm about to say regards *further* BDS customizations. Please feel free to go ahead with merging this one, as far as I'm concerned. So, picking up the thread at . The argument in that thread was made that "RDRAND-based protocol is better than nothing". However, the most recent idea, favoring the RDRAND-based protocol implementation over the virtio-rng-based one, seems to enable a degradation too, of EFI-time randomness. Most commonly, virtio-rng is fed on the host side from /dev/urandom, which *I think* means that the EFI_RNG_PROTOCOL from VirtioRngDxe will expose all the "good quality entropy", pre-boot, that the host-side Linux kernel collects from *multiple* sources. If the consumer of EFI_RNG_PROTOCOL in the guest doesn't do its own mixing, it sill gets the good stuff. That could potentially be degraded by relying on RDRAND only, in the guest. I can't propose any particular priority ordering mechanism for the platform firmware to produce exactly one EFI_RNG_PROTOCOL. Normally I'd suggest any viable mechanism for the platform to block or to delay "SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.inf" -- introducing a new dynamic PCD for early exit, adding a new protocol dependency to its DEPEX, postponing its protocol installation to an event group notification function or a protocol installation notification. Note that RngDxe.inf is a DXE_DRIVER, so it produces its protocol in its entry point function, so for blocking it or short-circuiting it, one of these measures would be needed. It could even be turned into a UEFI_DRIVER, one that would bind a synthetic VenHw device path. But, I'm not proposing any of those right now, because I imagine there are advantages to having EFI_RNG_PROTOCOL in the DXE phase, that is, *before* the BDS phase. VirtioRngDxe is a UEFI_DRIVER module that follows the UEFI driver model; in other words, it won't do anything beyond exposing the EFI_DRIVER_BINDING_PROTOCOL until BDS connects it. I think that should be sufficient for most cases, even (for example) possibly providing randomness for TLS in UEFI HTTPS Boot. But I vaguely remember we had wished for randomness being available earlier than BDS. "SecurityPkg/RandomNumberGenerator/RngDxe/RngDxe.inf" can fill that role, VirtioRngDxe can't. So best would be if both could coexist, and VirtioRngDxe took effect *whenever* it were available. Of course the UEFI spec allows for a client to collect all instances of EFI_RNG_PROTOCOL, and then to call GetInfo() on each, but that's hardly enough for a client to pick the one it thinks is "more secure". So one way or another we might want to control this still at the platform level, where we can form ideas about both protocol providers, *and* perhaps even determine if we *actually need* pre-BDS randomness. BDS could try connecting the virtio-rng device. If that failed, it could try "unblocking" RngDxe. If RngDxe were a UEFI driver following the UEFI driver model (see the VenHw option above), this would not be hard to do, with a "fallback" gBS->ConnectController() call. (Regarding VenHw vs. VenMedia vs. VenMsg -- RngDxe uses an RNG that's built into the processor, wich is arguably "inside the resource domain" of the system. So VenHw seems the right choice.) RngDxe could perhaps be restructured for the addition of a new entry point (new INF file and new entry point C file), so that it remain compatible with existent platforms that already consume it (and want it to remain a DXE_DRIVER). BDS could also signal an event group or install a synthetic protocol, so that the notification function in RngDxe expose EFI_RNG_PROTOCOL in response. Unblocking a DXE_DRIVER's DEPEX from BDS seems more cumbersome, by installing a dependend-upon synthetic protocol; I believe we might have to call gDS->Dispatch() manually then. And if a dynamic PCD caused RngDxe to exit early, we couldn't undo that from BDS at all. Thanks for considering, Laszlo