[lkrnprefix] Make real-mode setup code relocatable

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>
[nfs] Fix an invalid free() when loading a regular (non-symlink) file

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>
[intel] Increase receive ring fill level

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>
[syslog] Strip invalid characters from hostname

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>
[test] Add self-tests for strdup()

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[libc] Prevent strndup() from reading beyond the end of the string

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>
[nfs] Rewrite NFS URI handling

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>
[efi] Allow for optional protocols

Signed-off-by: Michael Brown <mcb30@ipxe.org>
[efi] Make EFI_DEVICE_PATH_TO_TEXT_PROTOCOL optional

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>
[efi] Make EFI_HII_DATABASE_PROTOCOL optional

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>
[efi] Do not try to fetch loaded image device path protocol

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>
[ipv6] Fix definition of IN6_IS_ADDR_LINKLOCAL()

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>
[dhcpv6] Do not set sin6_scope_id on the unspecified client socket address

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>
[ipv6] Do not set sin6_scope_id on source address

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>
[ipv6] Include network device when transcribing multicast addresses

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>
[ipv6] Avoid potentially copying from a NULL pointer in ipv6_tx()

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>
[librm] Allow for the PIC interrupt vector offset to be changed

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>
[ifmgmt] Do not sleep CPU while configuring network devices

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>
[ethernet] Provide eth_random_addr() to generate random Ethernet addresses

Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>