ipxe.git
5 years ago[intel] Add INTEL_NO_PHY_RST for another I218-LM variant
Mika Tiainen [Tue, 9 Feb 2016 20:38:29 +0000 (22:38 +0200)] 
[intel] Add INTEL_NO_PHY_RST for another I218-LM variant

Fixed booting on HP EliteBook 820 G2 laptop.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[efi] Add missing definitions for function key scancodes
Michael Brown [Fri, 12 Feb 2016 13:08:52 +0000 (13:08 +0000)] 
[efi] Add missing definitions for function key scancodes

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[pxe] Clarify comments regarding shrinking of cached DHCP packet
Michael Brown [Thu, 11 Feb 2016 19:14:00 +0000 (19:14 +0000)] 
[pxe] Clarify comments regarding shrinking of cached DHCP packet

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[iobuf] Improve robustness of I/O buffer allocation
Michael Brown [Thu, 11 Feb 2016 18:44:24 +0000 (18:44 +0000)] 
[iobuf] Improve robustness of I/O buffer allocation

Guard against various corner cases (such as zero-length buffers, zero
alignments, and integer overflow when rounding up allocation lengths
and alignments) and ensure that the struct io_buffer is correctly
aligned even when the caller requests a non-zero alignment for the I/O
buffer itself.

Add self-tests to verify that the resulting alignments and lengths are
correct for a range of allocations.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[malloc] Guard against unsigned integer overflow
Michael Brown [Sat, 6 Feb 2016 10:20:57 +0000 (10:20 +0000)] 
[malloc] Guard against unsigned integer overflow

