From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail05.groups.io (mail05.groups.io [45.79.224.7]) by spool.mail.gandi.net (Postfix) with ESMTPS id E46DCAC19C9 for ; Mon, 14 Oct 2024 19:08:00 +0000 (UTC) DKIM-Signature: a=rsa-sha256; bh=Inx04sHamJHpMUkzNLAXXevMoKyjgJ6U3XOBVEdLjwk=; c=relaxed/simple; d=groups.io; h=MIME-Version:From:Date:Message-ID:Subject:To:Cc:Precedence:List-Subscribe:List-Help:Sender:List-Id:Mailing-List:Delivered-To:Resent-Date:Resent-From:Reply-To:List-Unsubscribe-Post:List-Unsubscribe:Content-Type:Content-Transfer-Encoding; s=20240830; t=1728932880; v=1; x=1729192079; b=GrLZTlTa7+Bh9WqmJ1tq68GFAPfHwvKbbqiNm9px3DJdDdHM7YwxTkXbacsg4d4phmUjP7NF ciOz/pczr7fqWGPM21wMlu5xGVjMRCSKXfmK7GzisTsyri1SYWS5SnHUlhUnRc7H8OEbAMIMaez XZ9gQju4ZeBOKZHHCmjTTkBm7lP1nYAjMTqVGvOtj3+WX5NIvGv5D8yw4bZTQoIWrO6MjA6jGpN AKwq4eIaNXKMTYYrzY770iY4dWYJdbdo6HFyjn6kH5HS0vaPfqFSfQ37KLLC0TUOmZBB4bzMi1r 416oyg1eSWnM9DcoQ6RBQGd25fq083MwzZhgWEjUt+Nkw== X-Received: by 127.0.0.2 with SMTP id geESYY7687511xOSsOWDbkGI; Mon, 14 Oct 2024 12:07:59 -0700 X-Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by mx.groups.io with SMTP id smtpd.web10.3113.1728932878746912208 for ; Mon, 14 Oct 2024 12:07:58 -0700 X-Received: from mail-lf1-f72.google.com (mail-lf1-f72.google.com [209.85.167.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-626-tAcYBuixNmqMbYfLdQKf-A-1; Mon, 14 Oct 2024 15:07:56 -0400 X-MC-Unique: tAcYBuixNmqMbYfLdQKf-A-1 X-Received: by mail-lf1-f72.google.com with SMTP id 2adb3069b0e04-539fdef0040so224708e87.0 for ; Mon, 14 Oct 2024 12:07:56 -0700 (PDT) X-Gm-Message-State: GAXlvB0YSwUTK7ZFUfdBAvicx7686176AA= X-Received: by 2002:a05:6512:1048:b0:535:6942:29ea with SMTP id 2adb3069b0e04-539e54d82b2mr4449362e87.11.1728932874777; Mon, 14 Oct 2024 12:07:54 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHE2E7dJyJl2wcno+a+OR1o7BdVFYhDCpxtKZbJ9lG6YFwVpaHfImMfkT9fZL8UIkHLJFxRFc6eGDJ/P8o8AA4= X-Received: by 2002:a05:6512:1048:b0:535:6942:29ea with SMTP id 2adb3069b0e04-539e54d82b2mr4449341e87.11.1728932874341; Mon, 14 Oct 2024 12:07:54 -0700 (PDT) MIME-Version: 1.0 From: "Oliver Steffen" Date: Mon, 14 Oct 2024 21:07:43 +0200 Message-ID: Subject: [edk2-devel] OVMF Issue with Netboot, VirtioRng, and both COM1/COM2 configured To: devel@edk2.groups.io, Stefano Garzarella Cc: Gerd Hoffmann , Jiewen Yao , Zachary Clark-williams , Saloni Kasbekar , Doug Flick , Daniel Berrange , Cong Li X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Precedence: Bulk List-Subscribe: List-Help: Sender: devel@edk2.groups.io List-Id: Mailing-List: list devel@edk2.groups.io; contact devel+owner@edk2.groups.io Resent-Date: Mon, 14 Oct 2024 12:07:58 -0700 Resent-From: osteffen@redhat.com Reply-To: devel@edk2.groups.io,osteffen@redhat.com List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-GND-Status: LEGIT Authentication-Results: spool.mail.gandi.net; dkim=pass header.d=groups.io header.s=20240830 header.b=GrLZTlTa; dmarc=fail reason="SPF not aligned (relaxed), DKIM not aligned (relaxed)" header.from=redhat.com (policy=none); spf=pass (spool.mail.gandi.net: domain of bounce@groups.io designates 45.79.224.7 as permitted sender) smtp.mailfrom=bounce@groups.io Since the PixieFail CVE fixes, a strong random number generator is required to use network functionality, such as booting via PXE or HTTP. On modern x86_64 CPUs this is not a problem because these support the RDRAND instruction. On older models one needs to add a virtio-rng device otherwise network initialization fails. We now observe a very strange problem [1]: Network initialization still fails when adding a virtio-rng to a VM with an old CPU, under certain hardware configurations. For example in combination with COM1 and COM2 isa-serial port, while it works if only one of them is there (it doesn't matter which one, as long as they are not both configured in QEMU). Steps to reproduce the issue: Use a recent edk2 master branch, for example 596773f5e33e. We used qemu-8.2.7-1.fc40. Build OVMF for X64 like this: build -t GCC5 -b DEBUG -a X64 \ -p OvmfPkg/OvmfPkgX64.dsc \ -D NETWORK_HTTP_BOOT_ENABLE=3DTRUE \ -D NETWORK_IP6_ENABLE=3DTRUE \ -D NETWORK_TLS_ENABLE=3DTRUE \ -D NETWORK_ALLOW_HTTP_CONNECTIONS=3DTRUE \ -D DEBUG_PRINT_ERROR_LEVEL=3D0xFFFFFFFF Run QEMU with a CPU that does not feature RDRAND: qemu-system-x86_64 \ -machine q35,accel=3Dkvm -m 1G -display none -nodefaults \ -drive file=3DOVMF_CODE.fd,if=3Dpflash,format=3Draw,unit=3D0,readonly=3Do= n \ -drive file=3DOVMF_VARS.fd,if=3Dpflash,format=3Draw,unit=3D1,readonly=3Do= n \ -chardev file,id=3Dfw,path=3D"firmware.log" -device isa-debugcon,iobase=3D0x402,chardev=3Dfw \ -drive file=3DUefiShell.iso,format=3Draw,if=3Dnone,media=3Dcdrom,id=3Ddri= ve-cd1,readonly=3Don \ -device ide-cd,drive=3Ddrive-cd1,id=3Dcd1,bootindex=3D1 \ -netdev user,id=3Dnet0 -device virtio-net-pci,netdev=3Dnet0,bootindex=3D2= \ -device virtio-rng-pci \ -serial stdio \ -serial null \ -cpu core2duo The attached CD-Rom image [2] contains a EFI Shell executable that is boote= d. >From the shell one can investigate the available boot options: # bcfg boot dump Expectation: PXE and HTTP options are listed. Observation: No network boot options present. Changing the CPU model on the QEMU command line to =E2=80=9Cmax=E2=80=9D ma= kes PXE and HTTP options available. We suspected that a virtio-rng-pci is not working and network support is unavailable due to the lack of an RNG. But the same can be achieved by removing the second serial port (=E2=80=9C-serial null=E2=80=9D) while keeping the CPU model. We can=E2=80= =99t explain this at all. While network boot can be achieved by changing other parts of the command line too (modifying bootindex, for example) it is very strange that simply the serial port configuration influences network boot. Bisection: Doing a bisection, the commit that introduces this problem is 4c4ceb2ceb ("NetworkPkg: SECURITY PATCH CVE-2023-45237"). The problem seems to be pre-existing, but as of this commit, DxeNetLib has a new Depex with gEfiRngProtocolGuid (3152BCA5-EADE-433D-862E-C01CDC291F44) since it is now a consumer. Producers can be VirtioRng (when the device is present) and RngDxe (when the CPU supports for example instructions like RDRAND). Removing the Depex, just for confirmation, solves the problem, but of course DxeNetLib fails on an assert where it expects to find random generators. Observing the logs [3,4] with DEBUG_DISPATCH enabled and adding some printing in VirtioRng, we noticed that in both cases (PXE working or not), VirtioRng is started at the same time in the log (see on both logs attached at line 22240), but with both COM1 and COM2 we no longer see any dispatcher messages after VirtioRng has started, while we see them when there is only one of them. Just this last stage of the dispatcher will load the network modules, finding the dependency with gEfiRngProtocolGuid true. Any help is very much appreciated! Regards, Stefano and Oliver [1] https://issues.redhat.com/browse/RHEL-58631 [2] https://osteffen.fedorapeople.org/OvmfNetbootRngIssue/UefiShell.iso [3] https://osteffen.fedorapeople.org/OvmfNetbootRngIssue/edk2_PXE_issue_CO= M1_COM2.log [4] https://osteffen.fedorapeople.org/OvmfNetbootRngIssue/edk2_PXE_working_= COM1.log -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#120623): https://edk2.groups.io/g/devel/message/120623 Mute This Topic: https://groups.io/mt/109008158/7686176 Group Owner: devel+owner@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io] -=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-=3D-