From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from blyat.fensystems.co.uk (blyat.fensystems.co.uk [54.246.183.96]) by mx.groups.io with SMTP id smtpd.web11.176989.1598199871353404657 for ; Sun, 23 Aug 2020 09:24:32 -0700 Authentication-Results: mx.groups.io; dkim=missing; spf=pass (domain: ipxe.org, ip: 54.246.183.96, mailfrom: mcb30@ipxe.org) Received: from dolphin.home (unknown [IPv6:2a00:23c6:5495:5e00:beee:7bff:fe8d:f03d]) by blyat.fensystems.co.uk (Postfix) with ESMTPSA id 2410542AC3; Sun, 23 Aug 2020 16:24:27 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH v1] NetworkPkg/UefiPxeBcDxe: Fix PXE_BOOT_SERVERS usage in boot info parse flow To: Laszlo Ersek , devel@edk2.groups.io, maciej.rabeda@linux.intel.com Cc: Jiaxin Wu , Siyuan Fu , Seven.ding@lcfuturecenter.com References: <20200819165338.681-1-maciej.rabeda@linux.intel.com> <2dde2087-e291-0232-62e2-a30cdf4e09b2@redhat.com> <93ed808c-8414-310d-c065-36a92ebea2e7@redhat.com> From: "Michael Brown" Message-ID: <2d049486-372c-ed7d-ab41-2300211868aa@ipxe.org> Date: Sun, 23 Aug 2020 17:24:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <93ed808c-8414-310d-c065-36a92ebea2e7@redhat.com> X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on blyat.fensystems.co.uk Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit On 21/08/2020 12:19, Laszlo Ersek wrote: > On 08/19/20 20:46, Michael Brown wrote: >> FWIW, iPXE's equivalent logic (based on a combination of what the PXE >> spec says and what the Intel reference PXE implementation actually does, >> which is not necessarily the same thing) is to *ignore* PXE_BOOT_SERVERS >> if a DHCP filename is available and option 43 tag 6 bit 3 is *set*. > > Sorry, I expressed my concern incorrectly (I think I was tripped up by > the typo in Maciej's commit message). My fault; I should have read more closely. > It's about bit#2 in PXE_DISCOVERY_CONTROL. > > The question is whether bit#2 is *equivalent* to adhering to > PXE_BOOT_SERVERS ("if, and only if"). > > When bit#2 is set, the spec says we must. OK. > > When bit#2 is clear, the spec doesn't say anything. So two > interpretations are possible, "we still may consider PXE_BOOT_SERVERS", > and "we must not consider PXE_BOOT_SERVERS". iPXE's interpretation is: - if bit 2 is set then the subsequent boot server discovery will ignore replies from any servers not mentioned (for the selected boot server type) in PXE_BOOT_SERVERS - if bit 2 is clear then the subsequent boot server discovery will accept replies from any server This seems consistent with the spec paragraph stating: "If PXE_DISCOVERY_CONTROL bit 2 is set, the client may still use multicast and broadcast discovery (if it is permitted by bits 0 and 1); but the client may only accept replies from servers that are identified in the PXE_BOOT_SERVERS option." > Anyway -- I'm sending this just to explain my earlier email. My main > point remains: > > http://mid.mail-archive.com/11640b08-6f42-e4d8-356d-91d4bdf86c2c@redhat.com > > (alt link: https://edk2.groups.io/g/devel/message/64530) Resolving as INVALID seems appropriate to me. Thanks, Michael