As I pointed out before, on the ARM side there are a few intersecting issues with these changes. (On x86, this is mostly avoided due to the fact that RDRAND is universally supported)
- the RNDR instructions are not widely available yet, and support has not yet been added to ArmVirtQemu IIRC - the hypervisor TRNG service is only available when executing QEMU under KVM (true virtualization), or when running a firmware stack inside QEMU that implements it - QEMU itself does not expose this to guests when QEMU is acting as the hypervisor (TCG) - the virtio-rng device needs to be activated explicitly on the command line On the one hand, this means there are various ways to get entropy on /most/ systems, but it also means that the default use case of running QEMU on a non-ARM host (implying lack of KVM) without virtio-rng-pci will not have any EFI_RNG_PROTOCOL available. We might change this with RNDR but this will still leave some use cases behind (where a specific CPU is selected rather than 'max') If the result of this series is that systems with a EFI_RNG_PROTOCOL implementation cannot boot at all, this is a problem. If it means they cannot boot from the network, I'd be less worried. And while adding -device virtio-rng-pci to the CI command lines was long overdue, doing so doesn't fix other deployments of QEMU with the bundled firmware, so something has to be done. So we can at least clarify what the consequences are of attempting to run OVMF/ArmVirtQemu on a system that does not implement EFI_RNG_PROTOCOL at all? And then, make an informed decision on how to mitigate any resulting breakage? On Fri, 10 May 2024 at 19:13, Doug Flick via groups.io <dougflick=microsoft....@groups.io> wrote: > > At a high level, this isn't my project and I would look towards the > maintainers to provide guidance about the direction they want to go. > > However, > > In my opinion, this is a debate on Security vs Compatibility. I'm biased more > towards security, and I've tried to make it easy for a platform to understand > what is happening with PcdEnforceSecureRngAlgorithms . If we default to > default the platform never has the chance to understand what Rng Algorithms > they provide and if that is a problem for them. Default is obviously the most > compatible but it's also the one that may or may not be backed by something > insecure. Which is why I would prefer if a platform acknowledges that they > know it's backed by something secure or if not its an active decision. > > -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#118831): https://edk2.groups.io/g/devel/message/118831 Mute This Topic: https://groups.io/mt/106013302/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
