ipxe.git
24 hours ago[efi] Ensure NUL byte is at lowest address within stack cookie cookie coverity_scan master github/cookie github/coverity_scan github/master
Michael Brown [Thu, 9 Jul 2020 13:20:53 +0000 (14:20 +0100)] 
[efi] Ensure NUL byte is at lowest address within stack cookie

The NUL byte included within the stack cookie to act as a string
terminator should be placed at the lowest byte address within the
stack cookie, in order to avoid potentially including the stack cookie
value within an accidentally unterminated string.

Suggested-by: Pete Beck <pete.beck@ioactive.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
24 hours ago[efi] Distribute available entropy within stack cookie
Michael Brown [Thu, 9 Jul 2020 12:56:50 +0000 (13:56 +0100)] 
[efi] Distribute available entropy within stack cookie

Several of the values used to compute a stack cookie (in the absence
of a viable entropy source) will tend to have either all-zeroes or
all-ones in the higher order bits.  Rotate the values in order to
distribute the (minimal) available entropy more evenly.

Suggested-by: Pete Beck <pete.beck@ioactive.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
24 hours ago[libc] Add bit-rotation functions for unsigned long values
Michael Brown [Thu, 9 Jul 2020 12:51:30 +0000 (13:51 +0100)] 
[libc] Add bit-rotation functions for unsigned long values

Generalise the bit rotation implementations to use a common macro, and
add roll() and rorl() to handle unsigned long values.

Each function will still compile down to a single instruction.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
3 days ago[efi] Avoid setting direction flag on EFI platforms
Michael Brown [Tue, 7 Jul 2020 12:49:17 +0000 (13:49 +0100)] 
[efi] Avoid setting direction flag on EFI platforms

The only remaining use case in iPXE for the CPU direction flag is in
__memcpy_reverse() where it is set to allow the use of "rep movsb" to
perform the memory copy.  This matches the equivalent functionality in
the EDK2 codebase, which has functions such as InternalMemCopyMem that
also temporarily set the direction flag in order to use "rep movsb".

