~roguescholar/ipxe/trunk : changes

~roguescholar/ipxe/trunk » Changes from revision 6322

From Revision 6322 to 6303

Rev	Summary	Authors	Date
6322	[efi] Extend PE header size to cover space up to first secti... [efi] Extend PE header size to cover space up to first section Hybrid bzImage and UEFI binaries (such as wimboot) may place sections at explicit offsets within the PE file, as described in commit b30a098 ("[efi] Use load memory address as file offset for hybrid binaries"). This can leave a gap after the PE headers that is not covered by any section. It is not entirely clear whether or not such gaps are permitted in binaries submitted for Secure Boot signing. To minimise potential problems, extend the PE header size to cover any space before the first explicitly placed section. Signed-off-by: Michael Brown <mcb30@ipxe.org>	Michael Brown	4 months ago
6321	[efi] Fix dependency list construction in EDK2 header import... [efi] Fix dependency list construction in EDK2 header import script Signed-off-by: Michael Brown <mcb30@ipxe.org>	Michael Brown	4 months ago
6320	[efi] Maximise image base address [efi] Maximise image base address iPXE images are linked with a starting virtual address of zero. Other images (such as wimboot) may use a non-zero starting virtual address. There is no direct equivalent of the PE ImageBase address field within ELF object files. Choose to use the highest possible address that accommodates all sections and the PE header itself, since this will minimise the memory allocated to hold the loaded image. Signed-off-by: Michael Brown <mcb30@ipxe.org>	Michael Brown	4 months ago
6319	[efi] Do not assume canonical PE section ordering [efi] Do not assume canonical PE section ordering The BaseOfCode (and, in PE32, BaseOfData) fields imply an assumption that binaries are laid out as code followed by initialised data followed by uninitialised data. This assumption may not be valid for complex binaries such as wimboot. Remove this implicit assumption, and use arguably justifiable values for the assorted summary start and size fields within the PE headers. Signed-off-by: Michael Brown <mcb30@ipxe.org>	Michael Brown	4 months ago
6318	[efi] Treat 16-bit sections as hidden in hybrid binaries [efi] Treat 16-bit sections as hidden in hybrid binaries Hybrid bzImage and UEFI binaries (such as wimboot) may include 16-bit sections such as .bss16 that do not need to consume an entry in the PE section list. Treat any such sections as hidden. Signed-off-by: Michael Brown <mcb30@ipxe.org>	Michael Brown	4 months ago
6317	[efi] Place PE debug information in a hidden section [efi] Place PE debug information in a hidden section The PE debug information generated by elf2efi is used only to hold the image filename, and the debug information is located via the relevant data directory entry rather than via the section table. Make the .debug section a hidden section in order to save one entry in the PE section list. Choose to place the debug information in the unused space at the end of the PE headers, since it no longer needs to satisfy the general section alignment constraints. Signed-off-by: Michael Brown <mcb30@ipxe.org>	Michael Brown	4 months ago
6316	[efi] Fix recorded overall size of headers in NT optional he... [efi] Fix recorded overall size of headers in NT optional header Commit 1e4c378 ("[efi] Shrink size of data directory in PE header") reduced the number of entries used in the data directory and reduced the recorded size of the NT "optional" header, but did not also adjust the recorded overall size of the PE headers, resulting in unused space between the PE headers and the first section. Fix by reducing the initial recorded size of the PE headers by the size of the omitted data directory entries. Signed-off-by: Michael Brown <mcb30@ipxe.org>	Michael Brown	4 months ago
6315	[efi] Write out PE header only after writing sections [efi] Write out PE header only after writing sections Hybrid bzImage and UEFI binaries (such as wimboot) include a bzImage header within a section starting at offset zero, with the PE header effectively occupying unused space within this section. Allow for this by treating a section placed at offset zero as hidden, and by deferring the writing of the PE header until after the output sections have been written. Signed-off-by: Michael Brown <mcb30@ipxe.org>	Michael Brown	4 months ago
6314	[efi] Use load memory address as file offset for hybrid bina... [efi] Use load memory address as file offset for hybrid binaries Hybrid bzImage and UEFI binaries (such as wimboot) may be loaded as a single contiguous blob without reference to the PE headers, and the placement of sections within the PE file must therefore be known at link time. Use the load memory address (extracted from the ELF program headers) to determine the physical placement of the section within the PE file when generating a hybrid binary. Signed-off-by: Michael Brown <mcb30@ipxe.org>	Michael Brown	4 months ago
6313	[efi] Mark PE images as large address aware [efi] Mark PE images as large address aware The images generated by elf2efi can be loaded anywhere in the address space, and are not limited to the low 2GB. Indicate this by setting the "large address aware" flag within the PE header, for compatibility with EFI images generated by the EDK2 build process. (The EDK2 PE loader does not ever check this flag, and it is unlikely that any other EFI PE loader ever does so, but we may as well report it accurately.) Signed-off-by: Michael Brown <mcb30@ipxe.org>	Michael Brown	4 months ago
6312	[efi] Set NXCOMPAT bit in PE header [efi] Set NXCOMPAT bit in PE header Indicate that the binary is compatible with W^X protections by setting the NXCOMPAT bit in the DllCharacteristics field of the PE header. Signed-off-by: Michael Brown <mcb30@ipxe.org>	Michael Brown	4 months ago
6311	[efi] Treat writable sections as data sections [efi] Treat writable sections as data sections Hybrid bzImage and UEFI binaries (such as wimboot) may include 16-bit executable code that is opaque data from the perspective of a UEFI PE binary, as described in wimboot commit fe456ca ("[efi] Use separate .text and .data PE sections"). The ELF section will be marked as containing both executable code and writable data. Choose to treat such a section as a data section rather than a code section, since that matches the expected semantics for ELF files that we expect to process. Signed-off-by: Michael Brown <mcb30@ipxe.org>	Michael Brown	4 months ago
6310	[efi] Update to current EDK2 headers [efi] Update to current EDK2 headers Signed-off-by: Michael Brown <mcb30@ipxe.org>	Michael Brown	4 months ago
6309	[cloud] Add utility script to read iPXE output from INT13CON... [cloud] Add utility script to read iPXE output from INT13CON partition Some AWS instance types still do not support serial console output or screenshots. For these instance types, the only viable way to extract debugging information is to use the INT13 console (which is already enabled via CONFIG=cloud for all AWS images). Obtaining the INT13 console output can be very cumbersome, since there is no direct way to read from an AWS volume. The simplest current approach is to stop the instance under test, detach its root volume, and reattach the volume to a Linux instance in the same region. Add a utility script aws-int13con to retrieve the INT13 console output by creating a temporary snapshot, reading the first block from the snapshot, and extracting the INT13 console partition content. Signed-off-by: Michael Brown <mcb30@ipxe.org>	Michael Brown	5 months ago
6308	[cloud] Add ability to overwrite existing AMI images [cloud] Add ability to overwrite existing AMI images AMI names must be unique within a region. Add a --overwrite option that allows an existing AMI of the same name to be deregistered (and its underlying snapshot deleted). Signed-off-by: Michael Brown <mcb30@ipxe.org>	Michael Brown	5 months ago
6307	[eapol] Limit number of EAPoL-Start packets transmitted per ... [eapol] Limit number of EAPoL-Start packets transmitted per attempt Signed-off-by: Michael Brown <mcb30@ipxe.org>	Michael Brown	5 months ago
6306	[eapol] Delay EAPoL-Start while waiting for EAP to complete [eapol] Delay EAPoL-Start while waiting for EAP to complete EAP exchanges may take a long time to reach a final status, especially when relying upon MAC Authentication Bypass (MAB). Our current behaviour of sending EAPoL-Start every few seconds until a final status is obtained can prevent these exchanges from ever completing. Fix by redefining the EAP supplicant state to allow EAPoL-Start to be suppressed: either temporarily (while waiting for a full EAP exchange to complete, in which case we need to eventually resend EAPoL-Start if the final Success or Failure packet is lost), or permanently (while waiting for the potentially very long MAC Authentication Bypass timeout period). Signed-off-by: Michael Brown <mcb30@ipxe.org>	Michael Brown	5 months ago
6305	[pci] Require discovery of a PCI device when determining usa... [pci] Require discovery of a PCI device when determining usable PCI APIs The PCI cloud API (PCIAPI_CLOUD) currently selects the first PCI API that successfully discovers a PCI device address range. The ECAM API may discover an address range but subsequently be unable to map the configuration space region, which would result in the selected PCI API being unusable. Fix by instead selecting the first PCI API that can be successfully used to discover a PCI device. Signed-off-by: Michael Brown <mcb30@ipxe.org>	Michael Brown	5 months ago
6304	[pci] Check that ECAM configuration space is within reachabl... [pci] Check that ECAM configuration space is within reachable memory Some machines (observed with an AWS EC2 m7a.large instance) will place the ECAM configuration space window above 4GB, thereby making it unreachable from non-paged 32-bit code. This problem is currently ignored by iPXE, since the address is silently truncated in the call to ioremap(). (Note that other uses of ioremap() are not affected since the PCI core will already have checked for unreachable 64-bit BARs when retrieving the physical address to be mapped.) Fix by adding an explicit check that the region to be mapped starts within the reachable memory address space. (Assume that no machines will be sufficiently peverse to provide a region that straddles the 4GB boundary.) Signed-off-by: Michael Brown <mcb30@ipxe.org>	Michael Brown	5 months ago
6303	[pci] Cache ECAM mapping errors [pci] Cache ECAM mapping errors When an error occurs during ECAM configuration space mapping, preserve the error within the existing cached mapping (instead of invalidating the cached mapping) in order to avoid flooding the debug log with repeated identical mapping errors. Signed-off-by: Michael Brown <mcb30@ipxe.org>	Michael Brown	5 months ago

Older »