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.web09.2998.1659607112985576154 for ; Thu, 04 Aug 2022 02:58:33 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=nhUTV6Zq; spf=pass (domain: kernel.org, ip: 145.40.68.75, mailfrom: ardb@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 BD25AB824E4 for ; Thu, 4 Aug 2022 09:58:30 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8971BC433D6 for ; Thu, 4 Aug 2022 09:58:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1659607109; bh=pjhV12I763OJiKz7onkiCIFYZlflW7771eUzPb7BGvQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=nhUTV6ZqRScnCzPI08c7AQbds8LjQDUst2kvtbhYlfYKci2MmEJ4yWwsh4DBfvkad El+VlkBIX05sXbbui0qnnTMybTeINje4FNwvFiFIKOfqFs4rPcelOb5afeayqaaWOh cO8tsGpUEWHni9ibSpmbxRqSSXfu07j9dVJlP7nOs0qk7ec4ZHLBGjqpOM8R27opMk Esb3mwBY8xeg0kFP8RT/fZ5hX/jTkpBq4e5pmg4PPsGKmzqvA8fZIzFebGOd0fQ7rW dHdaKMMy1Q/aWpPd0ImplLLdULXgwpmWvbipIWBSZn/X9Kp1rqaB36nrmf57+U9CFd milXiMsq6L6ZQ== Received: by mail-oa1-f46.google.com with SMTP id 586e51a60fabf-10ee900cce0so11785292fac.5 for ; Thu, 04 Aug 2022 02:58:29 -0700 (PDT) X-Gm-Message-State: ACgBeo3vjatMchwd9Ic6sL1nfP3ZVmBOgtvW/2OZumOwTUkB6RdtuOiR ejeTtOq8RZfcgjtrZY2R2UZm1Clj9P4Vi+NmHA4= X-Google-Smtp-Source: AA6agR7PmYBuVzcWn2xucEPPoZOrEpIciVFS8ekg/wOD7bPIPrUgn11KMPi0msGePlYpBSpg914am08eztF6K4YSfCY= X-Received: by 2002:a05:6870:b403:b0:10e:7914:adb with SMTP id x3-20020a056870b40300b0010e79140adbmr466000oap.126.1659607108666; Thu, 04 Aug 2022 02:58:28 -0700 (PDT) MIME-Version: 1.0 References: <20220804025239.918263-1-yuanyu@google.com> <087048c2-d9d7-c50b-8b62-8bfe1267e4a0@redhat.com> In-Reply-To: <087048c2-d9d7-c50b-8b62-8bfe1267e4a0@redhat.com> From: "Ard Biesheuvel" Date: Thu, 4 Aug 2022 11:58:17 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [edk2-devel] [PATCH v1 0/2] Add support to disable VirtIo net at runtime To: edk2-devel-groups-io , Laszlo Ersek Cc: Yuan Yu , Ard Biesheuvel , Jordan Justen , Anthony Perard , Julien Grall , Gerd Hoffmann , Pawel Polawski , Oliver Steffen , Jiewen Yao Content-Type: text/plain; charset="UTF-8" On Thu, 4 Aug 2022 at 07:55, Laszlo Ersek wrote: > > On 08/04/22 04:52, Yuan Yu wrote: > > Currently networking can only be enabled/disabled at compile time. This > > patch series will add support to disable VirtIo net at runtime even if > > the functionality is built into binary at compile time. > > > > This will enable VMM to reduce attack surface without recompilation. > > > > The changes can be seen at: > > https://github.com/yyu/edk2/tree/network_cfg_lib_v1 > > > > Cc: Ard Biesheuvel > > Cc: Jordan Justen > > Cc: Laszlo Ersek > > Cc: Anthony Perard > > Cc: Julien Grall > > > > Yuan Yu (2): > > OvmfPkg: Introduce NetworkCfgLib > > OvmfPkg: Use PcdNetworkSupport to enable/disable VirtIo net > > > > OvmfPkg/OvmfPkg.dec | 3 ++ > > OvmfPkg/OvmfPkgX64.dsc | 7 ++++- > > OvmfPkg/Library/NetworkCfgLib/NetworkCfgLib.inf | 29 ++++++++++++++++++ > > OvmfPkg/VirtioNetDxe/VirtioNet.inf | 3 ++ > > OvmfPkg/Library/NetworkCfgLib/NetworkCfgLib.c | 32 ++++++++++++++++++++ > > OvmfPkg/VirtioNetDxe/EntryPoint.c | 10 ++++++ > > 6 files changed, 83 insertions(+), 1 deletion(-) > > create mode 100644 OvmfPkg/Library/NetworkCfgLib/NetworkCfgLib.inf > > create mode 100644 OvmfPkg/Library/NetworkCfgLib/NetworkCfgLib.c > > > > Well I've not been reviewing upstream edk2 patches for a while, but the > virtio-net driver is still very close to my heart, so this patch kind of > hits a nerve. > Welcome back old friend! > I think I disagree with the idea and the implementation both. > > Minimally, the idea needs a much better elaboration -- what is the > threat model? Do you want to protect the host from the guest, or the > guest from the host? Or something else? How does controlling a single > SNP driver via fw_cfg (which is also dictated by the host) help? > I have to confess that I was the one who suggested this approach to Yuan internally, but mainly to get the discussion going, as I was anticipating some pushback, just not from you :-) 'Reducing the attack surface' is probably not the most accurate characterization of the purpose. We are simply looking for a way to disable network boot from the vmm/host side without affecting how/which network interfaces the guest exposes to the OS. > Regarding the implementation: there is much more to networking in edk2 > than VirtioNetDxe. UEFI driver binaries (SNP drivers) built from iPXE > can be passed in via the NICs' option ROMs. SNP drivers can be loaded > from the UEFI system partition (for example, Intel's binary-only driver > for QEMU's e1000* cards). > > If you can control this fw_cfg switch from the VMM side, you can also > control the VMM enough to simply *not give* a virtio-net device to the > guest. Then the driver (it being a UEFI driver following the UEFI driver > model) will simply not have anything to bind. > Sure, but then the OS will lose networking as well. We just want to remove the ability to network boot without impacting anything else that relies on virtio-net > Sorry I find this approach very wrong. If you really need it for your > particular VMM, I kind of suggest not upstreaming this patch. I see it > as a step backwards for the upstream project. > If there are better ways to achieve this, we're all ears, but I think that having a PCD which could either be fixed at build and compiled out completely, or be set via a NULL library resolution, or even be wired to a menu option (using PcdsDynamicHii] is a rather low-impact but flexible way to go about this.