As noted in commit d2fb317 ("[crypto] Avoid temporarily setting
direction flag in bigint_is_geq()"), some UEFI implementations are
known to have buggy interrupt handlers that may reboot the machine if
a timer interrupt happens to occur while the direction flag is set.

Work around these buggy UEFI implementations by using the
(unoptimised) generic_memcpy_reverse() on i386 or x86_64 UEFI
platforms.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
3 days ago[libc] Provide an unoptimised generic_memcpy_reverse()
Michael Brown [Tue, 7 Jul 2020 12:13:28 +0000 (13:13 +0100)] 
[libc] Provide an unoptimised generic_memcpy_reverse()

Signed-off-by: Michael Brown <mcb30@ipxe.org>
3 days ago[crypto] Avoid temporarily setting direction flag in bigint_is_geq()
Michael Brown [Mon, 6 Jul 2020 23:09:40 +0000 (00:09 +0100)] 
[crypto] Avoid temporarily setting direction flag in bigint_is_geq()

The UEFI specification states that the calling convention for IA-32
and x64 includes "Direction flag in EFLAGS is clear".  This
specification covers only the calling convention used at the point of
calling functions annotated with EFIAPI.  The specification explicitly
states that other functions (such as private functions or static
library calls) are not required to follow the UEFI calling
conventions.

The reference EDK2 implementation follows this specification.  In
particular, the EDK2 interrupt handlers will clear the direction flag
before calling any EFIAPI functions, and will restore the direction
flag when returning from the interrupt handler.  Some EDK2 private
library functions (most notably InternalMemCopyMem) may set the
direction flag temporarily in order to make efficient use of CPU
string operations.

The current implementation of iPXE's bigint_is_geq() for i386 and
x86_64 will similarly set the direction flag temporarily in order to
make efficient use of CPU string operations.

On some UEFI implementations (observed with a Getac RX10 tablet), a
timer interrupt that happens to occur while the direction flag is set
will reboot the machine.  This very strongly indicates that the UEFI
timer interrupt handler is failing to clear the direction flag before
performing an affected operation (such as copying a block of memory).

Work around such buggy UEFI implementations by rewriting
bigint_is_geq() to avoid the use of string operations and so obviate
the requirement to temporarily set the direction flag.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
6 days ago[usb] Leave port enabled after a failed device registration
Michael Brown [Sat, 4 Jul 2020 10:52:26 +0000 (11:52 +0100)] 
[usb] Leave port enabled after a failed device registration

A failure in device registration (e.g. due to a device with malformed
descriptors) will currently result in the port being disabled as part
of the error path.  This in turn causes the hardware to detect the
device as newly connected, leading to an endless loop of failed device
registrations.

Fix by leaving the port enabled in the case of a registration failure.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
6 days ago[axge] Reapply USB device configuration when opening network device
Michael Brown [Fri, 3 Jul 2020 19:17:25 +0000 (20:17 +0100)] 
[axge] Reapply USB device configuration when opening network device

When connected to a USB3 port, the AX88179 seems to have an
approximately 50% chance of producing a USB transaction error on each
of its three endpoints after being closed and reopened.  The root
cause is unclear, but rewriting the USB device configuration value
seems to clear whatever internal error state has accumulated.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
7 days ago[xhci] Increase link state settling delay to 100ms
Michael Brown [Fri, 3 Jul 2020 11:52:05 +0000 (12:52 +0100)] 
[xhci] Increase link state settling delay to 100ms

Experimentation shows that the existing 20ms delay is insufficient,
and often results in device detection being deferred until after iPXE
has completed startup.

Fix by increasing the delay to 100ms.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
7 days ago[usb] Avoid unnecessary calls to usb_hub_set_drvdata()
Michael Brown [Fri, 3 Jul 2020 10:29:25 +0000 (11:29 +0100)] 
[usb] Avoid unnecessary calls to usb_hub_set_drvdata()

The driver-private data for root hubs is already set immediately after
allocating the USB bus.  There seems to be no reason to set it again
when opening the root hub.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
7 days ago[xhci] Set link state to RxDetect after disabling USB3 root hub port
Michael Brown [Thu, 2 Jul 2020 21:53:11 +0000 (22:53 +0100)] 
[xhci] Set link state to RxDetect after disabling USB3 root hub port

The "disabled" port states for USB2 and USB3 are not directly
equivalent.  In particular, a disabled USB3 port will not detect new
device connections.  The result is that a USB3 device disconnected
from and reconnected to an xHCI root hub port will end up reconnecting
as a USB2 device.

Fix by setting the link state to RxDetect after disabling the port, as
is already done during initialisation.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
7 days ago[usb] Do not attempt to disable USB3 hub ports
Michael Brown [Thu, 2 Jul 2020 15:48:17 +0000 (16:48 +0100)] 
[usb] Do not attempt to disable USB3 hub ports

The USB3 specification removes PORT_ENABLE from the list of features
that may be cleared via a CLEAR_FEATURE request.  Experimentation
shows that omitting the attempt to clear PORT_ENABLE seems to result
in the correct hotplug behaviour.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 days ago[usb] Add missing usb_recycle() for completed hub interrupt transfers
Michael Brown [Thu, 2 Jul 2020 13:19:02 +0000 (14:19 +0100)] 
[usb] Add missing usb_recycle() for completed hub interrupt transfers

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 days ago[usb] Clear device endpoint halt before resetting host endpoint
Michael Brown [Thu, 2 Jul 2020 01:51:58 +0000 (02:51 +0100)] 
[usb] Clear device endpoint halt before resetting host endpoint

Resetting the host endpoint may immediately restart any pending
transfers for that endpoint.  If the device endpoint halt has not yet
been cleared, then this will probably result in a second failed
transfer.

This second failure may be detected within usb_endpoint_reset() while
waiting for usb_clear_feature() to complete.  The endpoint will
subsequently be removed from the list of halted endpoints, causing the
second failure to be effectively ignored and leaving the host endpoint
in a permanently halted state.

Fix by deferring the host endpoint reset until after the device
endpoint is ready to accept new transfers.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
8 days ago[axge] Handle non-gigabit link speeds
Michael Brown [Wed, 1 Jul 2020 19:40:09 +0000 (20:40 +0100)] 
[axge] Handle non-gigabit link speeds

The ASIX USB NICs are capable of autodetecting the Ethernet link speed
and reporting it via PLSR but will not automatically update the
relevant GM and PS bits in MSR.  The result is that a non-gigabit link
will fail to send or receive any packets.

The interrupt endpoint used to report link state includes the values
of the PHY BMSR and LPA registers.  These are not sufficient to
differentiate between 100Mbps and 1000Mbps, since the LPA_NPAGE bit
does not necessarily indicate that the link partner is advertising
1000Mbps.

Extend axge_check_link() to write the MSR value based on the link
speed read from PLSR, and simplify the interrupt endpoint handler to
merely trigger a call to axge_check_link().

Signed-off-by: Michael Brown <mcb30@ipxe.org>
9 days ago[efi] Raise TPL during driver entry point
Michael Brown [Tue, 30 Jun 2020 15:32:59 +0000 (16:32 +0100)] 
[efi] Raise TPL during driver entry point

As per commit c89a446 ("[efi] Run at TPL_CALLBACK to protect against
UEFI timers") we expect to run at TPL_CALLBACK almost all of the time.
Various code paths rely on this assumption.  Code paths that need to
temporarily lower the TPL (e.g. for entropy gathering) will restore it
to TPL_CALLBACK.

The entropy gathering code will be run during DRBG initialisation,
which happens during the call to startup().  In the case of iPXE
compiled as an EFI application this code will run within the scope of
efi_snp_claim() and so will execute at TPL_CALLBACK as expected.

In the case of iPXE compiled as an EFI driver the code will
incorrectly run at TPL_APPLICATION since there is nothing within the
EFI driver entry point that raises (and restores) the TPL.  The net
effect is that a build that includes the entropy-gathering code
(e.g. a build with HTTPS enabled) will return from the driver entry
point at TPL_CALLBACK, which causes a system lockup.

Fix by raising and restoring the TPL within the EFI driver entry
point.

Debugged-by: Ignat Korchagin <ignat@cloudflare.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
11 days ago[efi] Detect and disable seriously broken EFI_RNG_PROTOCOL implementations
Michael Brown [Sun, 28 Jun 2020 18:24:30 +0000 (19:24 +0100)] 
[efi] Detect and disable seriously broken EFI_RNG_PROTOCOL implementations

The EFI_RNG_PROTOCOL on the Microsoft Surface Go does not generate
random numbers.  Successive calls to GetRNG() without any intervening
I/O operations (such as writing to the console) will produce identical
results.  Successive reboots will produce identical results.

It is unclear what the Microsoft Surface Go is attempting to use as an
entropy source, but it is demonstrably producing zero bits of entropy.

The failure is already detected by the ANS-mandated Repetition Count
Test performed as part of our GetEntropy implementation.  This
currently results in the entropy source being marked as broken, with
the result that iPXE refuses to perform any operations that require a
working entropy source.

We cannot use the existing EFI driver blacklisting mechanism to unload
the broken driver, since the RngDxe driver is integrated into the
DxeCore image.

Work around the broken driver by checking for consecutive identical
results returned by EFI_RNG_PROTOCOL and falling back to the original
timer-based entropy source.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
12 days ago[build] Disable position-independent code for ARM64 EFI builds
Michael Brown [Fri, 26 Jun 2020 20:21:31 +0000 (21:21 +0100)] 
[build] Disable position-independent code for ARM64 EFI builds

Some versions of gcc (observed with the cross-compiling gcc 9.3.0 in
Ubuntu 20.04) default to enabling -fPIE.  Experimentation shows that
this results in the emission of R_AARCH64_ADR_GOT_PAGE relocation
records for __stack_chk_guard.  These relocation types are not
supported by elf2efi.c.

Fix by explicitly disabling position-independent code for ARM64 EFI
builds.

Debugged-by: Antony Messerli <antony@mes.ser.li>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
12 days ago[golan] Add explicit type casts for nodnic_queue_pair_type
Michael Brown [Sat, 27 Jun 2020 19:43:32 +0000 (20:43 +0100)] 
[golan] Add explicit type casts for nodnic_queue_pair_type

GCC 10 emits warnings for implicit conversions of enumerated types.

The flexboot_nodnic code defines nodnic_queue_pair_type with values
identical to those of ib_queue_pair_type, and implicitly casts between
them.  Add an explicit cast to fix the warning.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
12 days ago[intel] Avoid spurious compiler warning on GCC 10
Michael Brown [Sat, 27 Jun 2020 19:21:11 +0000 (20:21 +0100)] 
[intel] Avoid spurious compiler warning on GCC 10

GCC 10 produces a spurious warning about an out-of-bounds array access
for the unsized raw dword array in union intelvf_msg.

Avoid the warning by embedding the zero-length array within a struct.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
12 days ago[build] Be explicit about -fcommon compiler directive temp github/temp
Bruce Rogers [Wed, 6 May 2020 21:03:02 +0000 (15:03 -0600)] 
[build] Be explicit about -fcommon compiler directive

gcc10 switched default behavior from -fcommon to -fno-common.  Since
"__shared" relies on the legacy behavior, explicitly specify it.

Signed-off-by: Bruce Rogers <brogers@suse.com>
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
2 weeks ago[ocsp] Accept SHA1 certID responses even if SHA1 is not enabled
Michael Brown [Thu, 25 Jun 2020 12:04:02 +0000 (13:04 +0100)] 
[ocsp] Accept SHA1 certID responses even if SHA1 is not enabled

Various implementation quirks in OCSP servers make it impractical to
use anything other than SHA1 to construct the issuerNameHash and
issuerKeyHash identifiers in the request certID.  For example: both
the OpenCA OCSP responder used by ipxe.org and the Boulder OCSP
responder used by LetsEncrypt will fail if SHA256 is used in the
request certID.

As of commit 6ffe28a ("[ocsp] Accept response certID with missing
hashAlgorithm parameters") we rely on asn1_digest_algorithm() to parse
the algorithm identifier in the response certID.  This will fail if
SHA1 is disabled via config/crypto.h.

Fix by using a direct ASN.1 object comparison on the OID within the
algorithm identifier.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
2 weeks ago[efi] Enable stack protection where possible
Michael Brown [Tue, 23 Jun 2020 22:08:49 +0000 (23:08 +0100)] 
[efi] Enable stack protection where possible

Enable -fstack-protector for EFI builds, where binary size is less
critical than for BIOS builds.

The stack cookie must be constructed immediately on entry, which
prohibits the use of any viable entropy source.  Construct a cookie by
XORing together various mildly random quantities to produce a value
that will at least not be identical on each run.

On detecting a stack corruption, attempt to call Exit() with an
appropriate error.  If that fails, then lock up the machine since
there is no other safe action that can be taken.

The old conditional check for support of -fno-stack-protector is
omitted since this flag dates back to GCC 4.1.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
2 weeks ago[parseopt] Treat empty integer strings in user input as invalid
Michael Brown [Fri, 19 Jun 2020 16:29:46 +0000 (17:29 +0100)] 
[parseopt] Treat empty integer strings in user input as invalid

Signed-off-by: Michael Brown <mcb30@ipxe.org>
2 weeks ago[util] Treat empty integer strings as invalid
Michael Brown [Fri, 19 Jun 2020 15:56:02 +0000 (16:56 +0100)] 
[util] Treat empty integer strings as invalid

Signed-off-by: Michael Brown <mcb30@ipxe.org>
3 weeks ago[snp] Retry initialisation if link is reported as down
Michael Brown [Thu, 18 Jun 2020 23:18:22 +0000 (00:18 +0100)] 
[snp] Retry initialisation if link is reported as down

Some devices (observed with a Getac RX10 tablet and docking station
containing an embedded AX88179 USB NIC) seem to be capable of
detecting link state only during the call to Initialize(), and will
occasionally erroneously report that the link is down for the first
few such calls.

Work around these devices by retrying the Initialize() call multiple
times, terminating early if a link is detected.  The eventual absence
of a link is treated as a non-fatal error, since it is entirely
possible that the link really is down.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
3 weeks ago[crypto] Disable MD5 as an OID-identifiable algorithm by default
Michael Brown [Tue, 16 Jun 2020 22:17:21 +0000 (23:17 +0100)] 
[crypto] Disable MD5 as an OID-identifiable algorithm by default

Disable the use of MD5 as an OID-identifiable algorithm.  Note that
the MD5 algorithm implementation will still be present in the build,
since it is used implicitly by various cryptographic components such
as HTTP digest authentication; this commit removes it only from the
list of OID-identifiable algorithms.

It would be appropriate to similarly disable the use of SHA-1 by
default, but doing so would break the use of OCSP since several OCSP
responders (including the current version of openca-ocspd) are not
capable of interpreting the hashAlgorithm field and so will fail if
the client uses any algorithm other than the configured default.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
3 weeks ago[crypto] Ensure that test code drags in required ASN.1 object identifiers
Michael Brown [Tue, 16 Jun 2020 22:40:58 +0000 (23:40 +0100)] 
[crypto] Ensure that test code drags in required ASN.1 object identifiers

Signed-off-by: Michael Brown <mcb30@ipxe.org>
3 weeks ago[crypto] Allow algorithms to be included without being OID-identifiable
Michael Brown [Tue, 16 Jun 2020 16:14:54 +0000 (17:14 +0100)] 
[crypto] Allow algorithms to be included without being OID-identifiable

There are many ways in which the object for a cryptographic algorithm
may be included, even if not explicitly enabled in config/crypto.h.
For example: the MD5 algorithm is required by TLSv1.1 or earlier, by
iSCSI CHAP authentication, by HTTP digest authentication, and by NTLM
authentication.

In the current implementation, inclusion of an algorithm for any
reason will result in the algorithm's ASN.1 object identifier being
included in the "asn1_algorithms" table, which consequently allows the
algorithm to be used for any ASN1-identified purpose.  For example: if
the MD5 algorithm is included in order to support HTTP digest
authentication, then iPXE would accept a (validly signed) TLS
certificate using an MD5 digest.

Split the ASN.1 object identifiers into separate files that are
required only if explicitly enabled in config/crypto.h.  This allows
an algorithm to be omitted from the "asn1_algorithms" table even if
the algorithm implementation is dragged in for some other purpose.

The end result is that only the algorithms that are explicitly enabled
in config/crypto.h can be used for ASN1-identified purposes such as
signature verification.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
3 weeks ago[tls] Default to supporting only TLSv1.1 or above
Michael Brown [Tue, 16 Jun 2020 12:14:12 +0000 (13:14 +0100)] 
[tls] Default to supporting only TLSv1.1 or above

Signed-off-by: Michael Brown <mcb30@ipxe.org>
3 weeks ago[tls] Allow a minimum TLS protocol version to be specified
Michael Brown [Fri, 12 Jun 2020 20:40:33 +0000 (21:40 +0100)] 
[tls] Allow a minimum TLS protocol version to be specified

The supported ciphers and digest algorithms may already be specified
via config/crypto.h.  Extend this to allow a minimum TLS protocol
version to be specified.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
4 weeks ago[efi] Attempt to connect our driver directly if ConnectController fails
Michael Brown [Wed, 10 Jun 2020 21:52:11 +0000 (22:52 +0100)] 
[efi] Attempt to connect our driver directly if ConnectController fails

Some platforms (observed with an AMI BIOS on an Apollo Lake system)
will spuriously fail the call to ConnectController() when the UEFI
network stack is disabled.  This appears to be a BIOS bug that also
affects attempts to connect any non-iPXE driver to the NIC controller
handle via the UEFI shell "connect" utility.

Work around this BIOS bug by falling back to calling our
efi_driver_start() directly if the call to ConnectController() fails.
This bypasses any BIOS policy in terms of deciding which driver to
connect but still cooperates with the UEFI driver model in terms of
handle ownership, since the use of EFI_OPEN_PROTOCOL_BY_DRIVER ensures
that the BIOS is aware of our ownership claim.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 weeks ago[uri] Avoid appearing to access final byte of a potentially empty string
Michael Brown [Fri, 5 Jun 2020 09:01:19 +0000 (10:01 +0100)] 
[uri] Avoid appearing to access final byte of a potentially empty string

The URI parsing code for "host[:port]" checks that the final character
is not ']' in order to allow for IPv6 literals.  If the entire
"host[:port]" portion of the URL is an empty string, then this will
access the preceding character.  This does not result in accessing
invalid memory (since the string is guaranteed by construction to
always have a preceding character) and does not result in incorrect
behaviour (since if the string is empty then strrchr() is guaranteed
to return NULL), but it does make the code confusing to read.

Fix by inverting the order of the two tests.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 weeks ago[efi] Work around UEFI specification bug in LoadImage for SAN boot
Michael Brown [Fri, 5 Jun 2020 08:40:36 +0000 (09:40 +0100)] 
[efi] Work around UEFI specification bug in LoadImage for SAN boot

As described in the previous commit, work around a UEFI specification
bug that necessitates calling UnloadImage if the return value from
LoadImage is EFI_SECURITY_VIOLATION.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 weeks ago[efi] Work around UEFI specification bug in LoadImage
Michael Brown [Thu, 4 Jun 2020 21:24:21 +0000 (22:24 +0100)] 
[efi] Work around UEFI specification bug in LoadImage

iPXE currently assumes that any error returned from LoadImage()
indicates that the image was not loaded.  This assumption was correct
at the time the code was written and remained correct for UEFI
specifications up to and including version 2.1.

In version 2.3, the UEFI specification broke API and ABI compatibility
by defining that a return value of EFI_SECURITY_VIOLATION would now
indicate that the image had been loaded and a valid image handle had
been created, but that the image should not be started.

The wording in version 2.2 is ambiguous, and does not define whether
or not a return value of EFI_SECURITY_VIOLATION indicates that a valid
image handle has been created.

Attempt to work around all of these incompatible and partially
undefined APIs by calling UnloadImage if we get a return value of
EFI_SECURITY_VIOLATION.  Minimise the risk of passing an uninitialised
pointer to UnloadImage by setting ImageHandle to NULL prior to calling
LoadImage.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
5 weeks ago[png] Fix potential integer overflow
Michael Brown [Thu, 4 Jun 2020 21:09:11 +0000 (22:09 +0100)] 
[png] Fix potential integer overflow

Signed-off-by: Michael Brown <mcb30@ipxe.org>
2 months ago[bnxt] Add driver support for Broadcom NetXtreme-E Adapters
Joseph Wong [Tue, 30 Apr 2019 21:17:04 +0000 (14:17 -0700)] 
[bnxt] Add driver support for Broadcom NetXtreme-E Adapters

Signed-off-by: Joseph Wong <joseph.wong@broadcom.com>
3 months ago[efi] Disambiguate errors returned by ConnectController
Michael Brown [Sat, 14 Mar 2020 09:49:49 +0000 (09:49 +0000)] 
[efi] Disambiguate errors returned by ConnectController

Signed-off-by: Michael Brown <mcb30@ipxe.org>
4 months ago[int13con] Create log partition only when CONSOLE_INT13 is enabled
Michael Brown [Sun, 1 Mar 2020 12:56:28 +0000 (12:56 +0000)] 
[int13con] Create log partition only when CONSOLE_INT13 is enabled

Reduce the size of the USB disk image in the common case that
CONSOLE_INT13 is not enabled.

Originally-implemented-by: Romain Guyard <romain.guyard@mujin.co.jp>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
4 months ago[bios] Define macros for constructing partition table entries
Michael Brown [Sun, 1 Mar 2020 11:58:47 +0000 (11:58 +0000)] 
[bios] Define macros for constructing partition table entries

Signed-off-by: Michael Brown <mcb30@ipxe.org>
4 months ago[iscsi] Eliminate variable-length stack allocation in URI parsing
Michael Brown [Sun, 16 Feb 2020 23:46:33 +0000 (23:46 +0000)] 
[iscsi] Eliminate variable-length stack allocation in URI parsing

Signed-off-by: Michael Brown <mcb30@ipxe.org>
4 months ago[iscsi] Eliminate variable-length stack allocations in CHAP handlers
Michael Brown [Sun, 16 Feb 2020 23:19:03 +0000 (23:19 +0000)] 
[iscsi] Eliminate variable-length stack allocations in CHAP handlers

Signed-off-by: Michael Brown <mcb30@ipxe.org>
4 months ago[settings] Eliminate variable-length stack allocation
Michael Brown [Sun, 16 Feb 2020 22:30:38 +0000 (22:30 +0000)] 
[settings] Eliminate variable-length stack allocation

Signed-off-by: Michael Brown <mcb30@ipxe.org>
4 months ago[slam] Allow for the possibility of IPv6 multicast addresses
Michael Brown [Sun, 16 Feb 2020 22:02:25 +0000 (22:02 +0000)] 
[slam] Allow for the possibility of IPv6 multicast addresses

Signed-off-by: Michael Brown <mcb30@ipxe.org>
4 months ago[slam] Eliminate variable-length stack allocation
Michael Brown [Sun, 16 Feb 2020 21:55:59 +0000 (21:55 +0000)] 
[slam] Eliminate variable-length stack allocation

Signed-off-by: Michael Brown <mcb30@ipxe.org>
4 months ago[infiniband] Eliminate variable-length stack allocation
Michael Brown [Sun, 16 Feb 2020 21:25:27 +0000 (21:25 +0000)] 
[infiniband] Eliminate variable-length stack allocation

Signed-off-by: Michael Brown <mcb30@ipxe.org>
4 months ago[tftp] Eliminate unnecessary variable-length stack allocation
Michael Brown [Sun, 16 Feb 2020 20:08:20 +0000 (20:08 +0000)] 
[tftp] Eliminate unnecessary variable-length stack allocation

Eliminate an unnecessary variable-length stack allocation and memory
copy by allowing TFTP option processors to modify the option string
in-place.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
6 months ago[travis] Ensure that most recent tag is always available
Michael Brown [Thu, 2 Jan 2020 23:14:03 +0000 (00:14 +0100)] 
[travis] Ensure that most recent tag is always available

Remove clone depth limit, to ensure that the most recent tag (from
which the version should be constructed) is always present.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
6 months ago[build] Construct full version number automatically from git revision v1.20.1
Michael Brown [Thu, 2 Jan 2020 22:43:15 +0000 (23:43 +0100)] 
[build] Construct full version number automatically from git revision

Signed-off-by: Michael Brown <mcb30@ipxe.org>
6 months ago[snp] Set EFI_SIMPLE_NETWORK_RECEIVE_MULTICAST bit as per UEFI spec v20.01
Ignat Korchagin [Fri, 13 Dec 2019 16:17:58 +0000 (16:17 +0000)] 
[snp] Set EFI_SIMPLE_NETWORK_RECEIVE_MULTICAST bit as per UEFI spec

According to UEFI specification 2.8 p 24.1 we must set the
EFI_SIMPLE_NETWORK_RECEIVE_MULTICAST bit in the "Disable" mask, when
"ResetMCastFilter" is TRUE.

Signed-off-by: Ignat Korchagin <ignat@cloudflare.com>
Split-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
6 months ago[snp] Try promiscuous multicast receive filter if the regular one fails
Ignat Korchagin [Fri, 13 Dec 2019 16:17:58 +0000 (16:17 +0000)] 
[snp] Try promiscuous multicast receive filter if the regular one fails

Currently, if the SNP driver for whatever reason fails to enable
receive filters for multicast frames, it falls back to enabling just
unicast and broadcast filters.  This breaks some IPv6 functionality as
the network card does not respond to neighbour solicitation requests.

Some cards refuse to enable EFI_SIMPLE_NETWORK_RECEIVE_MULTICAST, but
do support enabling EFI_SIMPLE_NETWORK_RECEIVE_PROMISCUOUS_MULTICAST,
so try it before falling back to just unicast+broadcast.

Signed-off-by: Ignat Korchagin <ignat@cloudflare.com>
Split-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
6 months ago[peerdist] Allow for the use of a hosted cache server
Michael Brown [Sun, 15 Dec 2019 23:26:02 +0000 (23:26 +0000)] 
[peerdist] Allow for the use of a hosted cache server

Allow a PeerDist hosted cache server to be specified via the
${peerhost} setting, e.g.:

  # Use 192.168.0.1 as hosted cache server
  set peerhost 192.168.0.1

Note that this simply treats the hosted cache server as a permanently
discovered peer for all segments.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
6 months ago[peerdist] Allow PeerDist to be globally enabled or disabled
Michael Brown [Fri, 13 Dec 2019 14:44:22 +0000 (14:44 +0000)] 
[peerdist] Allow PeerDist to be globally enabled or disabled

Allow the use of PeerDist content encoding to be enabled or disabled
via the ${peerdist} setting, e.g.:

  # Disable PeerDist
  set peerdist 0

Signed-off-by: Michael Brown <mcb30@ipxe.org>
9 months ago[lan78xx] Always enable automatic speed and duplex detection
Michael Brown [Sun, 29 Sep 2019 19:59:22 +0000 (20:59 +0100)] 
[lan78xx] Always enable automatic speed and duplex detection

On devices with no EEPROM or OTP, the MAC_CR register defaults to not
using automatic link speed detection, with the result that no packets
are successfully sent or received.

Fix by always enabling automatic speed and duplex detection, since
iPXE provides no mechanism for manual configuration of either link
speed or duplex.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
9 months ago[efi] Do not attempt EFI_USB_IO_PROTOCOL transfers during shutdown
Michael Brown [Sun, 15 Sep 2019 09:40:23 +0000 (10:40 +0100)] 
[efi] Do not attempt EFI_USB_IO_PROTOCOL transfers during shutdown

On at least some platforms (observed with a Raspberry Pi), any attempt
to perform USB transfers via EFI_USB_IO_PROTOCOL during EFI shutdown
will lock up the system.  This is quite probably due to the already
documented failure of all EFI timers when ExitBootServices() is
called: see e.g. commit 5cf5ffea2 "[efi] Work around temporal anomaly
encountered during ExitBootServices()".

Work around this problem by refusing to poll endpoints if shutdown is
in progress, and by immediately failing any attempts to enqueue new
transfers.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
9 months ago[efi] Report failed control transfers as expected by the USB core
Michael Brown [Sun, 15 Sep 2019 09:25:46 +0000 (10:25 +0100)] 
[efi] Report failed control transfers as expected by the USB core

The USB core reuses the I/O buffer space occupied by the USB setup
packet to hold the completion status for message transfers, assuming
that the message() method will always strip the setup packet before
returning.  This assumption is correct for all of the hardware
controller drivers (XHCI, EHCI, and UHCI), since these drivers are
able to enqueue the transfer as a separate action from waiting for the
transfer to complete.

The EFI_USB_IO_PROTOCOL does not allow us to separate actions in this
way: there is only a single blocking method that both enqueues and
waits for completion.  Our usbio driver therefore currently defers
stripping the setup packet until the control endpoint is polled.

This causes a bug if a message transfer is enqueued but never polled
and is subsequently cancelled, since the cancellation will be reported
with the I/O buffer still containing the setup packet.  This breaks
the assumption that the setup packet has been stripped, and triggers
an assertion failure in usb_control_complete().

Fix by always stripping the setup packet in usbio_endpoint_message(),
and adjusting usbio_control_poll() to match.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
10 months ago[golan] Fix address-of-pointer bug for multicast attach/detach
Michael Brown [Sat, 17 Aug 2019 16:51:18 +0000 (17:51 +0100)] 
[golan] Fix address-of-pointer bug for multicast attach/detach

Signed-off-by: Michael Brown <mcb30@ipxe.org>
10 months ago[ethernet] Avoid false positive Coverity warning
Michael Brown [Sat, 17 Aug 2019 16:30:09 +0000 (17:30 +0100)] 
[ethernet] Avoid false positive Coverity warning

Signed-off-by: Michael Brown <mcb30@ipxe.org>
10 months ago[coverity] Override assumptions about wcrtomb() and hmac_init()
Michael Brown [Sat, 17 Aug 2019 16:18:54 +0000 (17:18 +0100)] 
[coverity] Override assumptions about wcrtomb() and hmac_init()

Newer versions of Coverity use built-in models for wcrtomb() and
hmac_init() that are capable of returning errors, and reports defects
due to code failing to check for these errors.  The actual iPXE
implementations are simpler than Coverity's models and can never
return errors, so these defects are false positives.

Fix by overriding Coverity's built-in models for these functions.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
10 months ago[crypto] Profile the various stages of modular multiplication
Michael Brown [Sat, 17 Aug 2019 00:24:04 +0000 (01:24 +0100)] 
[crypto] Profile the various stages of modular multiplication

Signed-off-by: Michael Brown <mcb30@ipxe.org>
10 months ago[crypto] Drag in configured digestInfo prefixes for any use of RSA
Michael Brown [Sat, 17 Aug 2019 00:18:34 +0000 (01:18 +0100)] 
[crypto] Drag in configured digestInfo prefixes for any use of RSA

Ensure that the configured RSA digestInfo prefixes are included in any
build that includes rsa.o (rather than relying on x509.o or tls.o also
being present in the final binary).

This allows the RSA self-tests to be run in isolation.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
10 months ago[tls] Add missing call to tls_tx_resume() when restarting negotiation
Michael Brown [Fri, 16 Aug 2019 21:40:19 +0000 (22:40 +0100)] 
[tls] Add missing call to tls_tx_resume() when restarting negotiation

The restart of negotiation triggered by a HelloRequest currently does
not call tls_tx_resume() and so may end up leaving the connection in
an idle state in which the pending ClientHello is never sent.

Fix by calling tls_tx_resume() as part of tls_restart(), since the
call to tls_tx_resume() logically belongs alongside the code that sets
bits in tls->tx_pending.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
10 months ago[peerdist] Limit number of concurrent raw block downloads
Michael Brown [Fri, 16 Aug 2019 20:42:49 +0000 (21:42 +0100)] 
[peerdist] Limit number of concurrent raw block downloads

Raw block downloads are expensive if the origin server uses HTTPS,
since each concurrent download will require local TLS resources
(including potentially large received encrypted data buffers).

Raw block downloads may also be prohibitively slow to initiate when
the origin server is using HTTPS and client certificates.  Origin
servers for PeerDist downloads are likely to be running IIS, which has
a bug that breaks session resumption and requires each connection to
go through the full client certificate verification.

Limit the total number of concurrent raw block downloads to ameliorate
these problems.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
10 months ago[peerdist] Start block download timers from within opener methods
Michael Brown [Fri, 16 Aug 2019 20:23:55 +0000 (21:23 +0100)] 
[peerdist] Start block download timers from within opener methods

Move the responsibility for starting the block download timers from
peerblk_expired() to peerblk_raw_open() and peerblk_retrieval_open(),
in preparation for adding the ability to defer calls to
peerblk_raw_open() via a block download queue.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
10 months ago[process] Add PROC_INIT() for initialising static processes
Michael Brown [Fri, 16 Aug 2019 20:20:05 +0000 (21:20 +0100)] 
[process] Add PROC_INIT() for initialising static processes

Signed-off-by: Michael Brown <mcb30@ipxe.org>
11 months ago[build] Add predefined shortcut for Raspberry Pi builds
Michael Brown [Fri, 2 Aug 2019 10:57:35 +0000 (11:57 +0100)] 
[build] Add predefined shortcut for Raspberry Pi builds

Add a build shortcut "rpi", allowing for e.g.

  make CONFIG=rpi CROSS=aarch64-linux-gnu- bin-arm64-efi/rpi.efi

Signed-off-by: Michael Brown <mcb30@ipxe.org>
11 months ago[build] Move predefined all-drivers build shortcut to Makefile
Michael Brown [Fri, 2 Aug 2019 10:00:43 +0000 (11:00 +0100)] 
[build] Move predefined all-drivers build shortcut to Makefile

The (very approximate) split between Makefile.housekeeping and
Makefile is that the former provides mechanism and the latter provides
policy.

Provide a section within Makefile as a home for predefined build
shortcuts such as the existing all-drivers build.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
11 months ago[build] Do not apply WORKAROUND_CFLAGS for host compiler
Michael Brown [Mon, 22 Jul 2019 13:51:28 +0000 (14:51 +0100)] 
[build] Do not apply WORKAROUND_CFLAGS for host compiler

The WORKAROUND_CFLAGS list is constructed based on running tests on
the target compiler, and the results may not be valid for the host
compiler.

The only relevant workaround required for the host compiler is
-Wno-stringop-truncation, which is needed to avoid a spurious compiler
warning for a totally correct usage of strncpy() in util/elf2efi.c.

Duplicating the workaround tests for the host compiler is messy, as is
conditionally applying __attribute__((nonstring)).  Fix instead by
disapplying WORKAROUND_CFLAGS for the host compiler, and using
memcpy() with an explicitly calculated length instead of strncpy() in
util/elf2efi.c.

Reported-by: Ignat Korchagin <ignat@cloudflare.com>
Reported-by: Christopher Clark <christopher.w.clark@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
11 months ago[build] Workaround compilation error with gcc 9.1
Valentine Barshak [Mon, 22 Jul 2019 09:47:50 +0000 (10:47 +0100)] 
[build] Workaround compilation error with gcc 9.1

Compiling with gcc 9.1 generates lots of "taking address of packed
member of ... may result in an unaligned pointer value" warnings.

Some of these warnings are genuine, and indicate correctly that parts
of iPXE currently require the CPU (or runtime environment) to support
unaligned accesses.  For example: the TCP/IP receive data path will
attempt to access 32-bit fields that may not be aligned to a 32-bit
boundary.

Other warnings are either spurious (such as when the pointer is to a
variable-length byte array, which can have no alignment requirement
anyway) or unhelpful (such as when the pointer is used solely to
provide a debug colour value for the DBGC() macro).

There appears to be no easy way to silence the spurious warnings.
Since the ability to perform unaligned accesses is already a
requirement for iPXE, work around the problem by silencing this class
of warnings.

Signed-off-by: Valentine Barshak <gvaxon@gmail.com>
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
11 months ago[build] Fix "'%s' directive argument is null" error
Valentine Barshak [Sun, 9 Jun 2019 10:30:11 +0000 (13:30 +0300)] 
[build] Fix "'%s' directive argument is null" error

Use '%p' directive, and print handle's address if the address is null
and the handle doesn't have a name.  This fixes the following
compilation error:

  interface/efi/efi_debug.c:334:3: error: '%s' directive
  argument is null [-Werror=format-overflow=]

Signed-off-by: Valentine Barshak <gvaxon@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
11 months ago[smscusb] Fetch MAC from device tree for Raspberry Pi Model B+
Michael Brown [Fri, 19 Jul 2019 18:15:33 +0000 (19:15 +0100)] 
[smscusb] Fetch MAC from device tree for Raspberry Pi Model B+

Signed-off-by: Michael Brown <mcb30@ipxe.org>
11 months ago[build] Add named configuration for Raspberry Pi
Michael Brown [Fri, 19 Jul 2019 16:45:22 +0000 (17:45 +0100)] 
[build] Add named configuration for Raspberry Pi

Signed-off-by: Michael Brown <mcb30@ipxe.org>
11 months ago[smsc95xx] Fetch MAC from device tree for Raspberry Pi
Michael Brown [Fri, 19 Jul 2019 16:43:39 +0000 (17:43 +0100)] 
[smsc95xx] Fetch MAC from device tree for Raspberry Pi

Signed-off-by: Michael Brown <mcb30@ipxe.org>
11 months ago[efi] Register a device tree if provided by the platform firmware
Michael Brown [Fri, 19 Jul 2019 16:42:12 +0000 (17:42 +0100)] 
[efi] Register a device tree if provided by the platform firmware

Signed-off-by: Michael Brown <mcb30@ipxe.org>
11 months ago[fdt] Add ability to parse a MAC address from a flattened device tree
Michael Brown [Fri, 19 Jul 2019 16:35:39 +0000 (17:35 +0100)] 
[fdt] Add ability to parse a MAC address from a flattened device tree

The Raspberry Pi NIC has no EEPROM to hold the MAC address.  The
platform firmware (e.g. UEFI or U-Boot) will typically obtain the MAC
address from the VideoCore firmware and add it to the device tree,
which is then made available to subsequent programs such as iPXE or
the Linux kernel.

Add the ability to parse a flattened device tree and to extract the
MAC address.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
11 months ago[efi] Return only registered EFI devices from efidev_parent()
Michael Brown [Mon, 15 Jul 2019 11:49:47 +0000 (12:49 +0100)] 
[efi] Return only registered EFI devices from efidev_parent()

efidev_parent() currently assumes that any device with BUS_TYPE_EFI is
part of a struct efi_device.  This assumption is not valid, since the
code in efi_device_info() may also create a device with BUS_TYPE_EFI.

Fix by searching through the list of registered EFI devices when
looking for a match, instead of relying on the bus type value.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
11 months ago[arm] Provide dummy implementations for {in,out}[s]{b,w,l}
Michael Brown [Sun, 14 Jul 2019 14:27:01 +0000 (15:27 +0100)] 
[arm] Provide dummy implementations for {in,out}[s]{b,w,l}

It is currently not possible to build the all-drivers iPXE binaries
for ARM, since there is no implementation for inb(), outb(), etc.

There is no common standard for accessing I/O space on ARM platforms,
and there are almost no ARM-compatible peripherals that actually
require I/O space accesses.

Provide dummy implementations that behave as though no device is
present (i.e. ignore writes, return all bits high for reads).  This is
sufficient to allow the all-drivers binaries to link, and should cause
drivers to behave as though no I/O space peripherals are present in
the system.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
11 months ago[build] Fix use of inline assembly on GCC 8 ARM64 builds
Michael Brown [Sun, 14 Jul 2019 13:05:48 +0000 (14:05 +0100)] 
[build] Fix use of inline assembly on GCC 8 ARM64 builds

Commit 1a7746603 ("[build] Fix use of inline assembly on GCC 4.8 ARM64
builds") switched from using "%c0" to "%a0" in order to avoid an
"invalid operand prefix" error on the ARM64 version of GCC 4.8.

It appears that the ARM64 version of GCC 8 now produces an "invalid
address mode" error for the "%a0" form, but is happy with the original
"%c0" form.

Switch back to using the "%c0" form, on the assumption that the
requirement for "%a0" was a temporary aberration.

Originally-fixed-by: John L. Jolly <jjolly@suse.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
14 months ago[golan] Add various new PCI device IDs
Mohammed [Thu, 2 May 2019 10:00:18 +0000 (11:00 +0100)] 
[golan] Add various new PCI device IDs

Signed-off-by: Mohammed <mohammedt@mellanox.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
14 months ago[intelxl] Add driver for Intel 40 Gigabit Ethernet NIC virtual functions
Michael Brown [Wed, 24 Apr 2019 16:15:49 +0000 (17:15 +0100)] 
[intelxl] Add driver for Intel 40 Gigabit Ethernet NIC virtual functions

Signed-off-by: Michael Brown <mcb30@ipxe.org>
14 months ago[intelxl] Choose to operate in non-PXE mode
Michael Brown [Wed, 24 Apr 2019 21:11:14 +0000 (22:11 +0100)] 
[intelxl] Choose to operate in non-PXE mode

The physical function defaults to operating in "PXE mode" after a
power-on reset.  In this mode, receive descriptors are fetched and
written back as single descriptors.  In normal (non-PXE mode)
operation, receive descriptors are fetched and written back only as
complete cachelines unless an interrupt is raised.

There is no way to return to PXE mode from non-PXE mode, and there is
no way for the virtual function driver to operate in PXE mode.

Choose to operate in non-PXE mode.  This requires us to trick the
hardware into believing that it is raising an interrupt, so that it
will not defer writing back receive descriptors until a complete
cacheline (i.e. four packets) have been consumed.  We do so by
configuring the hardware to use MSI-X with a dummy target location in
place of the usual APIC register.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
14 months ago[intelxl] Expose functions required by virtual function driver
Michael Brown [Wed, 24 Apr 2019 13:38:43 +0000 (14:38 +0100)] 
[intelxl] Expose functions required by virtual function driver

Signed-off-by: Michael Brown <mcb30@ipxe.org>
14 months ago[intelxl] Allow for arbitrary placement of interrupt control register
Michael Brown [Wed, 24 Apr 2019 16:11:31 +0000 (17:11 +0100)] 
[intelxl] Allow for arbitrary placement of interrupt control register

Signed-off-by: Michael Brown <mcb30@ipxe.org>
14 months ago[intelxl] Split out ring creation from context programming
Michael Brown [Wed, 24 Apr 2019 15:47:16 +0000 (16:47 +0100)] 
[intelxl] Split out ring creation from context programming

The virtual function driver will use the same transmit and receive
descriptor ring structures, but will not itself construct and program
the ring context.  Split out ring creation and destruction from the
programming of the ring context, to allow code to be shared between
physical and virtual function drivers.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
14 months ago[intelxl] Allow for arbitrary placement of ring tail registers
Michael Brown [Wed, 24 Apr 2019 15:36:24 +0000 (16:36 +0100)] 
[intelxl] Allow for arbitrary placement of ring tail registers

The virtual function transmit and receive ring tail register offsets
do not match those of the physical function.  Allow the tail register
offsets to be specified separately.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
14 months ago[intelxl] Use 32-byte receive descriptors
Michael Brown [Wed, 24 Apr 2019 15:25:47 +0000 (16:25 +0100)] 
[intelxl] Use 32-byte receive descriptors

The physical function driver does not allow the virtual function to
request the use of 16-byte receive descriptors.  Switch to using
32-byte receive descriptors.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
14 months ago[intelxl] Provide a mechanism for handling "send to VF" events
Michael Brown [Wed, 24 Apr 2019 12:09:43 +0000 (13:09 +0100)] 
[intelxl] Provide a mechanism for handling "send to VF" events

Provide a weak stub function for handling the "send to VF" event used
for communications between the physical and virtual function drivers.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
14 months ago[intelxl] Allow admin cookie to hold extended opcode and return code
Michael Brown [Wed, 24 Apr 2019 12:00:12 +0000 (13:00 +0100)] 
[intelxl] Allow admin cookie to hold extended opcode and return code

The "send to PF" and "send to VF" admin queue descriptors (ab)use the
cookie field to hold the extended opcode and return code values.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
14 months ago[intelxl] Allow admin queues to be reinitialised
Michael Brown [Wed, 24 Apr 2019 11:45:37 +0000 (12:45 +0100)] 
[intelxl] Allow admin queues to be reinitialised

A virtual function reset is triggered via an admin queue command and
will reset the admin queue configuration registers.  Allow the admin
queues to be reinitialised after such a reset, without requiring the
overhead (and potential failure paths) of freeing and reallocating the
queues.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
14 months ago[intelxl] Use one admin queue buffer per admin queue descriptor
Michael Brown [Wed, 24 Apr 2019 11:18:12 +0000 (12:18 +0100)] 
[intelxl] Use one admin queue buffer per admin queue descriptor

We currently use a single data buffer shared between all admin queue
descriptors.  This works for the physical function driver since we
have at most one command in progress and only a single event (which
does not use a data buffer).

The communication path between the physical and virtual function
drivers uses the event data buffer, and there is no way to prevent a
solicited event (i.e. a response to a request) from being overwritten
by an unsolicited event (e.g. a link status change).

Provide individual data buffers for each admin event queue descriptor
(and for each admin command queue descriptor, for the sake of
consistency).

Signed-off-by: Michael Brown <mcb30@ipxe.org>
14 months ago[intelxl] Allow for virtual function admin queue register maps
Michael Brown [Fri, 22 Mar 2019 15:04:12 +0000 (15:04 +0000)] 
[intelxl] Allow for virtual function admin queue register maps

The register map for the virtual functions appears to have been
constructed using a random number generator.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
14 months ago[intelxl] Use VLAN tag in receive descriptor if present
Michael Brown [Sat, 27 Apr 2019 19:21:22 +0000 (20:21 +0100)] 
[intelxl] Use VLAN tag in receive descriptor if present

The physical function driver does not allow the virtual function to
request that VLAN tags are left unstripped.  Extract and use the VLAN
tag from the receive descriptor if present.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
14 months ago[vlan] Provide vlan_netdev_rx() and vlan_netdev_rx_err()
Michael Brown [Sat, 27 Apr 2019 19:12:01 +0000 (20:12 +0100)] 
[vlan] Provide vlan_netdev_rx() and vlan_netdev_rx_err()

The Hermon driver uses vlan_find() to identify the appropriate VLAN
device for packets that are received with the VLAN tag already
stripped out by the hardware.  Generalise this capability and expose
it for use by other network card drivers.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
14 months ago[pci] Add support for PCI MSI-X interrupts
Michael Brown [Mon, 22 Apr 2019 13:43:23 +0000 (14:43 +0100)] 
[pci] Add support for PCI MSI-X interrupts

The Intel 40 Gigabit Ethernet virtual functions support only MSI-X
interrupts, and will write back completed interrupt descriptors only
when the device attempts to raise an interrupt (or when a complete
cacheline of receive descriptors has been completed).

We cannot actually use MSI-X interrupts within iPXE, since we never
have ownership of the APIC.  However, an MSI-X interrupt is
fundamentally just a DMA write of a single dword to an arbitrary
address.  We can therefore configure the device to "raise" an
interrupt by writing a meaningless value to an otherwise unused memory
location: this is sufficient to trigger the receive descriptor
writeback logic.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
15 months ago[intel] Add PCI ID for I219-V and -LM 6 to 9
Christian Nilsson [Thu, 14 Feb 2019 21:21:55 +0000 (22:21 +0100)] 
[intel] Add PCI ID for I219-V and -LM 6 to 9

Signed-off-by: Christian Nilsson <nikize@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
16 months ago[ocsp] Accept response certID with missing hashAlgorithm parameters
Michael Brown [Sun, 10 Mar 2019 17:58:56 +0000 (17:58 +0000)] 
[ocsp] Accept response certID with missing hashAlgorithm parameters

One of the design goals of ASN.1 DER is to provide a canonical
serialization of a data structure, thereby allowing for equality of
values to be tested by simply comparing the serialized bytes.

Some OCSP servers will modify the request certID to omit the optional
(and null) "parameters" portion of the hashAlgorithm.  This is
arguably legal but breaks the ability to perform a straightforward
bitwise comparison on the entire certID field between request and
response.

Fix by comparing the OID-identified hashAlgorithm separately from the
remaining certID fields.

Originally-fixed-by: Thilo Fromm <Thilo@kinvolk.io>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
16 months ago[tcp] Display "connecting" status until connection is established
Michael Brown [Sun, 10 Mar 2019 17:29:06 +0000 (17:29 +0000)] 
[tcp] Display "connecting" status until connection is established

Provide increased visibility into the progress of TCP connections by
displaying an explicit "connecting" status message while waiting for
the TCP handshake to complete.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
16 months ago[tls] Display validator messages only while validation is in progress
Michael Brown [Sun, 10 Mar 2019 17:27:33 +0000 (17:27 +0000)] 
[tls] Display validator messages only while validation is in progress

Allow the cipherstream to report progress status messages during
connection establishment.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
16 months ago[tls] Display cross-certificate and OCSP status messages
Michael Brown [Thu, 7 Mar 2019 15:23:19 +0000 (15:23 +0000)] 
[tls] Display cross-certificate and OCSP status messages

TLS connections will almost always create background connections to
perform cross-signed certificate downloads and OCSP checks.  There is
currently no direct visibility into which checks are taking place,
which makes troubleshooting difficult in the absence of either a
packet capture or a debug build.

Use the job progress message buffer to report the current cross-signed
certificate download or OCSP status check, where applicable.

Signed-off-by: Michael Brown <mcb30@ipxe.org>
16 months ago[crypto] Use x509_name() in validator debug messages
Michael Brown [Thu, 7 Mar 2019 13:47:30 +0000 (13:47 +0000)] 
[crypto] Use x509_name() in validator debug messages

Display a human-readable certificate name in validator debug messages
wherever possible.

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