[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>
[scsi] Improve sense code parsing

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>