On 06/22/16 10:34, Michael Brown wrote: > On 22/06/16 05:48, Laszlo Ersek wrote: >> In other words, the memcpy() quoted at the top copies 32 bytes into a >> 32-byte buffer, from a 20-byte buffer. It is the *source* buffer that is >> overflowed. >> >> As a result, bytes 20..31 of MacAddress (inclusive) are filled with >> garbage. > > Awesome debugging; thank you! I've pushed a fix at > > http://git.ipxe.org/ipxe.git/commitdiff/632e57f
Thanks! Gerd, do you think you can rebuild the iPXE binaries bundled with QEMU during the 2.7 soft/hard freeze <http://wiki.qemu.org/Planning/2.7>? This issue does not interfere with the primary functionality of the iPXE SNP oproms, but it causes hiccups for people who like to use the textual network configuration forms in OVMF. >> The question is then, why does it cause issues? The answer boggles the >> mind a bit. I mentioned in the earlier emails that the new Device >> Manager uses a different type of IFR opcode for the sub-form selection. >> I said that the opcode was callback-less, but much more importantly, >> these opcodes (= EFI_IFR_REF4 or "goto" opcodes) store a *textual* >> rendering of the device path that is associated with the HII package >> list / form set that the individual driver installs. > > Is this conceptually safe? Is the process of binary->text->binary > guaranteed to be lossless for any (valid) device path? Yes, it is. In the UEFI v2.6 spec, it is described under 9.6.1.3 Round-Trip Conversion (I recall that this section goes back to at least version 2.3.1C, but perhaps with a different section number.) That section brings two examples: * Text1 -> Binary1 -> Text2 -> Binary2 * Binary1 -> Text1 -> Binary2 -> Text2 In the first example, identity between Binary1 and Binary2 is guaranteed. Identity between Text1 and Text2 is not. In the second example, identity between Text1 and Text2 is guaranteed. Identity between Binary1 and Binary2 is also guaranteed (which is what you asked about). > Also, what happens on systems that don't have DevicePathToTextProtocol? I have no idea. Thanks! Laszlo _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