Commit f3fbb5f ("[malloc] Avoid integer overflow for excessively large
memory allocations") fixed signed integer overflow issues caused by
the use of ssize_t, but did not guard against unsigned integer
overflow.

Add explicit checks for unsigned integer overflow where needed.  As a
side bonus, erroneous calls to malloc_dma() with an (illegal) size of
zero will now fail cleanly.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[ehci] Add extra debugging information
Michael Brown [Fri, 5 Feb 2016 21:03:17 +0000 (21:03 +0000)] 
[ehci] Add extra debugging information

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[ath9k] Remove broken ath_rxbuf_alloc()
Michael Brown [Thu, 28 Jan 2016 14:15:36 +0000 (14:15 +0000)] 
[ath9k] Remove broken ath_rxbuf_alloc()

ath_rx_init() demonstrates some serious confusion over how to use
pointers, resulting in (uint32_t*)NULL being used as a temporary
variable.  This does not end well.

The broken code in question is performing manual alignment of I/O
buffers, which can now be achieved more simply using alloc_iob_raw().
Fix by removing ath_rxbuf_alloc() entirely.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[slam] Avoid potential division by zero
Michael Brown [Wed, 27 Jan 2016 23:27:47 +0000 (23:27 +0000)] 
[slam] Avoid potential division by zero

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[tcp] Guard against malformed TCP options
Michael Brown [Wed, 27 Jan 2016 23:06:50 +0000 (23:06 +0000)] 
[tcp] Guard against malformed TCP options

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[intel] Add INTEL_NO_PHY_RST for I218-LM
Hummel Frank [Wed, 27 Jan 2016 13:07:42 +0000 (13:07 +0000)] 
[intel] Add INTEL_NO_PHY_RST for I218-LM

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[uri] Apply URI decoding for all parsed URIs
Michael Brown [Tue, 26 Jan 2016 16:16:13 +0000 (16:16 +0000)] 
[uri] Apply URI decoding for all parsed URIs

The various early-exit paths in parse_uri() accidentally bypass the
URI field decoding.  The result is that opaque or relative URIs do not
undergo URI field decoding, resulting in double-encoding when the URIs
are subsequently used.  For example:

  #!ipxe
  set mac ${macstring}
  imgfetch /boot/by-mac/${mac:uristring}

would result in an HTTP GET such as

  GET /boot/by-mac/00%253A0c%253A29%253Ac5%253A39%253Aa1 HTTP/1.1

rather than the expected

  GET /boot/by-mac/00%3A0c%3A29%3Ac5%3A39%3Aa1 HTTP/1.1

Fix by ensuring that URI decoding is always applied regardless of the
URI format.

Reported-by: Andrew Widdersheim <awiddersheim@inetu.net>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[tftp] Mangle initial slash on TFTP URIs
Michael Brown [Thu, 21 Jan 2016 16:24:16 +0000 (16:24 +0000)] 
[tftp] Mangle initial slash on TFTP URIs

TFTP URIs are intrinsically problematic, since:

- TFTP servers may use either normal slashes or backslashes as a
  directory separator,

- TFTP servers allow filenames to be specified using relative paths
  (with no initial directory separator),

- TFTP filenames present in a DHCP filename field may use special
  characters such as "?" or "#" that prevent parsing as a generic URI.

As of commit 7667536 ("[uri] Refactor URI parsing and formatting"), we
have directly constructed TFTP URIs from DHCP next-server and filename
pairs, avoiding the generic URI parser.  This eliminated the problems
related to special characters, but indirectly made it impossible to
parse a "tftp://..." URI string into a TFTP URI with a non-absolute
path.

Re-introduce the convention of requiring an extra slash in a
"tftp://..." URI string in order to specify a TFTP URI with an initial
slash in the filename.  For example:

  tftp://192.168.0.1/boot/pxelinux.0  => RRQ "boot/pxelinux.0"
  tftp://192.168.0.1//boot/pxelinux.0 => RRQ "/boot/pxelinux.0"

This is ugly, but there seems to be no other sensible way to provide
the ability to specify all possible TFTP filenames.

A side-effect of this change is that format_uri() will no longer add a
spurious initial "/" when formatting a relative URI string.  This
improves the console output when fetching an image specified via a
relative URI.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[ocsp] Avoid including a double path separator in request URI
Michael Brown [Thu, 21 Jan 2016 17:50:34 +0000 (17:50 +0000)] 
[ocsp] Avoid including a double path separator in request URI

The OCSP responder URI included within an X.509 certificate may or may
not include a trailing slash.  We currently rely on the fact that
format_uri() incorrectly inserts an initial slash, which we include
unconditionally within the OCSP request URI.

Switch to using uri_encode() directly, and insert a slash only if the
X.509 certificate's OCSP responder URI does not already include a
trailing slash.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[uri] Avoid potentially large stack allocation
Michael Brown [Thu, 21 Jan 2016 15:53:44 +0000 (15:53 +0000)] 
[uri] Avoid potentially large stack allocation

Avoid potentially large stack allocation in resolve_path().

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[autoboot] Fix incorrect boolean logic
Michael Brown [Tue, 19 Jan 2016 08:16:17 +0000 (08:16 +0000)] 
[autoboot] Fix incorrect boolean logic

Commit 53d2d9e ("[uri] Generalise tftp_uri() to pxe_uri()") introduced
a regression in which an NFS root path would no longer be treated as
an unsupported root path, causing a boot with an NFS root path to fail
with a "Could not open SAN device" error.

Reported-by: David Evans <dave.evans55@googlemail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[smsc95xx] Reserve headroom in received packets
Michael Brown [Tue, 19 Jan 2016 00:04:33 +0000 (00:04 +0000)] 
[smsc95xx] Reserve headroom in received packets

Some protocols (such as ARP) may modify the received packet and re-use
the same I/O buffer for transmission of a reply.  The SMSC95XX
transmit header is larger than the receive header: the re-used I/O
buffer therefore does not have sufficient headroom for the transmit
header, and the ARP reply will therefore fail to be transmitted.  This
is essentially the same problem as in commit 2e72d10 ("[ncm] Reserve
headroom in received packets").

Fix by reserving sufficient space at the start of each received packet
to allow for the difference between the lengths of the transmit and
receive headers.

This problem is not caught by the current driver development test
suite (documented at http://ipxe.org/dev/driver), since even the large
file transfer tests tend to completely sufficiently quickly that there
is no need for the server to ever send an ARP request.  The failure
shows up only when using a very slow protocol such as RFC7440-enhanced
TFTP (as used by Windows Deployment Services).

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[usb] Allow USB endpoints to specify a reserved header length for refills
Michael Brown [Tue, 19 Jan 2016 00:01:11 +0000 (00:01 +0000)] 
[usb] Allow USB endpoints to specify a reserved header length for refills

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[smsc95xx] Enable LEDs
Michael Brown [Wed, 13 Jan 2016 07:25:05 +0000 (07:25 +0000)] 
[smsc95xx] Enable LEDs

The LED pins are configured by default as GPIO inputs.  While it is
conceivable that a board might actually use these pins as GPIOs, no
such board is known to exist.

The Linux smsc95xx driver configures these pins unconditionally as LED
outputs.  Assume that it is safe to do likewise.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[netdevice] Add "ifname" setting
Andrew Widdersheim [Sat, 16 Jan 2016 16:21:34 +0000 (11:21 -0500)] 
[netdevice] Add "ifname" setting

Expose the network interface name (e.g. "net0") as a setting.  This
allows a script to obtain the name of the most recently opened network
interface via ${netX/ifname}.

Signed-off-by: Andrew Widdersheim <amwiddersheim@gmail.com>
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[build] Add named configuration for public cloud environments
Michael Brown [Mon, 18 Jan 2016 08:37:27 +0000 (08:37 +0000)] 
[build] Add named configuration for public cloud environments

Add a named CONFIG=cloud configuration, which enables console types
useful for obtaining output from virtual machines in public clouds
such as AWS EC2.

An image suitable for use in AWS EC2 can be built using

  make bin/ipxe.usb CONFIG=cloud EMBED=config/cloud/aws.ipxe

The embedded script will direct iPXE to download and execute the EC2
"user-data" file, which is always available to an EC2 VM via the URI
http://169.254.169.254/latest/user-data (regardless of the VPC
networking settings).  The boot can therefore be controlled by
modifying the per-instance user data, without having to modify the
boot disk image.

Console output can be obtained via syslog (with a syslog server
configured in the user-data script), via the AWS "System Log" (after
the instance has been stopped), or as a last resort from the log
partition on the boot disk.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[stp] Fix incorrectly disambiguated errors
Michael Brown [Thu, 14 Jan 2016 12:39:01 +0000 (12:39 +0000)] 
[stp] Fix incorrectly disambiguated errors

The three nominally-disambiguated ENOTSUP errors accidentally all used
the same error disambiguator, rendering them identical.  Fix by
changing all three values.  We avoid reusing the 0x01 disambiguator
value, since that remains ambiguous in older binaries.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[debug] Allow debug colourisation to be disabled
Michael Brown [Tue, 12 Jan 2016 15:35:06 +0000 (15:35 +0000)] 
[debug] Allow debug colourisation to be disabled

Some BIOS console redirection capabilities do not work well with the
colourised debug messages used by iPXE.  We already allow the range of
colours to be controlled via the DBGCOL=... build parameter.  Extend
this syntax to allow DBGCOL=0 to be used to mean "disable colours".

Requested-by: Wissam Shoukair <wissams@mellanox.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[i386] Add check_bios_interrupts() debug function
Michael Brown [Tue, 12 Jan 2016 08:27:59 +0000 (08:27 +0000)] 
[i386] Add check_bios_interrupts() debug function

Provide a debug function check_bios_interrupts() to look for changes
to the interrupt vector table.  This can be useful when investigating
the behaviour (including crashes) of external PXE NBPs.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[pxe] Add debug message to display real-mode segment addresses
Michael Brown [Mon, 11 Jan 2016 16:21:08 +0000 (16:21 +0000)] 
[pxe] Add debug message to display real-mode segment addresses

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[pxe] Colourise debug output
Michael Brown [Mon, 11 Jan 2016 16:20:05 +0000 (16:20 +0000)] 
[pxe] Colourise debug output

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[infiniband] Profile post work queue entry operations
Michael Brown [Sun, 10 Jan 2016 15:44:00 +0000 (15:44 +0000)] 
[infiniband] Profile post work queue entry operations

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[tftp] Do not change current working URI when TFTP server is cleared
Michael Brown [Sat, 9 Jan 2016 14:51:21 +0000 (14:51 +0000)] 
[tftp] Do not change current working URI when TFTP server is cleared

For historical reasons, iPXE sets the current working URI to the root
of the TFTP server whenever the TFTP server address is changed.  This
was originally implemented in the hope of allowing a DHCP-provided
TFTP filename to be treated simply as a relative URI.  This usage
turns out to be impractical since DHCP-provided TFTP filenames may
include characters which would have special significance to the URI
parser, and so the DHCP next-server+filename combination is now
handled by the dedicated pxe_uri() function instead.

The practice of setting the current working URI to the root of the
TFTP server is potentially helpful for interactive uses of iPXE,
allowing a user to type e.g.

  iPXE> dhcp
  Configuring (net0 52:54:00:12:34:56)... ok
  iPXE> chain pxelinux.0

and have the URI "pxelinux.0" interpreted as being relative to the
root of the TFTP server provided via DHCP.

The current implementation of tftp_apply_settings() has an unintended
flaw.  When the "dhcp" command is used to renew a DHCP lease (or to
pick up potentially modified DHCP options), the old settings block
will be unregistered before the new settings block is registered.
This causes tftp_apply_settings() to believe that the TFTP server has
been changed twice (to 0.0.0.0 and back again), and so the current
working URI will always be set to the root of the TFTP server, even if
the DHCP response provides exactly the same TFTP server as previously.

Fix by doing nothing in tftp_apply_settings() whenever there is no
TFTP server address.

Debugged-by: Andrew Widdersheim <awiddersheim@inetu.net>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[downloader] Update image URI in response to a redirection
Michael Brown [Sat, 9 Jan 2016 13:23:13 +0000 (13:23 +0000)] 
[downloader] Update image URI in response to a redirection

Update the image's recorded URI when a download redirection occurs.
This ensures that URIs relative to a redirected download are resolved
correctly.

In particular, this allows for the use of relative URIs in scripts
that are themselves downloaded via a redirection, such as the HTTP 301
redirection used to fix up URIs pointing to directories but omitting
the trailing slash (e.g. "http://boot.ipxe.org/demo", which will be
redirected to "http://boot.ipxe.org/demo/").

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[image] Provide image_set_uri() to modify an image's URI
Michael Brown [Sat, 9 Jan 2016 13:22:37 +0000 (13:22 +0000)] 
[image] Provide image_set_uri() to modify an image's URI

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[http] Handle relative redirection URIs
Michael Brown [Sat, 9 Jan 2016 13:20:55 +0000 (13:20 +0000)] 
[http] Handle relative redirection URIs

Resolve redirection URIs as being relative to the original HTTP
request URI, rather than treating them as being implicitly relative to
the current working URI.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[usb] Add support for numeric keypad on USB keyboards
Michael Brown [Wed, 6 Jan 2016 16:30:01 +0000 (16:30 +0000)] 
[usb] Add support for numeric keypad on USB keyboards

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[romprefix] Report an optimistic runtime size estimate
Michael Brown [Tue, 5 Jan 2016 23:40:18 +0000 (23:40 +0000)] 
[romprefix] Report an optimistic runtime size estimate

Commit 5de45cd ("[romprefix] Report a pessimistic runtime size
estimate") set the PCI3.0 "runtime size" field equal to the worst-case
runtime size, on the basis that there is no guarantee that PMM
allocation will succeed and hence no guarantee that we will be able to
shrink the ROM image.

On a PCI3.0 system where PMM allocation would succeed, this can cause
the BIOS to unnecessarily refuse to initialise the iPXE ROM due to a
perceived shortage of option ROM space.

Fix by reporting the best-case runtime size via the PCI header, and
checking that we have sufficient runtime space (if applicable).  This
allows iPXE ROMs to initialise on PCI3.0 systems that might otherwise
fail due to a shortage of option ROM space.

This may cause iPXE ROMs to fail to initialise on PCI3.0 systems where
PMM is broken.  (Pre-PCI3.0 systems are unaffected since there must
already have been sufficient option ROM space available for the
initialisation entry point to be called.)

On balance, it seems preferable to avoid breaking "good" systems
(PCI3.0 with working PMM) at the cost of potentially breaking "bad"
systems (PCI3.0 with broken PMM).

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[vmware] Expose GuestRPC mechanism in 64-bit builds
Michael Brown [Tue, 5 Jan 2016 17:20:36 +0000 (17:20 +0000)] 
[vmware] Expose GuestRPC mechanism in 64-bit builds

The GuestRPC mechanism (used for VMWARE_SETTINGS and CONSOLE_VMWARE)
does not use any real-mode code and so can be exposed in both 64-bit
and 32-bit builds.

Reported-by: Matthew Helton <mwhelton@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[crypto] Dual-license more selected DRBG files
Michael Brown [Mon, 4 Jan 2016 15:39:07 +0000 (15:39 +0000)] 
[crypto] Dual-license more selected DRBG files

Allow the use of the iPXE DRBG implementation in BSD-licensed
projects.

Requested-by: Sean Davis <dive@hq.endersgame.net>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[smsc95xx] Fetch MAC from SMBIOS OEM string for Honeywell VM3
Michael Brown [Wed, 23 Dec 2015 15:25:31 +0000 (15:25 +0000)] 
[smsc95xx] Fetch MAC from SMBIOS OEM string for Honeywell VM3

The Honeywell VM3 has no attached EEPROM, and records the MAC address
within an SMBIOS OEM string.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[crypto] Dual-license selected DRBG files
Michael Brown [Thu, 31 Dec 2015 14:44:45 +0000 (14:44 +0000)] 
[crypto] Dual-license selected DRBG files

Allow the use of the iPXE DRBG implementation in BSD-licensed
projects.

Requested-by: Sean Davis <dive@hq.endersgame.net>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[smsc95xx] Allow for multiple methods for obtaining the MAC address
Michael Brown [Wed, 23 Dec 2015 15:02:48 +0000 (15:02 +0000)] 
[smsc95xx] Allow for multiple methods for obtaining the MAC address

The SMSC95xx devices tend to be used in embedded systems with a
variety of ad-hoc mechanisms for storing the MAC address.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[settings] Expose SMBIOS settings as global variables
Michael Brown [Wed, 23 Dec 2015 15:28:08 +0000 (15:28 +0000)] 
[settings] Expose SMBIOS settings as global variables

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[bios] Add support for injecting keypresses
Michael Brown [Fri, 18 Dec 2015 10:05:58 +0000 (10:05 +0000)] 
[bios] Add support for injecting keypresses

When USB network card drivers are used, the BIOS' legacy USB
capability is necessarily disabled since there is no way to share the
host controller between the BIOS and iPXE.

Commit 3726722 ("[usb] Add basic support for USB keyboards") added
support allowing a USB keyboard to be used within iPXE.  However,
external code such as a PXE NBP has no way to utilise this support,
and so a USB keyboard cannot be used to control a PXE NBP loaded from
a USB network card.

Add support for injecting keypresses from any iPXE console into the
BIOS keyboard buffer.  This allows external code such as a PXE NBP to
function with a USB keyboard even after the BIOS' legacy USB
capability has been disabled.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[build] Allow extra objects to be included in an all-drivers build
Michael Brown [Thu, 17 Dec 2015 13:45:35 +0000 (13:45 +0000)] 
[build] Allow extra objects to be included in an all-drivers build

The build system allows for additional drivers (or other objects) to
be specified using build targets such as

  make bin/intel--realtek.usb
  make bin/8086100e--8086100f.mrom

This currently fails if the base target is the "bin/ipxe.*" all-drivers
target, e.g.

  make bin/ipxe--acm.usb

Fix the build target parsing logic to allow additional drivers (or
other objects) to be included on top of the base all-drivers target.

This can be used to include USB network card drivers, which are not
yet included by default in the all-drivers build.

Reported-by: Andrew Sloma <asloma@lenovo.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[efi] Centralise EFI file system info GUIDs
Michael Brown [Wed, 9 Dec 2015 17:35:24 +0000 (17:35 +0000)] 
[efi] Centralise EFI file system info GUIDs

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[xhci] Ensure that zero-length packets are not part of a TRB chain
Michael Brown [Mon, 7 Dec 2015 22:30:27 +0000 (22:30 +0000)] 
[xhci] Ensure that zero-length packets are not part of a TRB chain

Some xHCI controllers (such as qemu's emulated xHCI controller) do not
correctly handle zero-length packets that are part of a TRB chain.
The zero-length TRB ends up being squashed and does not result in a
zero-length packet as seen by the device.

Work around this problem by marking the zero-length packet as
belonging to a separate transfer descriptor.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[intel] Add INTEL_NO_PHY_RST for I217-LM
Torgeir Wulfsberg [Mon, 7 Dec 2015 19:52:16 +0000 (19:52 +0000)] 
[intel] Add INTEL_NO_PHY_RST for I217-LM

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[acm] Add support for CDC-ACM (aka USB RNDIS) devices
Michael Brown [Tue, 1 Dec 2015 14:46:48 +0000 (14:46 +0000)] 
[acm] Add support for CDC-ACM (aka USB RNDIS) devices

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[usb] Allow additional settling time for out-of-spec hubs
Michael Brown [Mon, 7 Dec 2015 00:54:01 +0000 (00:54 +0000)] 
[usb] Allow additional settling time for out-of-spec hubs

Some hubs (e.g. the Avocent Corp. Virtual Hub on a Lenovo x3550
Integrated Management Module) have been observed to require more than
the standard 200ms for ports to stabilise, with the result that
devices appear to disconnect and immediately reconnect during the
initial bus enumeration.

Work around this problem by allowing specific hubs an extra 500ms of
settling time.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[usb] Allow USB device IDs to include arbitrary driver-specific data
Michael Brown [Mon, 7 Dec 2015 00:32:08 +0000 (00:32 +0000)] 
[usb] Allow USB device IDs to include arbitrary driver-specific data

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[usb] Record USB device speed separately from current port speed
Michael Brown [Sun, 6 Dec 2015 23:41:26 +0000 (23:41 +0000)] 
[usb] Record USB device speed separately from current port speed

Record the speed of a USB device based on the port's speed at the time
that the device was enabled.  This allows us to remember the device's
speed even after the device has been disconnected (and so the port's
current speed has changed).

In particular, this allows us to correctly identify the transaction
translator for a low-speed or full-speed device after the device has
been disconnected.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[usb] Use port->disconnected to check for disconnected devices
Michael Brown [Sun, 6 Dec 2015 23:22:37 +0000 (23:22 +0000)] 
[usb] Use port->disconnected to check for disconnected devices

The usb_message() and usb_stream() functions currently check for
port->speed==USB_SPEED_NONE to determine whether or not a device has
been unplugged.  This test will give a false negative result if a new
device has been plugged in before the hotplug mechanism has finished
handling the removal of the old device.

Fix by checking instead the port->disconnected flag, which is now
cleared only after completing the removal of the old device.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[efi] Add %.usb target for building EFI-bootable USB (or other) disk images
Michael Brown [Sat, 5 Dec 2015 23:54:10 +0000 (23:54 +0000)] 
[efi] Add %.usb target for building EFI-bootable USB (or other) disk images

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[bitops] Provide BIT_QWORD_PTR()
Michael Brown [Tue, 24 Nov 2015 17:28:23 +0000 (17:28 +0000)] 
[bitops] Provide BIT_QWORD_PTR()

Provide BIT_QWORD_PTR() to allow for easy extraction of non-endian
fields (e.g. Infiniband GUIDs) without unnecessary byte swapping.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[smsc95xx] Add driver for SMSC/Microchip LAN95xx USB Ethernet NICs
Michael Brown [Fri, 13 Nov 2015 13:51:17 +0000 (13:51 +0000)] 
[smsc95xx] Add driver for SMSC/Microchip LAN95xx USB Ethernet NICs

Tested using QEMU and usbredir to expose the LAN9512 chip present on a
Raspberry Pi.

There is a known issue with the LAN9512: an extra two bytes are
appended to every transmitted packet.  These two bytes comprise:

  {   0x00,   0x08 } if packet length == 0 (mod 8)
  { CRC[0],   0x00 } if packet length == 7 (mod 8)
  { CRC[0], CRC[1] } otherwise

The extra bytes are appended whether the Ethernet CRC is generated
manually or added automatically by the hardware.  The issue occurs
with the Linux kernel driver as well as the iPXE driver.  It appears
to be an undocumented hardware errata.

TCP/IP traffic is not affected, since the IP header length field
causes the extraneous bytes to be discarded by the receiver.  However,
protocols that rely on the length of the Ethernet frame (such as FCoE
or iPXE's "lotest" protocol) will be unusable on this hardware.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[bitops] Fix definitions for big-endian devices
Michael Brown [Mon, 30 Nov 2015 22:22:13 +0000 (22:22 +0000)] 
[bitops] Fix definitions for big-endian devices

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[pci] Add definitions for PCI Express function level reset (FLR)
Michael Brown [Wed, 25 Nov 2015 09:32:45 +0000 (09:32 +0000)] 
[pci] Add definitions for PCI Express function level reset (FLR)

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[infiniband] Add qword accessors for ib_guid and ib_gid
Michael Brown [Mon, 30 Nov 2015 16:24:23 +0000 (16:24 +0000)] 
[infiniband] Add qword accessors for ib_guid and ib_gid

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[infiniband] Add definitions for FDR and EDR link speeds
Michael Brown [Wed, 25 Nov 2015 08:44:20 +0000 (08:44 +0000)] 
[infiniband] Add definitions for FDR and EDR link speeds

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[intel] Correct definition of receive overrun bit
Michael Brown [Sun, 22 Nov 2015 19:17:24 +0000 (19:17 +0000)] 
[intel] Correct definition of receive overrun bit

Reported-by: Robin Smidsrød <robin@smidsrod.no>
Tested-by: Robin Smidsrød <robin@smidsrod.no>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[intel] Forcibly skip PHY reset on some models
Michael Brown [Sun, 22 Nov 2015 18:35:50 +0000 (18:35 +0000)] 
[intel] Forcibly skip PHY reset on some models

On some models (notably ICH), the PHY reset mechanism appears to be
broken.  In particular, the PHY_CTRL register will be correctly loaded
from NVM but the values will not be propagated to the "OEM bits" PHY
register.  This typically has the effect of dropping the link speed to
10Mbps.

Since the original version of this driver in commit 945e428 ("[intel]
Replace driver for Intel Gigabit NICs"), we have always worked around
this problem by skipping the PHY reset if the link is already up.
Enhance this workaround by explicitly checking for known-broken PCI
IDs.

Reported-by: Robin Smidsrød <robin@smidsrod.no>
Tested-by: Robin Smidsrød <robin@smidsrod.no>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[comboot] Reset console before starting COMBOOT executable
Michael Brown [Tue, 17 Nov 2015 14:17:03 +0000 (14:17 +0000)] 
[comboot] Reset console before starting COMBOOT executable

iPXE does not call shutdown() before invoking a COMBOOT executable,
since the executable is allowed to make API calls back into iPXE.  If
a background picture is used, then the console will not be restored to
text mode before invoking the COMBOOT executable.  This can cause
undefined behaviour.

Fix by adding an explicit call to console_reset() immediately before
invoking a COMBOOT or COM32 executable, analogous to the call made to
console_reset() immediately before invokving a PXE NBP.

Debugged-by: Andrew Widdersheim <awiddersheim@inetu.net>
Tested-by: Andrew Widdersheim <awiddersheim@inetu.net>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[dhcp] Limit maximum number of DHCP discovery deferrals
Michael Brown [Tue, 10 Nov 2015 14:05:46 +0000 (14:05 +0000)] 
[dhcp] Limit maximum number of DHCP discovery deferrals

For switches which remain permanently in the non-forwarding state (or
which erroneously report a non-forwarding state), ensure that iPXE
will eventually give up waiting for the link to become unblocked.

Originally-fixed-by: Wissam Shoukair <wissams@mellanox.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[intel] Add PCI IDs for i210/i211 flashless operation
Kyösti Mälkki [Wed, 4 Nov 2015 20:27:37 +0000 (22:27 +0200)] 
[intel] Add PCI IDs for i210/i211 flashless operation

Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[dhcp] Reset start time when deferring discovery
Michael Brown [Fri, 30 Oct 2015 13:18:51 +0000 (13:18 +0000)] 
[dhcp] Reset start time when deferring discovery

If we detect (via STP) that a switch port is in a non-forwarding
state, then the link is marked as being temporarily blocked and DHCP
discovery will be deferred until the link becomes unblocked.

The timer used to decide when to give up waiting for ProxyDHCPOFFERs
is currently based on the time that DHCP discovery was started, and
makes no allowances for any time spent waiting for the link to become
unblocked.  Consequently, if STP is used then the timeout for
ProxyDHCPOFFERs becomes essentially zero.

Fix by resetting the recorded start time whenever DHCP discovery is
deferred due to a blocked link.

Debugged-by: Sebastian Roth <sebastian.roth@zoho.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[efi] Add support for EFI_GRAPHICS_OUTPUT_PROTOCOL frame buffer consoles
Michael Brown [Mon, 5 Oct 2015 18:19:26 +0000 (19:19 +0100)] 
[efi] Add support for EFI_GRAPHICS_OUTPUT_PROTOCOL frame buffer consoles

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[build] Generalise CONSOLE_VESAFB to CONSOLE_FRAMEBUFFER
Michael Brown [Fri, 16 Oct 2015 15:14:29 +0000 (16:14 +0100)] 
[build] Generalise CONSOLE_VESAFB to CONSOLE_FRAMEBUFFER

The name "vesafb" is intrinsically specific to a BIOS environment.
Generalise the build configuration option CONSOLE_VESAFB to
CONSOLE_FRAMEBUFFER, in preparation for adding EFI framebuffer
support.

Existing configurations using CONSOLE_VESAFB will continue to work.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[console] Tidy up config/console.h
Michael Brown [Thu, 15 Oct 2015 16:50:12 +0000 (17:50 +0100)] 
[console] Tidy up config/console.h

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[fbcon] Move margin calculations to fbcon.c
Michael Brown [Wed, 14 Oct 2015 21:01:29 +0000 (22:01 +0100)] 
[fbcon] Move margin calculations to fbcon.c

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[fbcon] Allow character height to be selected at runtime
Michael Brown [Wed, 14 Oct 2015 19:42:42 +0000 (20:42 +0100)] 
[fbcon] Allow character height to be selected at runtime

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[efi] Import EFI_HII_FONT_PROTOCOL definitions
Michael Brown [Tue, 6 Oct 2015 17:50:41 +0000 (18:50 +0100)] 
[efi] Import EFI_HII_FONT_PROTOCOL definitions

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[efi] Update to current EDK2 headers
Michael Brown [Tue, 6 Oct 2015 17:44:21 +0000 (18:44 +0100)] 
[efi] Update to current EDK2 headers

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[efi] Reset root directory when installing EFI_SIMPLE_FILE_SYSTEM_PROTOCOL
Michael Brown [Tue, 6 Oct 2015 23:21:34 +0000 (00:21 +0100)] 
[efi] Reset root directory when installing EFI_SIMPLE_FILE_SYSTEM_PROTOCOL

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[http] Verify server port when reusing a pooled connection
Michael Brown [Fri, 2 Oct 2015 06:54:51 +0000 (07:54 +0100)] 
[http] Verify server port when reusing a pooled connection

Reported-by: Allen <allen@gtf.org>
Reported-by: Andreas Hammarskjöld <junior@2PintSoftware.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[peerdist] Avoid NULL pointer dereference for plaintext blocks
Michael Brown [Tue, 29 Sep 2015 00:24:36 +0000 (01:24 +0100)] 
[peerdist] Avoid NULL pointer dereference for plaintext blocks

Avoid accidentally dereferencing a NULL cipher context pointer for
plaintext blocks (which are usually messages with a block length of
zero, indicating a missing block).

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[malloc] Avoid integer overflow for excessively large memory allocations
Michael Brown [Tue, 29 Sep 2015 00:07:08 +0000 (01:07 +0100)] 
[malloc] Avoid integer overflow for excessively large memory allocations

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[efi] Expose an UNDI interface alongside the existing SNP interface
Michael Brown [Sun, 27 Sep 2015 16:21:24 +0000 (17:21 +0100)] 
[efi] Expose an UNDI interface alongside the existing SNP interface

UEFI UNDI is a hideously ugly lump of poorly specified garbage bolted
on as an appendix of the UEFI specification.  My personal favourite
line from the UNDI 'specification' is section E.2.2, which states
"Basically, the rule is: Do it right, or don't do it at all".  The
author appears to believe that such exhortations are a viable
substitute for documenting what it is that the wretched reader is
supposed to, in fact, do.

(Second favourite is the section listing the pros and cons of various
driver types.  This fails to identify a single con for the mythical
"Hardware UNDI", a design so insanely intrinsically slow that it
appears to have been the inspiration for the EFI_USB_IO_PROTOCOL.)

UNDI is functionally isomorphic to the substantially less preposterous
EFI_SIMPLE_NETWORK_PROTOCOL.  Provide an UNDI interface (as a thin
wrapper around the existing SNP interface) to allow for use by
third-party software that has made poor life choices.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[efi] Avoid infinite loops when asked to stop non-existent devices
Michael Brown [Mon, 28 Sep 2015 01:54:53 +0000 (02:54 +0100)] 
[efi] Avoid infinite loops when asked to stop non-existent devices

Calling EDK2's OpenProtocol() with attributes BY_DRIVER|EXCLUSIVE will
call DisconnectController() in a loop to attempt to dislodge any
existing openers with attributes BY_DRIVER.  The loop will continue
indefinitely until either no such openers remain, or until
DisconnectController() returns an error.

If our driver binding protocol's Stop() method is ever called to
disconnect a device that we are not in fact driving, then return
EFI_DEVICE_ERROR rather than EFI_SUCCESS, in order to break this
potentially infinite loop.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[efi] Work around broken 32-bit PE executable parsing in ImageHlp.dll
Michael Brown [Fri, 25 Sep 2015 12:41:32 +0000 (13:41 +0100)] 
[efi] Work around broken 32-bit PE executable parsing in ImageHlp.dll

The Microsoft PE/COFF specification defines the MajorLinkerVersion and
MinorLinkerVersion fields as "The linker major version number" and
"The linker minor version number" respectively, and has nothing more
to say on the matter.  These fields have no significance: they do not
affect the interpretation of the remainder of the file, but merely
provide diagnostic information for interested humans to read.

Apparently, versions 2.4 and earlier of the Microsoft linker produced
binaries so incorrigibly cursed that even to attempt to parse such a
binary would risk summoning a plague of enraged spiders.  To protect
users from unwanted arachnids, ImageHlp.dll's MapAndLoad() function
will helpfully fail to map and/or load a 32-bit binary unless the
linker version field indicates version 2.5 or later.  (64-bit binaries
are exempt from such helpfulness.)

Work around the broken Microsoft ImageHlp.dll library by providing a
linker version number that will satisfy the arbitrary whims of the
MapAndLoad() function.

This mirrors wimboot commit 670c7e2 ("[efi] Work around broken 32-bit
PE executable parsing in ImageHlp.dll").

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[vmxnet3] Avoid completely filling the TX descriptor ring
Carl Henrik Lunde [Wed, 16 Sep 2015 10:10:04 +0000 (11:10 +0100)] 
[vmxnet3] Avoid completely filling the TX descriptor ring

Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[pxe] Notify BIOS via INT 1a,564e for each new network device
Michael Brown [Tue, 15 Sep 2015 12:43:35 +0000 (13:43 +0100)] 
[pxe] Notify BIOS via INT 1a,564e for each new network device

Use INT 1a,564e to notify the BIOS of each network device that we
detect.  This provides an opportunity for the BIOS to implement
platform policy such as changing the MAC address by issuing a call to
PXENV_UNDI_SET_STATION_ADDRESS.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[pxe] Invoke INT 1a,564e when PXE stack is activated
Michael Brown [Tue, 15 Sep 2015 12:20:17 +0000 (13:20 +0100)] 
[pxe] Invoke INT 1a,564e when PXE stack is activated

Invoke INT 1a,564e whenever a PXE stack is activated, passing the
address of the PXENV+ structure in %es:%bx.  This is designed to allow
a BIOS to be notified when a PXE stack has been installed, providing
an opportunity for start-of-day commands such as setting the MAC
address according to a policy chosen by the BIOS.

PXE defines INT 1a,5650 as a means of locating the PXENV+ structure:
this call returns %ax=0x564e and the address of the PXENV+ structure
in %es:%bx.  We choose INT 1a,564e as a fairly natural notification
call, using the parameters as would be returned by INT 1a,5650.

The full calling convention (documented as per section 3.1 of the PXE
specification) is:

  INT 1a,564e - PXE installation notification
  Enter:
    %ax = 0x564e
    %es = 16-bit segment address of the PXENV+ structure
    %bx = 16-bit offset of the PXENV+ structure
  Exit:
    %edx may be trashed (as is the case for INT 1a,5650)
    All other register contents must be preserved
    CF is cleared
    IF is preserved
    All other flags are undefined

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[efi] Minimise use of iPXE header files when building host utilities
Michael Brown [Mon, 14 Sep 2015 22:29:24 +0000 (23:29 +0100)] 
[efi] Minimise use of iPXE header files when building host utilities

Avoid dragging in unnecessary iPXE header files such as <ipxe/uuid.h>
and <ipxe/tables.h> when building host utilities, and ensure that
FILE_LICENCE() (present in the imported EDK2 headers) expands to a
no-op.

Reported-by: Michael Tautschnig <mt@debian.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[build] Remove dependency on libiberty
Michael Brown [Mon, 14 Sep 2015 21:49:34 +0000 (22:49 +0100)] 
[build] Remove dependency on libiberty

Commit 7d36a1b ("[build] Explicitly link efilink against -liberty")
introduced a dependency on libiberty to cope with old versions of
libbfd.  This commit dates from 2008 and seems to apply only to what
are now extremely old versions of libbfd (prior to binutils 2.12).

There are systems (such as current Debian) which do not include
libiberty within the binutils packages.  On such systems, our build
dependency on libiberty represents a pointless hurdle.

Remove the explicit dependency on libiberty, hoping that there are no
modern systems where this will cause a problem.

Suggested-by: Ben Hildred <42656e@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[ncm] Support setting MAC address
Michael Brown [Mon, 14 Sep 2015 21:45:56 +0000 (22:45 +0100)] 
[ncm] Support setting MAC address

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[efi] Expose unused USB devices via EFI_USB_IO_PROTOCOL
Michael Brown [Thu, 10 Sep 2015 16:22:03 +0000 (17:22 +0100)] 
[efi] Expose unused USB devices via EFI_USB_IO_PROTOCOL

Allow the UEFI platform firmware to provide drivers for unrecognised
devices, by exposing our own implementation of EFI_USB_IO_PROTOCOL.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[usb] Allow for wildcard USB class IDs
Michael Brown [Mon, 14 Sep 2015 16:52:25 +0000 (17:52 +0100)] 
[usb] Allow for wildcard USB class IDs

Make the class ID a property of the USB driver (rather than a property
of the USB device ID), and allow USB drivers to specify a wildcard ID
for any of the three component IDs (class, subclass, or protocol).

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[usb] Select preferred USB device configuration based on driver score
Michael Brown [Mon, 14 Sep 2015 15:53:05 +0000 (16:53 +0100)] 
[usb] Select preferred USB device configuration based on driver score

Generate a score for each possible USB device configuration based on
the available driver support, and select the configuration with the
highest score.  This will allow us to prefer ECM over RNDIS (for
devices which support both) and will allow us to meaningfully select a
configuration even when we have drivers available for all functions
(e.g. when exposing unused functions via EFI_USB_IO_PROTOCOL).

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[efi] Include a copy of the device path within struct efi_device
Michael Brown [Thu, 10 Sep 2015 22:23:14 +0000 (23:23 +0100)] 
[efi] Include a copy of the device path within struct efi_device

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[efi] Provide efi_devpath_len()
Michael Brown [Thu, 10 Sep 2015 22:22:43 +0000 (23:22 +0100)] 
[efi] Provide efi_devpath_len()

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[xhci] Support arbitrarily large transfers
Michael Brown [Sun, 13 Sep 2015 11:31:18 +0000 (12:31 +0100)] 
[xhci] Support arbitrarily large transfers

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[ehci] Support arbitrarily large transfers
Michael Brown [Sun, 13 Sep 2015 10:48:14 +0000 (11:48 +0100)] 
[ehci] Support arbitrarily large transfers

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[ehci] Do not treat zero-length NULL pointers as unreachable
Michael Brown [Thu, 10 Sep 2015 23:19:16 +0000 (00:19 +0100)] 
[ehci] Do not treat zero-length NULL pointers as unreachable

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[usb] Generalise zero-length packet generation logic
Michael Brown [Sat, 12 Sep 2015 23:49:56 +0000 (00:49 +0100)] 
[usb] Generalise zero-length packet generation logic

The decision on whether or not a zero-length packet needs to be
transmitted is independent of the host controller and belongs in the
USB core.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[tcpip] Avoid generating positive zero for transmitted UDP checksums
Michael Brown [Thu, 10 Sep 2015 12:19:16 +0000 (13:19 +0100)] 
[tcpip] Avoid generating positive zero for transmitted UDP checksums

TCP/IP checksum fields are one's complement values and therefore have
two possible representations of zero: positive zero (0x0000) and
negative zero (0xffff).

In RFC768, UDP over IPv4 exploits this redundancy to repurpose the
positive representation of zero (0x0000) to mean "no checksum
calculated"; checksums are optional for UDP over IPv4.

In RFC2460, checksums are made mandatory for UDP over IPv4.  The
wording of the RFC is such that the UDP header is mandated to use only
the negative representation of zero (0xffff), rather than simply
requiring the checksum to be correct but allowing for either
representation of zero to be used.

In RFC1071, an example algorithm is given for calculating the TCP/IP
checksum.  This algorithm happens to produce only the positive
representation of zero (0x0000); this is an artifact of the way that
unsigned arithmetic is used to calculate a signed one's complement
sum (and its final negation).

A common misconception has developed (exemplified in RFC1624) that
this artifact is part of the specification.  Many people have assumed
that the checksum field should never contain the negative
representation of zero (0xffff).

A sensible receiver will calculate the checksum over the whole packet
and verify that the result is zero (in whichever representation of
zero happens to be generated by the receiver's algorithm).  Such a
receiver will not care which representation of zero happens to be used
in the checksum field.

However, there are receivers in existence which will verify the
received checksum the hard way: by calculating the checksum over the
remainder of the packet and comparing the result against the checksum
field.  If the representation of zero used by the receiver's algorithm
does not match the representation of zero used by the transmitter (and
so placed in the checksum field), and if the receiver does not
explicitly allow for both representations to compare as equal, then
the receiver may reject packets with a valid checksum.

For UDP, the combined RFCs effectively mandate that we should generate
only the negative representation of zero in the checksum field.

For IP, TCP and ICMP, the RFCs do not mandate which representation of
zero should be used, but the misconceptions which have grown up around
RFC1071 and RFC1624 suggest that it would be least surprising to
generate only the positive representation of zero in the checksum
field.

Fix by ensuring that all of our checksum algorithms generate only the
positive representation of zero, and explicitly inverting this in the
case of transmitted UDP packets.

Reported-by: Wissam Shoukair <wissams@mellanox.com>
Tested-by: Wissam Shoukair <wissams@mellanox.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[efi] Add a USB host controller driver based on EFI_USB_IO_PROTOCOL
Michael Brown [Fri, 4 Sep 2015 01:26:01 +0000 (02:26 +0100)] 
[efi] Add a USB host controller driver based on EFI_USB_IO_PROTOCOL

Allow iPXE to coexist with other USB device drivers, by attaching to
the EFI_USB_IO_PROTOCOL instances provided by the UEFI platform
firmware.

The EFI_USB_IO_PROTOCOL is an unsurprisingly badly designed
abstraction of a USB device.  The poor design choices intrinsic in the
UEFI specification prevent efficient operation as a network device,
with the result that devices operated using the EFI_USB_IO_PROTOCOL
operate approximately two orders of magnitude slower than devices
operated using our native EHCI or xHCI host controller drivers.

Since the performance is so abysmally slow, and since the underlying
problems are due to fundamental architectural mistakes in the UEFI
specification, support for the EFI_USB_IO_PROTOCOL host controller
driver is left as disabled by default.  Users are advised to use the
native iPXE host controller drivers instead.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[efi] Allow efidev_parent() to traverse multiple device generations
Michael Brown [Mon, 7 Sep 2015 00:25:41 +0000 (01:25 +0100)] 
[efi] Allow efidev_parent() to traverse multiple device generations

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[efi] Add USB headers and GUID definitions
Michael Brown [Thu, 3 Sep 2015 15:00:28 +0000 (16:00 +0100)] 
[efi] Add USB headers and GUID definitions

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[usb] Add function to device's function list before attempting probe
Michael Brown [Sat, 5 Sep 2015 17:29:53 +0000 (18:29 +0100)] 
[usb] Add function to device's function list before attempting probe

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[usb] Expose usb_find_driver()
Michael Brown [Sat, 5 Sep 2015 14:53:56 +0000 (15:53 +0100)] 
[usb] Expose usb_find_driver()

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[efi] Implement the EFI_PXE_BASE_CODE_PROTOCOL
Michael Brown [Tue, 1 Sep 2015 20:23:34 +0000 (21:23 +0100)] 
[efi] Implement the EFI_PXE_BASE_CODE_PROTOCOL

Many UEFI NBPs expect to find an EFI_PXE_BASE_CODE_PROTOCOL installed
in addition to the EFI_SIMPLE_NETWORK_PROTOCOL.  Most NBPs use the
EFI_PXE_BASE_CODE_PROTOCOL only to retrieve the cached DHCP packets.

This implementation has been tested with grub.efi, shim.efi,
syslinux.efi, and wdsmgfw.efi.  Some methods (such as Discover() and
Arp()) are not used by any known NBP and so have not (yet) been
implemented.

Usage notes for the tested bootstraps are:

  - grub.efi uses EFI_PXE_BASE_CODE_PROTOCOL only to retrieve the
    cached DHCP packet, and uses no other methods.

  - shim.efi uses EFI_PXE_BASE_CODE_PROTOCOL to retrieve the cached
    DHCP packet and to retrieve the next NBP via the Mtftp() method.
    If shim.efi was downloaded via HTTP (or other non-TFTP protocol)
    then shim.efi will blindly call Mtftp() with an HTTP URI as the
    filename: this allows the next NBP (e.g. grubx64.efi) to also be
    transparently retrieved by HTTP.

    shim.efi can also use the EFI_SIMPLE_FILE_SYSTEM_PROTOCOL to
    retrieve files previously loaded by "imgfetch" or similar commands
    in iPXE.  The current implementation of shim.efi will use the
    EFI_SIMPLE_FILE_SYSTEM_PROTOCOL only if it does not find an
    EFI_PXE_BASE_CODE_PROTOCOL; this patch therefore prevents this
    usage of our EFI_SIMPLE_FILE_SYSTEM_PROTOCOL.  This logic could be
    trivially reversed in shim.efi if needed.

  - syslinux.efi uses EFI_PXE_BASE_CODE_PROTOCOL only to retrieve the
    cached DHCP packet.  Versions 6.03 and earlier have a bug which
    may cause syslinux.efi to attach to the wrong NIC if there are
    multiple NICs in the system (or if the UEFI firmware supports
    IPv6).

  - wdsmgfw.efi (ab)uses EFI_PXE_BASE_CODE_PROTOCOL to retrieve the
    cached DHCP packets, and to send and retrieve UDP packets via the
    UdpWrite() and UdpRead() methods.  (This was presumably done in
    order to minimise the amount of benefit obtainable by switching to
    UEFI, by replicating all of the design mistakes present in the
    original PXE specification.)

The EFI_DOWNGRADE_UX configuration option remains available for now,
until this implementation has received more widespread testing.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[uri] Generalise tftp_uri() to pxe_uri()
Michael Brown [Wed, 26 Aug 2015 21:35:42 +0000 (22:35 +0100)] 
[uri] Generalise tftp_uri() to pxe_uri()

Merge the functionality of parse_next_server_and_filename() and
tftp_uri() into a single pxe_uri(), which takes a server address
(IPv4/IPv6/none) and a filename, and produces a URI using the rule:

 - if the filename is a hierarchical absolute URI (i.e. includes a
   scheme such as "http://" or "tftp://") then use that URI and ignore
   the server address,

 - otherwise, if the server address is recognised (according to
   sa_family) then construct a TFTP URI based on the server address,
   port, and filename

 - otherwise fail.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[pxe] Populate ciaddr in fake PXE Boot Server ACK packet
Michael Brown [Tue, 1 Sep 2015 15:52:27 +0000 (16:52 +0100)] 
[pxe] Populate ciaddr in fake PXE Boot Server ACK packet

We currently do not populate the ciaddr field in the constructed PXE
Boot Server ACK packet.  This causes a WDS server to respond with a
broadcast packet, which is then ignored by wdsmgfw.efi since it does
not match the specified IP address filter.

Fix by populating ciaddr within the constructed PXE Boot Server ACK
packet.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 years ago[efi] Do not return EFI_NOT_READY from our ReceiveFilters() method
Michael Brown [Tue, 1 Sep 2015 18:20:28 +0000 (19:20 +0100)] 
[efi] Do not return EFI_NOT_READY from our ReceiveFilters() method

Our SNP ReceiveFilters() method is a no-op, since we always (if
possible) use promiscuous mode for all network cards.  The method
currently returns EFI_NOT_READY if the SNP interfaces are claimed for
use by iPXE, as with all other SNP methods.

The WDS bootstrap wdsmgfw.efi attempts to use both the PXE Base Code
protocol and the Simple Network Protocol simultaneously.  This is
fundamentally broken, since use of the PXE Base Code protocol requires
us to disable the use of SNP (by claiming the interfaces for use by
iPXE), otherwise MnpDxe swallows all of the received packets before
our PXE Base Code's UdpRead() method is able to return them.

The root cause of this problem is that, as with BIOS PXE, the network
booting portions of the UEFI specification are less of a specification
and more of an application note sketchily describing how the original
hacked-together Intel implementation works.  No sane design would ever
have included the UdpWrite() and UdpRead() methods.

Work around these fundamental conceptual flaws by unconditionally
returning success from efi_snp_receive_filters().

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