The .mrom payload has a code type of 0xff and so the initialisation
length field (single byte at offset 0x02) does not need to be
present. Use only the PCI header's image length field, which allows
the .mrom payload to be up to 32MB in size.
Inspired-by: Swift Geek <swiftgeek@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
mromprefix.S currently uses the initialisation length field (single
byte at offset 0x02) to determine the length of a ROM image within a
multi-image ROM BAR. For PCI ROM images with a code type other than
0, the initialisation length field may not be present.
Fix by using the PCI header's image length field instead.
Inspired-by: Swift Geek <swiftgeek@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Option::ROM currently uses the initialisation length field (single
byte at offset 0x02) to determine the length of a ROM image within a
multi-image ROM file. For PCI ROM images with a code type other than
0, the initialisation length field may not be present.
Fix by using the PCI header's image length field instead. Note that
this does not prevent us from correctly handling ISA ROMs, since ISA
ROMs do not support multiple images within a single ROM BAR anyway.
Inspired-by: Swift Geek <swiftgeek@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
With extremely unlucky timing, it is possible to interrupt a build and
cause make to delete config/named.h (and possibly any local
configuration headers).
Mark config/named.h and all local configuration headers as .PRECIOUS
to prevent make from ever deleting them.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The build process has for a long time assumed that every ROM is a PCI
ROM, and will always include the PCI header and PCI-related
functionality (such as checking the PCI BIOS version, including the
PCI bus:dev.fn address within the ROM product name string, etc.).
While real ISA cards are no longer in use, some virtualisation
environments (notably VirtualBox) have support only for ISA ROMs.
This can cause problems: in particular, VirtualBox will call our
initialisation entry point with random garbage in %ax, which we then
treat as the PCI bus:dev.fn address of the autoboot device: this
generally prevents the default boot sequence from using any network
devices.
Create .isarom and .pcirom prefixes which can be used to explicitly
specify the type of ROM to be created. (Note that the .mrom prefix
always implies a PCI ROM, since the .mrom mechanism relies on
reconfiguring PCI BARs.)
Make .rom a magic prefix which will automatically select the
appropriate PCI or ISA ROM prefix for ROMs defined via a PCI_ROM() or
ISA_ROM() macro. To maintain backwards compatibility, we default to
building a PCI ROM for anything which is not directly derived from a
PCI_ROM() or ISA_ROM() macro (e.g. bin/intel.rom).
Add a selection of targets to "make everything" to ensure that the
(relatively obscure) ISA ROM build process is included within the
per-commit QA checks.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Since some PnP BIOSes fail to set %es:di to point to the PnP signature
on entry, we identify a PnP BIOS by scanning through the top 64kB of
base memory looking for the PnP structure. We therefore don't
actually use the values of %es:di provided to the initialisation entry
point, and so there is no need to preserve them.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
ICH8 devices have an errata which requires us to reconfigure the
packet buffer size (PBS) register, and correspondingly adjust the
packet buffer allocation (PBA) register. The "Intel I/O Controller
Hub ICH8/9/10 and 82566/82567/82562V Software Developer's Manual"
notes for the PBS register that:
10.4.20 Packet Buffer Size - PBS (01008h; R/W)
Note: The default setting of this register is 20 KB and is
incorrect. This register must be programmed to 16 KB.
Initial value: 0014h
0018h (ICH9/ICH10)
It is unclear from this comment precisely which devices require the
workaround to be applied. We currently attempt to err on the side of
caution: if we detect an initial value of either 0x14 or 0x18 then the
workaround will be applied. If the workaround is applied
unnecessarily, then the effect should be just that we use less than
the full amount of the available packet buffer memory.
Unfortunately this approach does not play nicely with other device
drivers. For example, the Linux e1000e driver will rewrite PBA while
assuming that PBS still contains the default value, which can result
in inconsistent values between the two registers, and a corresponding
inability to transmit or receive packets. Even more unfortunately,
the contents of PBS and PBA are not reset by anything less than a
power cycle, meaning that this error condition will survive a hardware
reset.
The Linux driver (written and maintained by Intel) applies the PBS/PBA
errata workaround only for devices in the ICH8 family, identified via
the PCI device ID. Adopt a similar approach, using the PCI_ROM()
driver data field to indicate when the workaround is required.
Reported-by: Donald Bindner <dbindner@truman.edu>
Debugged-by: Donald Bindner <dbindner@truman.edu>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Allow named configurations to be specified via the CONFIG=... build
parameter. For headers in config/*.h which support named
configurations, the following files will be included when building
with CONFIG=<name>:
- config/defaults/<platform>.h (e.g. config/defaults/pcbios.h)
- config/<header>.h
- config/<name>/<header>.h (only if the directory config/<name> exists)
- config/local/<header>.h (autocreated if necessary)
- config/local/<name>/<header>.h (autocreated if necessary)
This mechanism allows for predefined named configurations to be
checked in to the source tree, as a directory config/<name> containing
all of the required header files.
The mechanism also allows for users to define multiple local
configurations, by creating header files in the directory
config/local/<name>.
Note that the config/*.h files which are used only to configure
internal iPXE APIs (e.g. config/ioapi.h) cannot be modified via a
named configuration. This avoids rebuilding the entire iPXE codebase
whenever switching to a different named configuration.
Inspired-by: Robin Smidsrød <robin@smidsrod.no>
Tested-by: Robin Smidsrød <robin@smidsrod.no>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Under some circumstances (e.g. if iPXE itself is booted via iSCSI, or
after an unclean reboot), the backend may not be in the expected
InitWait state when iPXE starts up.
There is no generic reset mechanism for Xenbus devices. Recent
versions of xen-netback will gracefully perform all of the required
steps if the frontend sets its state to Initialising. Older versions
(such as that found in XenServer 6.2.0) require the frontend to
transition through Closed before reaching Initialising.
Add a reset mechanism for netfront devices which does the following:
- read current backend state
- if backend state is anything other than InitWait, then set the
frontend state to Closed and wait for the backend to also reach
Closed
- set the frontend state to Initialising and wait for the backend to
reach InitWait.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Using version 1 grant tables limits guests to using 16TB of grantable
RAM, and prevents the use of subpage grants. Some versions of the Xen
hypervisor refuse to allow the grant table version to be set after the
first grant references have been created, so the loaded operating
system may be stuck with whatever choice we make here. We therefore
currently use version 2 grant tables, since they give the most
flexibility to the loaded OS.
Current versions (7.2.0) of the Windows PV drivers have no support for
version 2 grant tables, and will merrily create version 1 entries in
what the hypervisor believes to be a version 2 table. This causes
some confusion.
Avoid this problem by attempting to use version 1 tables, since
otherwise we may render Windows unable to boot.
Play nicely with other potential bootloaders by accepting either
version 1 or version 2 grant tables (if we are unable to set our
requested version).
Note that the use of version 1 tables on a 64-bit system introduces a
possible failure path in which a frame number cannot fit into the
32-bit field within the v1 structure. This in turn introduces
additional failure paths into netfront_transmit() and
netfront_refill_rx().
Signed-off-by: Michael Brown <mcb30@ipxe.org>
At some point during XenServer development history, the Windows PV
drivers changed to using a PCI device ID of 5853:0002 rather than
5853:0001. Current (7.2.0) drivers will bind to either 5853:0001 or
5853:0002, and the general approach taken by the world at large
(including Amazon EC2) seems to be to use only 5853:0001.
However, the current version of XenServer (6.2.0) will create the
platform device as 5853:0002 (via the platform:device_id VM parameter)
for any VMs created using the built-in templates for Windows Vista or
later.
Accept either PCI ID, since the underlying device is identical.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The behavior observed in the Apple EFI (1.10) RecieveFilters() call
is:
- failure if any of the PROMISCUOUS or MULTICAST filters are
included
- success if only UNICAST is included, however the result is
UNICAST|BROADCAST
- success if only UNICAST and BROADCAST are included
- if UNICAST, or UNICAST|BROADCAST are used, but the previous call
tried (and failed) to set UNICAST|BROADCAST|MULTICAST, then the
result is UNICAST|BROADCAST|MULTICAST
Work around this apparently broken SNP implementation by trying
RecieveFilterMask, then falling back to UNICAST|BROADCAST|MULTICAST,
then UNICAST|BROADCAST, and finally UNICAST.
Modified-by: Michael Brown <mcb30@ipxe.org>
Tested-by: Curtis Larsen <larsen@dixie.edu>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Some EFI 1.10 systems (observed on an Apple iMac) do not allow us to
open the device path protocol with an attribute of
EFI_OPEN_PROTOCOL_BY_DRIVER and so we cannot maintain a safe,
long-lived pointer to the device path. Work around this by instead
opening the device path protocol with an attribute of
EFI_OPEN_PROTOCOL_GET_PROTOCOL whenever we need to use it.
Debugged-by: Curtis Larsen <larsen@dixie.edu>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
According to the UEFI specification, the MCastFilter parameter (which
we currently pass as NULL, along with a zero MCastFilterCnt) is
optional only if ResetMCastFilter is true.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The ComponentName and ComponentName2 protocols differ only in the
standard which is used for language name codes.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Try very hard to avoid ever doing something invalid while attempting
to generate a debug message.
Debugged-by: Curtis Larsen <larsen@dixie.edu>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Dump the existing openers of a protocol whenever we are unable to open
a protocol using attributes of BY_DEVICE, EXCLUSIVE, or
BY_CHILD_CONTROLLER.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
efi_file_install() and efi_download_install() are both used to install
onto existing handles. There is therefore no need to allow for each
of their calls to InstallMultipleProtocolInterfaces() to create a new
handle.
By passing the handle directly (rather than a pointer to the handle),
we avoid potential confusion (and erroneous debug message colours).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The EFI headers define EFI_HANDLE as a void pointer, which renders
type checking on anything dealing with EFI handles somewhat useless.
Work around this bizarre sabotage attempt by redefining EFI_HANDLE as
a pointer to an anonymous structure.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Using efi_devpath_text() is marginally more efficient if we already
have the device path protocol available, but the mild increase in
efficiency is not worth compromising the clarity of the pattern:
DBGC ( device, "THING %p %s ...", device, efi_handle_name ( device ) );
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Provide a function efi_handle_name() (as a generalisation of
efi_handle_devpath_text()) which tries various methods to produce a
human-readable name for an EFI handle.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
HII seems to fail on several systems. Since it is non-essential,
treat HII problems as non-fatal.
Debugged-by: Curtis Larsen <larsen@dixie.edu>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Reject network devices which appear to be duplicates of those already
available via a different underlying hardware device. On a Xen PV-HVM
system, this allows us to filter out the emulated PCI NICs (which
would otherwise appear alongside the netfront NICs).
Note that we cannot use the Xen facility to "unplug" the emulated PCI
NICs, since there is no guarantee that the OS we subsequently load
will have a native netfront driver.
We permit devices with the same MAC address if they are attached to
the same underlying hardware device (e.g. VLAN devices).
Inspired-by: Marin Hannache <git@mareo.fr>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Some EFI 1.10 implementations (observed with a mid-2011 iMac) seem to
fail to fill in the DeviceHandle for our loaded images. It is
plausible that these implementations fill in the DeviceHandle only if
loading the image from a device path (rather than directly from a
memory buffer).
Work around this problem by filling in DeviceHandle if the firmware
leaves it empty.
We cannot sensibly fill in FilePath, because we have no way of knowing
whether or not the firmware will treat this as a pointer to be freed
when the image returns.
Reported-by: Curtis Larsen <larsen@dixie.edu>
Tested-by: Curtis Larsen <larsen@dixie.edu>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
If the StartImage() call returns with no error, then the image must
have been started and returned successfully. It either unloaded
itself, or it intended to remain loaded (e.g. it was a driver). We
therefore do not unload successful images.
If there was an error, we attempt to unload the image. This may not
work. In particular, there is no way to tell whether an error
returned from StartImage() was due to being unable to start the image
(in which case we probably should call UnloadImage()), or due to the
image itself returning an error (in which case we probably should not
call UnloadImage()). We therefore ignore any failures from the
UnloadImage() call itself.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
We currently treat network devices as available for use via the SNP
API only if RX queue processing has been frozen. (This is similar in
spirit to the way that RX queue processing is frozen for the network
device currently exposed via the PXE API.)
The default state of a freshly created network device is for the RX
queue to not be frozen, and thus to be unavailable for use via SNP.
This causes problems when devices are added through code paths other
than _efidrv_start() (which explicitly releases devices for use via
SNP).
We don't actually need to freeze RX queue processing, since calls via
the SNP API will always use netdev_poll() rather than net_poll(), and
so will never trigger the RX queue processing code path anyway.
We can therefore simplify the code to use a single global flag to
indicate whether network devices are claimed for use by iPXE or
available for use via SNP. Using a global flag allows the default
state for dynamically created network devices to behave sensibly.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Add basic support for Xen PV-HVM domains (detected via the Xen
platform PCI device with IDs 5853:0001), including support for
accessing configuration via XenStore and enumerating devices via
XenBus.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Import selected headers from the xen/include/public directory of the
Xen repository at git://xenbits.xen.org/xen.git
The script ./include/xen/import.pl can be used to automatically import
any required headers and their dependencies (in a similar fashion to
./include/ipxe/efi/import.pl). Trailing whitespace is stripped and an
appropriate FILE_LICENCE declaration is added to each header file.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Commit 24bbaf6 ("[lotest] Allow loopback testing on shared networks")
introduced a regression in which loopback testing packets would be
accepted from any network device. This produces unexpected results,
such as VLAN loopback testing succeeding even when incorrectly using
the underlying trunk device as either transmitter or receiver.
Fix by discarding any loopback testing packets which arrive on a
network device other than the current loopback testing receiver.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The $(BIN)/version.%.o target will fail if iPXE is built within a
non-git repository, e.g. when the user downloaded and extracted an
archive containing iPXE sources, *and* if any parent directory of the
iPXE sources is a git repository (or even contains a directory named
".git"). This is because git will by default ascend the directory
tree and look for ".git".
The problem typically manifests on source based distributions, see for
example https://bugs.gentoo.org/show_bug.cgi?id=482804
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Some switches do not allow an individual link (as defined in IEEE Std
802.3ad-2000 section 43.3.5) to work alone in a link aggregation group
as described in section 43.3.6. This is verified on Dell's
PowerConnect M6220, based on the Broadcom Strata XGS-IV chipset.
Set the LACP_STATE_AGGREGATABLE flag in the actor.state field to
announce link aggregation in the response LACPDU, which will have the
switch enable the link aggregation group and allow frames to pass.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
When a 32-bit iPXE binary is running on a system which allocates PCI
memory BARs above 4GB, our PCI subsystem will return the base address
for any such BARs as zero (with a warning message if DEBUG=pci is
enabled). Currently, ioremap() will happily map an address pointing
to the start of physical memory, providing no sensible indication of
failure.
Fix by always returning NULL if we are asked to ioremap() a zero bus
address.
With a totally flat memory model (e.g. under EFI), this provides an
accurate failure indication since no PCI peripheral will be mapped to
the zero bus address.
With the librm memory model, there is the possibility of a spurious
NULL return from ioremap() if the bus address happens to be equal to
virt_offset. Under the current virtual memory map, the NULL virtual
address will always be the start of .textdata, and so this problem
cannot occur; a NULL return from ioremap() will always be an accurate
failure indication.
Debugged-by: Anton D. Kachalov <mouse@yandex-team.ru>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
On some older EFI 1.10 implementations (observed with an old iMac), we
must use the (now obsolete) EFI_CONSOLE_CONTROL_PROTOCOL to switch the
console into text mode.
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The EFI_CONSOLE_CONTROL_PROTOCOL does not exist in the current UEFI
specification, but is required to enable text output on some older EFI
1.10 implementations (observed on an old iMac).
The header is not present in any of the standard include directories,
but can still be found in the EDK2 codebase as part of
EdkCompatibilityPkg.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
When building with DEBUG=efi_wrap, print details of calls made by the
loaded image to selected boot services functions.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The EFI FAT filesystem driver has a bug: if a block device contains no
FAT filesystem but does have an EFI_SIMPLE_FILE_SYSTEM_PROTOCOL
instance, the FAT driver will assume that it must have previously
installed the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL. This causes the FAT
driver to claim control of our device, and to refuse to stop driving
it, which prevents us from later uninstalling correctly.
Work around this bug by opening the disk I/O protocol ourselves,
thereby preventing the FAT driver from opening it.
Note that the alternative approach of opening the block I/O protocol
(and thereby in theory preventing DiskIo from attaching to the block
I/O protocol) causes an endless loop of calls to our DRIVER_STOP
method when starting the EFI shell. I have no idea why this is.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
When functioning as an EFI driver, drivers can be disconnected and
reconnected multiple times (e.g. via the EFI shell "connect" command,
or by running an executable such as ipxe.efi which will temporarily
disconnect existing drivers).
Minimise surprise by resetting the network device index to zero
whenever the last device is unregistered. This is not foolproof, but
it does handle the common case of having all devices unregistered and
then reregistered in the original order.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Rewrite the SNP NIC driver to use non-blocking and deferrable
transmissions, to provide link status detection, to provide
information about the underlying (PCI) hardware device, and to avoid
unnecessary I/O buffer allocations during receive polling.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Commit 8290a95 ("[build] Expose build timestamp, build name, and
product names") introduced a regression in the build process which
resulted in broken final binaries which had names based on object
files (e.g. "undionly.kpxe" or "intel.rom") rather than on device IDs
(e.g. "8086100e.mrom").
The underlying problem is the -DOBJECT=<name> macro which is used to
generate the obj_<name> symbols used to select objects required for
the final binary. The macro definition is derived from the initial
portion (up to the first dot) of the object being built. In the case
of e.g. undionly.kpxe.version.o, this gives -DOBJECT=undionly. This
results in undionly.kpxe.version.o claiming to be the "undionly"
object; the real "undionly" object will therefore never get dragged in
to the build.
Fix by renaming $(BIN)/%.version.o to $(BIN)/version.%.o, so that the
object is always built with -DOBJECT=version (as might be expected,
since it is built from core/version.c).
Final binaries which have names based on device IDs (such as
"8086100e.mrom") are not affected by this problem, since the object
name "8086100e" will not conflict with that of the underlying "intel"
object.
This problem was not detected by the per-commit smoke testing
procedure, which happens to use the binary bin/8086100e.mrom.
Reported-by: Christian Hesse <list@eworm.de>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Provide a single instance of EFI_DRIVER_BINDING_PROTOCOL (attached to
our image handle); this matches the expectations scattered throughout
the EFI specification.
Open the underlying hardware device using EFI_OPEN_PROTOCOL_BY_DRIVER
and EFI_OPEN_PROTOCOL_EXCLUSIVE, to prevent other drivers from
attaching to the same device.
Do not automatically connect to devices when being loaded as a driver;
leave this task to the platform firmware (or to the user, if loading
directly from the EFI shell).
When running as an application, forcibly disconnect any existing
drivers from devices that we want to control, and reconnect them on
exit.
Provide a meaningful driver version number (based on the build
timestamp), to allow platform firmware to automatically load newer
versions of iPXE drivers if multiple drivers are present.
Include device paths within debug messages where possible, to aid in
debugging.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Expose the build timestamp (measured in seconds since the Epoch) and
the build name (e.g. "rtl8139.rom" or "ipxe.efi"), and provide the
product name and product short name in a single centralised location.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
When multiple iPXE binaries are running concurrently (e.g. in the case
of undionly.kpxe using an underlying iPXE driver via the UNDI
interface) it would be helpful to be able to visually distinguish
debug messages from each binary.
Allow the range of debug colours used to be customised via the
DBGCOL=... build parameter. For example:
# Restrict to colours 31-33 (red, green, yellow)
make DBGCOL=31-33
# Restrict to colours 34-36 (blue, magenta, cyan)
make DBGCOL=34-36
Signed-off-by: Michael Brown <mcb30@ipxe.org>
If iPXE is used as a git submodule then the ../.git/index file will
not exist, and the build will fail. Fix by checking that the git
index file exists before adding it as a build dependency.
Signed-off-by: Peter Lemenkov <lemenkov@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
With blade servers, the chassis serial number (exposed via ${serial})
may not be unique. Expose ${board-serial} as a named setting to
provide easy access to a more meaningful serial number.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The VF might not have assigned a MAC address upon startup, and will
end up with a random MAC address during probe(). With this patch the
MAC address can be changed later on.
Signed-off-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
If the VF doesn't have a MAC address assigned we should create a
random MAC address.
Signed-off-by: Hannes Reinecke <hare@suse.de>
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The iBFT includes an "origin" field to indicate the source of the IP
address. We use the heuristic of assuming that the source should be
"manual" if the IP address originates directly from the network device
settings block, and "DHCP" otherwise. This is an imperfect guess, but
is likely to be correct in most common situations.
Originally-implemented-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Parse the sense data to extract the reponse code, the sense key, the
additional sense code, and the additional sense code qualifier.
Originally-implemented-by: Hannes Reinecke <hare@suse.de>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
iPXE currently calls cpu_nap() while performing DHCP, in order to
reduce CPU utilisation on virtual machines. Under mild broadcast load
(~100 packets per second), this can cause received packets to be
dropped because the receive descriptor ring is overrun before the next
18Hz timer interrupt wakes up the CPU. The result is that DHCP is
likely to intermittently fail on networks with appreciable amounts of
broadcast (or multicast) traffic.
This behaviour was introduced in the series of commits which
generalised the "dhcp" command to the "ifconf" command. The earlier
code (which did not handle IPv6 configuration) had no call to
cpu_nap() and so did not suffer from this problem.
Fix by removing the call to cpu_nap() in ifpoller_progress(). This
has the undesirable side effect that CPU utilisation will remain at
100% while waiting for DHCP to complete (which can take several
seconds, if we have to wait around for potential ProxyDHCP offers to
arrive).
Reported-by: Alex Davies <adavies@jumptrading.com>
Reported-by: Christoffer Stokbæk <christoffers@easyspeedy.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Some external code (observed with FreeBSD's bootloader) will continue
to make INT 13 calls after reconfiguring the 8259 PIC to change the
vector offsets for IRQs. If an IRQ (e.g. the timer IRQ) subsequently
occurs while iPXE is in protected mode, this will cause a general
protection fault since the corresponding IDT entry is empty.
A general protection fault is INT 0x0d, which happens to overlap with
the original IRQ5. We therefore do have an ISR set up to handle a
general protection fault, but this ISR simply reflects the interrupt
down to the real-mode INT 0x0d and then attempts to return. Since our
ISR is expecting a hardware interrupt rather than a general protection
fault, it doesn't remove the error code from the stack before issuing
the iret instruction; it therefore attempts to return to a garbage
address. Since the segment part of this address is likely to be
invalid, a second general protection fault occurs. This cycle
continues until we run out of stack space and triple fault.
Fix by reflecting all INTs down to real mode. This actually reduces
the code size by four bytes (but increases the bss size by almost
2kB).
Reported-by: Brian Rak <dn@devicenull.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
If ipv6_tx() is called with a non-NULL network device, a NULL or
unspecified source address, and a destination address which does not
match any routing table entry, then it will attempt to copy the source
address from a NULL pointer.
I don't think that there is currently any code path which could
trigger this behaviour, but we should probably ensure that it can
never happen.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Destination multicast addresses require a sin6_scope_id, which should
therefore be transcribed to a network device name by ipv6_sock_ntoa().
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The transmitting network device is specified via the destination
address, not the source address. There is no reason to set
sin6_scope_id on the source address.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Setting sin6_scope_id to a non-zero value will cause the check against
the "empty socket address" in udp_demux() to fail, and incoming DHCPv6
responses on interfaces other than net0 will be rejected with a
spurious "No UDP connection listening on port 546" error.
The transmitting network device is specified via the destination
address, not the source address. Fix by simply not setting
sin6_scope_id on the client socket address.
Reported-by: Anton D. Kachalov <mouse@yandex-team.ru>
Tested-by: Anton D. Kachalov <mouse@yandex-team.ru>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Fix an erroneous htonl() in the definition of IN6_IS_ADDR_LINKLOCAL(),
and add self-tests for the IN6_IS_ADDR_xxx() family of macros.
Reported-by: Marin Hannache <git@mareo.fr>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Some UEFI systems (observed with a Mac Pro) do not provide a loaded
image device path protocol. We don't currently use the loaded image
device path protocol for anything beyond printing a debug message, so
simply remove the code which attempts to fetch it.
Reported-by: Matt Woodward <pxematt@woodwardcc.com>
Tested-by: Matt Woodward <pxematt@woodwardcc.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Some UEFI systems (observed with a Mac Pro) do not provide
EFI_HII_DATABASE_PROTOCOL. We can continue to function without
providing access to network device settings via HII, so make this
protocol optional and fall back to simply not providing any HII
protocols.
Reported-by: Matt Woodward <pxematt@woodwardcc.com>
Tested-by: Matt Woodward <pxematt@woodwardcc.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Some UEFI systems (observed with a Mac Pro) do not provide
EFI_DEVICE_PATH_TO_TEXT_PROTOCOL. Since we use this protocol only for
debug messages, make it optional and fall back to printing the raw
device path bytes.
Reported-by: Matt Woodward <pxematt@woodwardcc.com>
Tested-by: Matt Woodward <pxematt@woodwardcc.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Get the NFS URI manipulation code out of nfs_open.c. The resulting
code is now much more readable.
Signed-off-by: Marin Hannache <git@mareo.fr>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
strndup() may be called on a string which is not NUL-terminated. Use
strnlen() instead of strlen() to ensure that we do not read beyond the
end of such a string.
Add self-tests for strndup(), including a test case with an
unterminated string.
Originally-fixed-by: Marin Hannache <git@mareo.fr>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Avoid generating syntactically invalid log messages by ensuring that
invalid characters are not present in the hostname. In particular,
ensure that any whitespace is stripped, since whitespace functions as
a field separator for syslog messages.
Reported-by: Alex Davies <adavies@jumptrading.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
As of commit d28bb51 ("[tcp] Defer sending ACKs until all received
packets have been processed"), increasing the RX ring size will
increase the number of received packets per transmitted ACK (since
each poll will process up to one complete receive ring). Under KVM,
this can make a substantial (up to ~200%) difference to the overall
download speed, since transmissions are very expensive.
Increase the ring fill level from four to eight packets: this
increases the download speed by around 50% at a cost of around 8kB of
heap space. Further speedups are possible by increasing the ring size
further, but it would be preferable to find alternative methods which
do not use noticeable amounts of heap space.
Tested-by: Robin Smidsrød <robin@smidsrod.no>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
An invalid free() was ironically introduced by fixing another invalid
free in commit 7aa69c4 ("[nfs] Fix an invalid free() when loading a
symlink").
Signed-off-by: Marin Hannache <git@mareo.fr>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The bzImage boot protocol allows the real-mode code to be loaded at
any segment within base memory. (The fact that both iPXE and recent
versions of Syslinux will load the real-mode code at 1000:0000 is a
coincidence; it is not guaranteed by the specification.)
Fix by making the code relocatable.
Reported-by: Andrew Stuart <andrew@shopcusa.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Rework geniso and genliso to provide a single merged utility for
generating ISO images.
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The .lkrn prefix currently provides a zImage kernel with unused setup
sectors and the whole iPXE binary placed within the "protected mode
kernel" portion of the zImage.
The work carried out years ago to create the .mrom format provides a
mechanism allowing the iPXE binary to be split into a small real-mode
header and a larger payload. This neatly matches the way that a
bzImage is loaded: the "setup sectors" can contain the header and the
"protected mode kernel" can contain the payload.
This removes the size restrictions on an iPXE .lkrn image (and hence
on derived image formats such as .iso).
Also remove obsolete copyright information, since none of the original
code or functionality now remains.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
When running inside a virtual machine (or when using the UNDI driver),
transmitting packets can be expensive. When we receive several
packets in one poll (e.g. because a slow BIOS timer interrupt routine
has caused us to fall behind in processing), we can safely send just a
single ACK to cover all of the received packets. This reduces the
time spent transmitting and allows us to clear the backlog much
faster.
Various RFCs (starting with RFC1122) state that there should be an ACK
for at least every second segment. We choose not to enforce this
rule. Under normal operation each poll should find at most one
received packet, and we will then not delay any ACKs. We delay
(i.e. omit) ACKs only when under sufficiently heavy load that we are
finding multiple packets per poll; under these conditions it is
important to clear the backlog quickly since any delay may lead to
dropped packets.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Commit 8540300 ("[build] Disable ccache for all relevant build
targets") attempted to generalise the rule for $(BIN)/version.o to
$(BIN)/version.% in order to apply the dependency to all relevant
build targets (debug objects, assembly listings, etc).
This generalisation appears to work for the ccache override
directives, but seems to cause make (at least, GNU make 4.0) to simply
ignore the dependency upon the git index.
Since version.c contains only some string constants, there is unlikely
to be a substantive need for its debug objects, assembly listings,
etc. Restore the previous form of the dependency and accept that
hypothetical builds with e.g. DEBUG=version will not be handled
correctly.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
When profiling, exclude any time spent inside the hypervisor
responding to our MMIO accesses. This substantially reduces the
variance accumulated on many other profilers.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Interrupt processing adds noise to profiling results. Allow
interrupts (from within protected mode) to be profiled separately,
with time spent within the interrupt handler being excluded from any
other profiling currently in progress.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
PXENV_UNDI_ISR calls may implicitly refill the underlying receive
ring, and so could continue to retrieve packets indefinitely. Place
an upper limit on the number of calls to PXENV_UNDI_ISR per call to
undinet_poll().
Signed-off-by: Michael Brown <mcb30@ipxe.org>
When making a call from real mode to protected mode, we save and
restore the global and interrupt descriptor table registers. The
restore currently takes place after returning to real mode, which
generates two EXCEPTION_NMIs and corresponding VM exits when running
under KVM on an Intel CPU.
Avoid the VM exits by restoring the descriptor table registers inside
prot_to_real, while still running in protected mode.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Ensure that all segment registers have zero in the low two bits before
transitioning to protected mode. This allows the CPU state to
immediately be deemed to be "valid", and eliminates the need for any
further emulated instructions.
Load the protected-mode interrupt descriptor table after switching to
protected mode, since this avoids triggering an EXCEPTION_NMI and
corresponding VM exit.
This reduces the time taken by real_to_prot under KVM by around 50%.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
On an Intel CPU supporting VMX, KVM will emulate instructions while
the CPU state remains "invalid". In real mode, the CPU state is
defined to be "invalid" if any segment register has a base which is
not equal to (sreg<<4) or a limit which is not equal to 64kB.
We don't actually use the base stored in the REAL_DS descriptor for
any significant purpose. Change the base stored in this descriptor to
be equal to (REAL_DS<<4). A segment register loaded with REAL_DS is
then automatically valid in both real and protected modes. This
allows KVM to stop emulating instructions much sooner.
The only use of REAL_DS for memory accesses currently occurs in the
indirect ljmp within prot_to_real. Change this to a direct ljmp,
storing rm_cs in .text16 as part of the ljmp instruction. This
removes the only memory access via REAL_DS (thereby allowing for the
above descriptor base address hack), and also simplifies the ljmp
instruction (which will still have to be emulated).
Load the real-mode interrupt descriptor table register before
switching to real mode, since this avoids triggering an EXCEPTION_NMI
and corresponding VM exit.
This reduces the time taken by prot_to_real under KVM by around 65%.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The mode-transition code involves paths which switch back and forth
between the .text and .text16 sections. At present, only the start of
each function is labelled, which makes it difficult to decode
addresses within the parts of the function existing in a different
section.
Add explicit labels at the start of each section change, so that
addresses can be meaningfully decoded to the nearest label.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Now that we can handle interrupts while in protected mode, there is no
need to switch to real mode just to halt the CPU.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The currticks() function is called at least once per TCP packet, and
so is performance-critical. Switching to real mode just to allow the
timer interrupt to fire is expensive when running inside a virtual
machine, and imposes a significant performance cost.
Fix by enabling interrupts without switching to real mode. This
results in an approximately 100% increase in download speed when
running under KVM.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
We now have the ability to handle interrupts while in protected mode,
and so no longer need to set up a dedicated interrupt descriptor table
while running COM32 executables.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
When running in a virtual machine, switching to real mode may be
expensive. Allow interrupts to be enabled while in protected mode and
reflected down to the real-mode interrupt handlers.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Allow for an explicit debug level of zero, which will enable
assertions and profiling (i.e. anything controlled by NDEBUG) without
generating any debug messages.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
We currently use flat real mode wherever real mode is required. This
guarantees that we will not surprise some unsuspecting external caller
which has carefully set up flat real mode by suddenly reducing the
segment limits to 64kB.
However, operating in flat real mode imposes a severe performance
penalty in some virtualisation environments, since some CPUs cannot
fully virtualise flat real mode and so the hypervisor must fall back
to emulation. In particular, operating under KVM on a pre-Westmere
Intel CPU will be at least an order of magnitude slower, to the point
that there is a visible teletype effect when printing anything to the
BIOS console. (Older versions of KVM used to cheat and ignore the
"flat" part of flat real mode, which masked the problem.)
Switch (back) to using genuine real mode with 64kB segment limits
instead of flat real mode. Hopefully this won't break anything.
Add an explicit switch to flat real mode before returning to the BIOS
from the ROM prefix, since we know that a PMM BIOS will call the ROM
initialisation point (and potentially the BEV) in flat real mode.
As noted in previous commit messages, it is not possible to restore
the real-mode segment limits after a transition to protected mode,
since there is no way to know which protected-mode segment descriptor
was originally used to initialise the limit portion of the segment
register.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Inside a virtual machine, writing the RX ring tail pointer may incur a
substantial overhead of processing inside the hypervisor. Minimise
this overhead by writing the tail pointer once per batch of
descriptors, rather than once per descriptor.
Profiling under qemu-kvm (version 1.6.2) shows that this reduces the
amount of time taken to refill the RX descriptor ring by around 90%.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Operations which are negligible on physical hardware (such as issuing
a posted write to the transmit ring tail register) may involve
substantial amounts of processing within the hypervisor if running in
a virtual machine.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
As observed in commit 082cedb ("[build] Fix __libgcc attribute for
recent gcc versions"), recent versions of gcc have changed the
semantics of -mrtd as applied to the implicit arithmetic functions.
It is possible for tests to succeed even if our assumptions about
gcc's interpretation of -mrtd are incorrect. In particular, if gcc
chooses to utilise a frame pointer in the calling function, then it
can tolerate a temporarily incorrect stack pointer (since the stack
pointer will shortly afterwards be restored from the frame pointer
anyway).
Add tests designed specifically to check that our implementations of
the implicit arithmetic functions manipulate the stack pointer as
expected by gcc.
The effect of these tests can be observed by temporarily reverting
commit 082cedb ("[build] Fix __libgcc attribute for recent gcc
versions"): without this fix in place, the tests will fail on gcc 4.7
and later.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
We observed some time ago (in commit 4ce8d61 "Import various libgcc
functions from syslinux") that gcc seems to treat calls to the
implicit arithmetic functions (e.g. __udivdi3()) as being affected by
-mregparm but unaffected by -mrtd.
This seems to be no longer the case with current gcc versions, which
treat calls to these functions as being affected by both -mregparm and
-mrtd, as expected.
There is nothing obvious in the gcc changelogs to indicate precisely
when this happened. From experimentation with available gcc versions,
the change occurred sometime between v4.6.3 and v4.7.2. We assume
that only versions up to v4.6.x require the special treatment.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
On a 32-bit system, 64-bit division is implemented using the libgcc
functions provided in __udivmoddi4.c etc. Calls to these functions
are generated automatically by gcc, with a calling convention that is
somewhat empirical in nature. Add these self-tests primarily as a
check that we are using the correct calling convention.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Escape sequences received via the serial console can fail since the
cpu_nap() in getchar_timeout() can delay processing for more than the
time it takes for a single character to arrive.
Fix by enabling the UART FIFOs.
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
It is unclear from the datasheets whether or not the TX ring can be
completely filled (i.e. whether writing the tail value as equal to the
current head value will cause the ring to be treated as completely
full or completely empty). It is very plausible that this edge case
could differ in behaviour between real hardware and the many
implementations of an emulated Intel NIC found in various virtual
machines. Err on the side of caution and always leave at least one
ring entry empty.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Expand the concept of the X.509 cache to provide the functionality of
a certificate store. Certificates in the store will be automatically
used to complete certificate chains where applicable.
The certificate store may be prepopulated at build time using the
CERT=... build command line option. For example:
make bin/ipxe.usb CERT=mycert1.crt,mycert2.crt
Certificates within the certificate store are not implicitly trusted;
the trust list is specified using TRUST=... as before. For example:
make bin/ipxe.usb CERT=root.crt TRUST=root.crt
This can be used to embed the full trusted root certificate within the
iPXE binary, which is potentially useful in an HTTPS-only environment
in which there is no HTTP server from which to automatically download
cross-signed certificates or other certificate chain fragments.
This usage of CERT= extends the existing use of CERT= to specify the
client certificate. The client certificate is now identified
automatically by checking for a match against the private key. For
example:
make bin/ipxe.usb CERT=root.crt,client.crt TRUST=root.crt KEY=client.key
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Ensure that any generated files (such as DER forms of X.509
certificates) are rebuilt if the Makefile changes.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The build process currently attempts to disable ccache for files using
the .incbin directive, but the rule fails to apply to anything beyond
the simple object target. Fix by applying to all relevant build
targets (including debug objects, assembly listings, and so on).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
iPXE currently allocates a copy the certificate's common name as a
string. This string is used by the TLS and CMS code to check
certificate names against an expected name, and also appears in
debugging messages.
Provide a function x509_check_name() to centralise certificate name
checking (in preparation for adding subjectAlternativeName support),
and a function x509_name() to provide a name to be used in debugging
messages, and remove the dynamically allocated string.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Certificate authorities are not required to send the certificate used
to sign the OCSP response if the response is signed by the original
issuer.
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
At least one HTTP server (Google's OCSP responder) has been observed
to generate a Content-Length header with trailing whitespace.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Some BIOSes (observed with a ProLiant DL360p Gen8 SE) perform no range
checking whatsoever on the parameters passed to INT10,06 and will
therefore happily write to an area beyond the end of video RAM. The
area immediately following the video RAM tends to be the VGA BIOS ROM
image. Overwriting the VGA BIOS leads to an interesting variety of
crashes and reboots.
Fix by specifying an exact width and height to be cleared, rather than
passing in large values and relying upon the BIOS to truncate them to
the appropriate range.
Reported-by: Alex Davies <adavies@jumptrading.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
On an Asus Z87-K motherboard with an onboard 8168 NIC, booting into
Windows 7 and then warm rebooting into iPXE results in a broken RX
datapath: packets can be transmitted successfully but garbage is
received. A cold reboot clears the problem.
A dump of the PHY registers reveals only one difference: in the
failure case the bits ADVERTISE_PAUSE_CAP and ADVERTISE_PAUSE_ASYM are
cleared. Explicitly setting these bits does not fix the problem.
A dump of the MAC registers reveals a few differences, of which the
most obvious culprit is the undocumented bit 24 of the Receive
Configuration Register (RCR), which is set in the failure case.
Explicitly clearing this bit does fix the problem.
Reported-by: Sebastian Nielsen <ipxe@sebbe.eu>
Reported-by: Oliver Rath <rath@mglug.de>
Debugged-by: Sebastian Nielsen <ipxe@sebbe.eu>
Tested-by: Sebastian Nielsen <ipxe@sebbe.eu>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Some UEFI builds will set up a timer to continuously poll any SNP
devices. This can drain packets from the network device's receive
queue before iPXE gets a chance to process them.
Use netdev_rx_[un]freeze() to explicitly indicate when we expect our
network devices to be driven via the external SNP API (as we do with
the UNDI API on the standard BIOS build), and disable the SNP API
except when receive queue processing is frozen.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
EFIRC() uses PLATFORM_TO_ERRNO(), which evaluates its argument twice
(and can't trivially use a braced-group expression or an inline
function to avoid this, since it gets used outside of function
context).
The expression "EFIRC(main())" will therefore end up calling main()
twice, which is not the intended behaviour. Every other instance of
EFIRC() is of the simple form "EFIRC(rc)", so fix by converting this
instance to match.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Allow for extraneous packets to be received during loopback testing,
and so permit loopback tests to be performed when ports are connected
to a switch (rather than requiring ports to be directly connected with
a loopback cable).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Inhibit implicit sign-padding of characters with the top bit set
(e.g. accented characters), which confuses the mucurses library by
colliding with the bits used to store character attributes and
colours.
Reported-by: Marc Delisle <Marc.Delisle@cegepsherbrooke.qc.ca>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
On a 64-bit build, EFI_STATUS codes are 64-bit quantities, with the
"error/warning" bit located in bit 63.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
iPXE will detect timeout failures in several situations: network
link-up, DHCP, TCP connection attempts, unacknowledged TCP data, etc.
This does not cover all possible circumstances. For example, if a
connection to a web server is successfully established and the web
server acknowledges the HTTP request but never sends any data in
response, then no timeout will be triggered. There is no timeout
defined within the HTTP specifications, and the underlying TCP
connection will not generate a timeout since it has no way to know
that the HTTP layer is expecting to receive data from the server.
Add a "--timeout" parameter to "imgfetch", "chain", etc. If no
progress is made (i.e. no data is downloaded) within the timeout
period, then the download will be aborted.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Redefine the timeout parameter from "time since start of job" to "time
since progress was last made". This does not affect any existing
behaviour, since all existing users of the timeout parameter do not
provide progress indication.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
A web server may return a 503 Service Unavailable response along with
a Retry-After header to direct the client to retry the request at a
later time.
The Retry-After header may be a number of seconds, or a full HTTP
timestamp (e.g. "Fri, 7 Mar 2014 17:22:14 GMT"). We have no
reasonable way of parsing a full HTTP timestamp; if the server chooses
to use this format then we simply retry after a fixed 5-second delay.
As per RFC 2616, in the absence of a Retry-After header we treat a
status code of 503 Service Unavailable as being equivalent to 500
Internal Server Error, and immediately fail the request.
Requested-by: Suresh Sundriyal <ssundriy@vmware.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
iPXE uses currticks() (along with the MAC address(es) of any network
devices) to seed the (non-cryptographic) random number generator. The
current implementation of linux_currticks() ensures that the first
call to currticks() will always return zero; this results in identical
random number sequences on each run of iPXE on a given machine. This
can cause odd-looking behaviour due to e.g. the reuse of local TCP
port numbers.
Fix by effectively rounding down the start time recorded by
linux_currticks() to the nearest whole second; this makes it unlikely
that consecutive runs of iPXE will use the exact same RNG sequence.
(Note that none of this affects the cryptographic RNG, which uses
/dev/random as a source of entropy.)
Signed-off-by: Michael Brown <mcb30@ipxe.org>
iPXE currently ignores ACKs which do not acknowledge any new data.
(In particular, it does not stop the retransmission timer; this is
done to prevent an immediate retransmission if a duplicate ACK is
received while the transmit queue is non-empty.)
If a peer provides a window size of zero and later sends a duplicate
ACK to update the window size, this update will therefore be ignored
and iPXE will never be able to transmit data.
Fix by updating the window size even for ACKs which do not acknowledge
new data.
Reported-by: Wissam Shoukair <wissams@mellanox.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
When opening a VLAN device, vlan_open() will call netdev_open() on the
trunk device. This will result in a call to netdev_notify(), which
will cause vlan_notify() to call vlan_sync() on the original VLAN
device, which will see that the trunk device is now open but the VLAN
device apparently isn't (since it has not yet been flagged as open by
netdev_open()). The upshot is a second attempt to open the VLAN
device, which will result in an erroneous second call to vlan_open().
This convoluted chain of events then terminates harmlessly since
vlan_open() calls netdev_open() on the trunk device, which just
returns immediately since the trunk device is by now flagged as being
already open.
Prevent this from happening by having netdev_open() flag the device as
open prior to calling the device's open() method, and reflagging it as
closed if the open() method fails.
Originally-fixed-by: Wissam Shoukair <wissams@mellanox.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Commit c429bf0 ("[romprefix] Store boot bus:dev.fn address as autoboot
device location") introduced a regression by using register %cx to
temporarily hold the PCI bus:dev.fn address, despite the fact that %cx
was already being used to hold the stored BIOS stack segment.
Consequently, when returning to the BIOS after a failed or cancelled
boot attempt, iPXE would end up calling INT 18 with the stack segment
set equal to the PCI bus:dev.fn address. Writing to essentially
random areas of memory tends to upset even the more robust BIOSes.
Fix by using register %ax to temporarily hold the PCI bus:dev.fn
address.
Reported-by: Anton D. Kachalov <mouse@yandex-team.ru>
Tested-by: Anton D. Kachalov <mouse@yandex-team.ru>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
iPXE currently pads initrd images to a multiple of 4kB and inserts
zero padding between images, as required by some versions of the Linux
kernel. The overall length reported via the ramdisk_size field in the
bzImage header includes this zero padding.
This causes problems when using memdisk to load a gzip-compressed disk
image. memdisk treats the ramdisk_size field as containing the exact
length of the initrd image, and uses this length to locate the 8-byte
gzip footer. This will generally cause memdisk to fail to decompress
the disk image.
Fix by reporting the exact length of the initrd image set, including
any padding inserted between images but excluding any padding added at
the end of the final image.
Reported-by: Levente LEVAI <levail@aviatronic.hu>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
iPXE currently advertises a fixed MSS of 1460, which is correct only
for IPv4 over Ethernet. For IPv6 over Ethernet, the value should be
1440 (allowing for the larger IPv6 header). For non-Ethernet link
layers, the value should reflect the MTU of the underlying network
device.
Use tcpip_mtu() to calculate the transport-layer MTU associated with
the peer address, and calculate the MSS to allow for an optionless TCP
header as per RFC 6691.
As a side benefit, we can now fail a connection immediately with a
meaningful error message if we have no route to the destination
address.
Reported-by: Anton D. Kachalov <mouse@yandex-team.ru>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Provide the function tcpip_mtu() to allow external code to determine
the (transport-layer) maximum transmission unit for a given socket
address.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Provide the function tcpip_netdev() to allow external code to
determine the transmitting network device for a given socket address.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
qemu can load an option ROM which is not associated with a particular
PCI device using the "-option-rom" syntax. Under these circumstances,
we should ignore the PCI bus:dev.fn address that we expect to find in
%ax on entry to the initialisation vector.
Fix by using the PCI bus:dev.fn address only if it is non-zero. Since
00:00.0 will always be the host bridge, it can never be the address of
a network card.
Reported-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Per the BIOS Boot Specification, the initialization phase of the ROM
is called with the PFA (PCI Function Address) in the %ax register.
The intention is that the ROM code will store that device address
somewhere and use it for booting from that device when the Boot Entry
Vector (BEV) is called. iPXE does store the PFA, but doesn't use it
to select the boot network device. This renders BIOS IPL lists fairly
ineffective.
Fix by using the BBS-specified bus:dev.fn address as the autoboot
device location.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
iPXE will currently attempt to boot from every network device for
which it has a driver. Where a system has more than one network
device supported by iPXE, this renders BIOS IPL lists ineffective.
Allow an autoboot device location to be specified. If such a location
is specified, then only devices matching that location will be used as
part of the automatic boot sequence. If no such location is
specified, then all devices will be used.
Note that this does not affect the "autoboot" command, which will
continue to use all devices.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
iPXE currently prints a "Press Ctrl-B" banner twice: once when the ROM
is first called for initialisation and again if we attempt to boot
from the ROM. This slows boot, especially when the NIC is not the
primary boot device. Tools such as libguestfs make use of QEMU VMs
for performing maintenance on disk images and may make use of NICs in
the VM for network support. If iPXE introduces a static init-time
delay, that directly translates to increased runtime for the tools.
Fix by allowing the ROM banner timeout to be configured independently
of the main banner timeout.
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Add support for parsing of URIs containing literal IPv6 addresses
(e.g. "http://[fe80::69ff:fe50:5845%25net0]/boot.ipxe").
Duplicate URIs by directly copying the relevant fields, rather than by
formatting and reparsing a URI string. This relaxes the requirements
on the URI formatting code and allows it to focus on generating
human-readable URIs (e.g. by not escaping ':' characters within
literal IPv6 addresses). As a side-effect, this allows relative URIs
containing parameter lists (e.g. "../boot.php##params") to function
as expected.
Add validity check for FTP paths to ensure that only printable
characters are accepted (since FTP is a human-readable line-based
protocol with no support for character escaping).
Construct TFTP next-server+filename URIs directly, rather than parsing
a constructed "tftp://..." string,
Add self-tests for URI functions.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Commit b5f5f73 ("[cmdline] Expand settings within each command-line
token individually") effectively rendered the "uristring" setting type
obsolete, since strings containing whitespace no longer break the
command line parser. The concept of the "uristring" type is not well
defined, since URI escaping rules depend on which portion of a URI is
being escaped.
Remove the "uristring" type, converting it into an alias for the
"string" setting type so as to avoid breaking existing scripts.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
When resizing DHCP options, iPXE currently calculates the length to be
copied by subtracting the destination pointer from the end of buffer
pointer. This works and guarantees not to write beyond the end of the
buffer, but may end up reading beyond the end of the buffer.
Fix by calculating the required length exactly.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Commit d4c0226 ("[dns] Support DNS search lists") introduced a
regression when handling CNAME records resolving to names longer than
the original name. The "end of name" offset stored in dns->offset was
not updated to reflect the length of the new name, causing
dns_question() to append the (empty) search suffix at an incorrect
offset within the name buffer, resulting in a mangled DNS name.
In the case of a CNAME record resolving to a name shorter than or
equal in length to the original name, then the mangling would occur in
an unused portion of the name buffer. In the common case of a name
server returning the A (or AAAA) record along with the CNAME record,
this would cause name resolution to succeed despite the mangling. (If
the name server did not return the A or AAAA record along with the
CNAME record, then the mangling would be revealed by the subsequent
invalid query packet.)
Reported-by: Nicolas Sylvain <nsylvain@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Update the DNS resolver to support DNS search lists (as provided by
DHCP option 119, DHCPv6 option 24, or NDP option 31).
Add validation code to ensure that parsing of DNS packets does not
overrun the input, get stuck in infinite loops, or (worse) write
beyond the end of allocated buffers.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Rename the "--bpp" option to "--depth", to free up the single-letter
option "-b" for "--bottom" in preparation for adding margin support.
This does not break backwards compatibility with documented features,
since the "console" command has not yet been documented.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Allow for an arbitrary margin to be specified in the console
configuration. If the actual screen size does not match the requested
screen size, then update any margins specified so that they remain in
the same place relative to the requested screen size. If margins are
unspecified (i.e. zero), then leave them as zero.
The underlying assumption here is that any specified margins are
likely to describe an area within a background picture, and so should
remain in the same place relative to that background picture.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Centre the background picture on the console, to give a more
consistent result when the aspect ratio does not match the requested
width and height.
Once drawn for the first time, nothing should ever overwrite the
margins of the display. We can therefore eliminate the logic used to
redraw only the margin areas, and use much simpler code to draw the
complete initial background image.
Simplify the redrawing logic further by making the background picture
buffer equal in size to the frame buffer. In the common case of a
background picture which is designed to fill the screen, this wastes
no extra memory, and the combined code simplifications reduce the size
of fbcon.o by approximately 15%.
Redefine the concept of "margin" to match the intuitive definition
(i.e. the size of the gap, rather than the position of the boundary
line).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Fix incorrect calculation used to determine length of data to be
copied within a literal data block, and add a test case to prevent
this bug from going undetected in future.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Allow test reports to specify an explicit file name and line number
using the extended okx() macro. This allows large blocks of test
report code such as tcpip_random_ok() to be implemented as functions
rather than macros.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Use the magic colour facility to cause the user interface background
to become transparent when we have a background picture.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The magic basic colour can be remapped at runtime from COLOR_NORMAL_BG
(usually blue) to COLOR_DEFAULT (which will be transparent as a
background colour on the framebuffer console).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Add a centralised concept of colours and colour pairs (using the
default colour pairs as configured via config/colour.h). A colour
pair consists of a pair of colour indices.
Add the ability to redefine both a colour pair and an individual
colour index, with minimal overhead if this feature is not required
(e.g. because the relevant shell commands are not present in the
build).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Provide a mechanism for consoles to update the recorded console width
and height, and use this width and height to provide the curses COLS
and LINES variables.
We choose not to use ANSI escape sequences to obtain the width and
height, for two reasons:
- iPXE's model is that all output is sent to all consoles; we could
therefore end up with multiple consoles reporting conflicting widths
and heights
- when a serial console is in use, we probably don't want to resize
the output shown on the BIOS console to match the size of the serial
console, since it's likely that the serial console is in use only
for debugging.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The vgabios used by bochs and qemu (and other virtualisation products)
has a bug in its implementation of INT 10,4f00 which causes the high
16 bits of %ebx and %edx to become corrupted.
The vgabios code uses a "pushaw"/"popaw" pair to preserve the low 16
bits of all non-segment registers. The vgabios code is compiled using
bcc, which generates 8086-compatible code and so never touches the
high 16 bits of the 32-bit registers. However, the function
vbe_biosfn_return_controller_information() includes the line:
size_64k = (Bit16u)((Bit32u)cur_info->info.XResolution *
cur_info->info.XResolution *
cur_info->info.BitsPerPixel) >> 19;
which generates an implicit call to the "lmulul" function. This
function is implemented in vbe.c as:
; helper function for memory size calculation
lmulul:
and eax, #0x0000FFFF
shl ebx, #16
or eax, ebx
SEG SS
mul eax, dword ptr [di]
mov ebx, eax
shr ebx, #16
ret
which modifies %eax, %ebx, and %edx (as a result of the "mul"
instruction, which places its result into %edx:%eax).
Work around this problem by marking %ebx and %edx as being clobbered
by the call to INT 10,4f00. (%eax is already used as an output
register, so does not need to be on the clobber list.)
Reported-by: Oliver Rath <rath@mglug.de>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Allow for equivalent IPv4 and IPv6 settings (which requires equivalent
settings to be adjacent within the settings list).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Allow for multiple setting definitions with the same name but
different scopes and tags. For example, allow for a "filename"
setting with default scope and tag value 67 (for DHCPv4) and a
corresponding "filename" setting with IPv6 scope and tag value 59 (for
DHCPv6).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Note that IANA has not yet assigned a DHCPv6 option code for the
syslog server. When a code is assigned, the definition of
DHCPV6_LOG_SERVERS should be updated. Until then, an IPv6 address of
a syslog server can be configured manually using e.g.
set syslog6 3ffe:302:11:2::8309
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Our policy is to prefer IPv6 addreses to IPv4 addresses, but to
request IPv6 addresses only if we have an IPv6 address for the name
server itself.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Allow for the existence of references to IPv6 setting types without
dragging in the whole IPv6 stack, by placing the definition of
setting_type_ipv6 in core/settings.c and providing weak stub methods
for parse_ipv6_setting() and format_ipv6_setting().
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The fetch_setting() family of functions may currently modify the
definition of the specified setting (e.g. to add missing type
information). Clean up this interface by requiring callers to provide
an explicit buffer to contain the completed definition of the fetched
setting, if required.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The ANSI escape sequences to show and hide the cursor take the form
"<ESC>[?25h" and "<ESC>[?25l" respectively. iPXE currently treats the
'?' character as the final byte. Fix by explicitly treating '?' as an
intermediate byte.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
OpenBSD 5.4 seems to generate dynamically linked binaries by default,
which breaks our build process. Fix by forcing the linker to always
create static binaries.
Reported-by: Jiri B <jirib@devio.us>
Tested-by: Jiri B <jirib@devio.us>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
There is no requirement for VBE modes to be listed in increasing order
of resolution. With the present logic, this can cause e.g. a 1024x768
mode to be selected if the user asks for 640x480, if the 1024x768 mode
is earlier in the mode list.
Define a scoring system for modes as
score = ( width * height - bpp )
and choose the mode with the lowest score among all acceptable modes.
This should prefer to choose the mode closest to the requested
resolution, with a slight preference for higher colour depths.
Reported-by: Robin Smidsrød <robin@smidsrod.no>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The VirtualBox BIOS fails to retrieve mode information (with status
0x0100) for some modes within the mode list. Skip any such modes,
rather than treating this as a fatal error.
Reported-by: Robin Smidsrød <robin@smidsrod.no>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The VESA frame buffer console uses the VESA BIOS extensions (VBE) to
enumerate video modes, selects an appropriate mode, and then hands off
to the generic frame buffer code.
The font is extracted from the VGA BIOS, avoiding the need to provide
an external font file.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Allow the "initialising devices" message to show up on consoles which
require initialisation, by deferring it until after initialise() has
completed.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Allow for IPv6 routing table entries to be created for an on-link
prefix where a local address has not yet been assigned to the network
device.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Syslinux 6.x places its files into a bios subdirectory, and requires
that a ldlinux.c32 module be included within the ISO image. Add the
relevant search paths for isolinux.bin, and include the file
ldlinux.c32 within the ISO image if it exists.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Add support for the stateful and stateless variants of the DHCPv6
protocol. The resulting settings block is registered as
"net<x>.dhcpv6", and DHCPv6 options can be obtained using
e.g. "${net0.dhcpv6/23:ipv6}" to obtain the IPv6 DNS server address.
IPv6 addresses obtained via stateful DHCPv6 are not yet applied to the
network device.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The retrieval of the cached DHCPACK and the creation of network
devices are both currently scheduled as STARTUP_NORMAL. It is
therefore possible that the cached DHCPACK will not be retrieved in
time for cachedhcp_probe() to apply it to the relevant network device.
Fix by retrieving the cached DHCPACK at initialisation time rather
than at startup time.
As an optimisation, an unclaimed cached DHCPACK can be freed
immediately after the last network device has been created, rather
than waiting until shutdown.
Reported-by: Espen Braastad <espen.braastad@redpill-linpro.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Include IPv6 within the generic network device configurator
mechanism. The IPv6 configurator will send a router solicitation and
wait for a router advertisement to be received. (As per RFC4861
section 6.3.7, we do this even if advertisements have been received
prior to sending the router solicitation.)
Signed-off-by: Michael Brown <mcb30@ipxe.org>
iPXE supports multiple mechanisms for network device configuration:
DHCPv4 for IPv4, FIP for FCoE, and SLAAC for IPv6. At present, DHCPv4
requires an explicit action (e.g. a "dhcp" command), FIP is initiated
implicitly upon opening a network device, and SLAAC takes place
whenever a RA happens to be received.
Add a generic concept of a network device configurator, which provides
a common interface to triggering configuration and to reporting the
result of the configuration process.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Commit 5e1fa5c ("[parseopt] Add parse_timeout()") introduced a
regression causing the shell banner timeout value (calculated in
milliseconds) to be treated as a timer tick count, resulting in a
timeout of approximately two minutes rather than the intended two
seconds.
Reported-by: Christian Hesse <list@eworm.de>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
If a job times out then use the most recent ongoing error status
reported via job_progress() (if available) as the overall return
status.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Some background jobs have a meaningful ongoing status code (e.g. the
current link status for a job waiting for a network link to come up).
Allow this to be exposed via the job_progress() method.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
If an object interface does not provide an intf_close() method, then
default to calling intf_restart(). This allows static objects to
safely ignore intf_close(), without needing to add code solely to
ensure that the interface gets unplugged.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Most network upper-layer drivers do not implement all three methods
(probe, notify, and remove). Save code by making all methods
optional.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Parsing a timeout value (specified in milliseconds) into an internal
timeout value measured in timer ticks is a common operation. Provide
a parse_timeout() value to carry out this conversion automatically.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
When chainloading, always retrieve the cached DHCPACK packet from the
underlying PXE stack, and apply it as the original contents of the
"net<X>.dhcp" settings block. This allows cached DHCP settings to be
used for any chainloaded iPXE binary (not just undionly.kkpxe).
This change eliminates the undocumented "use-cached" setting. Issuing
the "dhcp" command will now always result in a fresh DHCP request.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
When transmitting to a link-local or multicast destination address,
use the network device's link-local address as the source address if
no explicit source address has been specified.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The IPv6 option length field represents the length of the option data
field, not the overall length of the option.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Add generic pinger mechanism (analogous to the generic downloader
mechanism) which opens a ping socket, transmits ping requests, and
passes information about ping replies to a callback function.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Merge common functionality between IPv4 and IPv6 ICMP echo handling,
and add support for transmitting ICMP echo requests and delivering
ICMP echo replies to a (not yet implemented) ping_rx() function.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown