Remove the now-unused implementation of ECDHE that requires an
underlying elliptic curve abstraction, since we now use a standalone
key exchange algorithm abstraction instead.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
X25519 is defined as a key exchange algorithm, not as a generic
elliptic curve. We have never supported arbitrary point addition on
the underlying curve, and we have never supported pure multiplication
(without the clamping defined in RFC7748, which modifies the scalar
multiple).
Now that we have an abstraction for key exchange that exists
independently of the elliptic curve abstraction, there are no further
consumers of the elliptic curve abstraction for X25519. Remove this
redundant abstraction to simplify the codebase.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Remove any knowledge of elliptic curve point formats from the TLS
layer and use the generic key exchange algorithm abstraction instead.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Provide the Weierstrass curves P-256 and P-384 as generic key exchange
algorithms (independent of the elliptic curve abstraction). Only the
"uncompressed" point format is supported, and the knowledge of the
format byte is internalised within the key exchange algorithm so that
the caller can just treat all values as opaque byte strings.
Add a random selection of the NIST "ECC CDH Primitive (SP800-56A
Section 5.7.1.2)" key exchange test vectors.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Provide X25519 as a generic key exchange algorithm (independent of the
elliptic curve abstraction).
The existing RFC7748 test vectors are not structured in a way amenable
to treatment as a generic key exchange algorithm. Retain these test
vectors unaltered for completeness, add the single "Alice/Bob" key
exchange example presented in RFC7748, and add a selection of test
vectors from Project Wycheproof (including some known edge cases).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
TLS version 1.3 does not use static RSA or parameterized DHE for key
exchange: all key exchange algorithms are identified via a "named
group" enumeration and have predefined group parameters with fixed
input and output sizes.
Add an abstraction of a key exchange algorithm matching this usage
pattern, along with corresponding test support code.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The length calculations in nfs_uri_symlink() omitted space for the
NUL terminator, causing strcpy() to write one byte past the heap
allocation.
Signed-off-by: Theodore Riera <warsang@hotmail.com>
GCC 16 attempts to link against -latomic_asneeded by default, and
expects that this library will be provided by the installed build
toolchain alongside libgcc.
The Fedora cross-gcc packages do not include libatomic, which causes
the build to fail.
We do not require any functions provided by libatomic. Work around
the missing packaged files in Fedora by disabling gcc's implicit
linking via the -fno-link-libatomic build option.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Replace malloc_phys with dma_alloc, free_phys with dma_free, alloc_iob
with alloc_rx_iob, free_iob with free_rx_iob, virt_to_bus with dma or
iob_dma. Replace dma_addr_t with physaddr_t.
Signed-off-by: Joseph Wong <joseph.wong@broadcom.com>
As with most other assembly code in iPXE, LoongArch64 is sufficiently
close to RISC-V that a straightforward transcription of the assembly
language code generally works.
Copy the RISC-V implementation for TCP/IP checksumming, retain the
register names and ABI, and just adjust the syntax to match
LoongArch64 requirements.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Use the tighter provable constraint
carry.2^n + x <= (2^n - 1) + (2^n - 1)
<= 2^n + (2^n - 2)
and so
x + carry <= (2^n - 2) + 1
<= (2^n - 1)
to eliminate some unnecessary folding steps, and hold the folded value
in the most significant bits of the register rather than the least
significant bits so that the final one's complement negation can be
accomplished naturally without requiring an explicit 0xffff constant.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The usage pattern for UEFI Secure Boot on RISC-V 64 and LoongArch64 is
not yet well defined: there is no equivalent on those architectures
for the UEFI shim or the Microsoft signing submission infrastructure.
Include signed binaries for these architectures within the release
artifacts. Users may choose to enrol the iPXE Secure Boot CA
certificate on their own systems in order to use these binaries with
UEFI Secure Boot enabled.
OEMs such as Loongson may choose to include the iPXE Secure Boot CA
certificate within their default enrolled certificate list, or to
issue a cross-signed version of the iPXE Secure Boot CA certificate
(which could then be included within the official iPXE binaries in
future releases).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The current implementation of the optimised string operations appears
to have been ported from the (old) arm64 implementation, and does not
cleanly match the LoongArch64 instruction set.
Replace with code derived from the riscv64 implementation, modified to
use indexed load and store instructions.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Discarding neighbour cache entries for active connections is known to
be extremely disruptive, and is therefore done only as a last resort
when attempting to free up memory for a new allocation attempt.
There is currently no way to discard the deferred packet queue
separately from discarding the complete neighbour cache entry. Under
some conditions (such as a sustained ICMP echo request packet flood
from an IP address that will never complete neighbour resolution),
this can lead to the deferred packet queue growing without limit,
which will eventually lead to complete neighbour cache entries being
discarded.
Split out the logic in neighbour_destroy() for dropping deferred
packets to a separate neighbour_drop() function, and add a separate
cache discarder that will use this to free up memory without requiring
the complete neighbour cache entry to be discarded.
Reported-by: Daniel Kiper <daniel.kiper@oracle.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The existing virtio network driver has been somewhat hacked together
over the past two decades by multiple contributors, and includes a
substantial amount of logic that is almost but not quite duplicated
between the "legacy" and "modern" code paths.
Rip out the existing driver and replace with a completely new driver
written based on the Virtual I/O Device specification document, not
derived from the Linux kernel driver.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Commit 3d43789 ("[lacp] Detect and ignore erroneously looped back LACP
packets") added protection against LACP packet storms that arise when
our own transmitted packets are somehow looped back to the same port,
but does not protect against a situation in which we have two
different ports that are externally bridged to each other.
This situation is unlikely to arise in practice since a properly
configured link partner should not be both sending and forwarding LACP
packets. Triggering this situation essentially requires our two ports
to be connected to a non-LACP-capable switch, while another port on
the same switch is connected to a separate device that is sending out
LACP packets.
Guard against this situation by using the MAC address of the first
network device as the LACP system identifier, thereby allowing the
loopback detection to reject any packets that were sent from any of
our ports.
Since the system identifier is no longer unique between ports, use the
guaranteed-unique network device scope ID as the group key to indicate
that we do not support aggregation.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The RSA-PSS signature scheme is crowbarred somewhat awkwardly into TLS
version 1.2. Certificates with the standard rsaEncryption OID in the
public key may be used with either PKCS#1 or RSA-PSS, which breaks the
straightforward mapping between the OID and the signature algorithm.
Extend the definition of a TLS signature hash algorithm to include a
required OID-identified algorithm in the certificate's public key.
This allows us to define signature schemes such as rsa_pss_rsae_sha256
where the signature scheme uses an algorithm that differs from the
algorithm identified in the certificate's public key.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Add support for the RSA-PSS signature scheme as defined in RFC 8017
and required for TLS version 1.3.
Signature verification is deliberately implemented by first deriving
the salt value and then reconstructing the entire expected signature.
This is arguably inefficient since it involves two invocations of the
mask generation function when only one is required. However, this
implementation approach keeps the code size minimal (since there is no
need to implement separate verification logic), and makes it provably
impossible to accidentally omit a verification step (such as checking
the leading zero bits or the fixed 0x01 or 0xbc bytes). Since
signature verification is not a fast-path operation, the guaranteed
correctness is more valuable than a marginally faster execution.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The RSA-PSS signature scheme has the same basic structure as the
existing PKCS#1 signature scheme, with a difference only in how the
digest value is encoded before being enciphered.
Abstract out the digest encoding from the signature and verification
methods, and add an explicit "pkcs1" to the relevant method names.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Make the public key self-tests fully deterministic by temporarily
overriding the function used to obtain random data for RSA encryption.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Modify bnxt_hwrm_run() to accept a flag indicating whether to abort
immediately upon a command failure. During initialization path,
driver will continue to abort on first error. During teardown,
sequence will continue executing subsequent cleanup commands even if
one fails. This ensures a best-effort cleanup.
Signed-off-by: Joseph Wong <joseph.wong@broadcom.com>
Enhance code readability in the completion queue servicing logic to
use explicit function calls per case statement, rather than falling
through to the next statement. Add debug print in ring allocation
path. Fix typo in PCI ROM entry.
Signed-off-by: Joseph Wong <joseph.wong@broadcom.com>
The regparm function attribute is meaningful only for i386, not for
x86_64, and is reported as a build error by GCC 16.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The regparm function attribute is meaningful only for i386, not for
x86_64, and is reported as a build error by GCC 16.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The EFI device path settings are currently registered as the
"netX.dhcp" settings block, in order that they will be automatically
overridden if a real DHCP configuration takes place. This does not
work as expected in an IPv6-only network, since the IPv6 configurator
will register "netX.ndp" rather than "netX.dhcp".
Fix by registering the EFI device path settings as either "netX.dhcp"
or "netX.ndp" based on the first address family encountered within the
device path.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
RFC 5246 defines the signature_algorithm extension values for TLS
version 1.2 as being tuples of {HashAlgorithm, SignatureAlgorithm}
pairs. RFC 8446 redefines the signature_algorithm extension values
for TLS version 1.3 in a backwards-compatible way as opaque 16-bit
SignatureScheme values, and RFC 8447 updates RFC 5246 to allow these
values to be used with TLS version 1.2.
Redefine our concept of a signature algorithm identifier to remove the
internal structure that no longer exists.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The null crypto algorithms are intended to do nothing: the null digest
algorithm accepts all input and generates a zero-length digest, and
the null cipher algorithm simply copies the input unmodifed to the
output.
The null public-key algorithm currently does nothing successfully.
Unlike the null digest and cipher algorithms, the null public-key
algorithm's methods are never called.
Change the null public-key algorithm to fail all operations, thereby
allowing its methods to be used as stubs by algorithms such as ECDSA
that do not implement all of the possible public-key operations.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The != operator has higher precedence than = in C, so the expressions:
rc = imgacquire ( ..., image ) != 0
are parsed as:
rc = ( imgacquire ( ..., image ) != 0 )
This assigns the boolean result (0 or 1) to rc instead of the actual
return code from imgacquire(). As a result, strerror(rc) reports an
incorrect error message when debugging is enabled.
Add parentheses around each assignment to ensure rc captures the
actual return value, matching the pattern already used in
efi_autoexec_filesystem() within the same file.
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Add support for the HMAC-based Extract-and-Expand Key Derivation
Function (HKDF) as used in TLS version 1.3 and defined in RFC 5869.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Commit 988243c ("[virtio] Add virtio-net 1.0 support") erroneously
placed the code to unmap the device regions before the code to
unregister the network device. In the common case that the network
device is still open at the time that we shut down to boot the OS,
this results in the regions being accessed after having been unmapped.
For 32-bit BIOS or for UEFI with no IOMMU enabled, the iounmap()
operation is a no-op and so the driver still happens to work despite
the ordering bug. For 64-bit BIOS or for UEFI with an IOMMU enabled,
the iounmap() operation is not a no-op, and the driver will trigger a
page fault.
Fix by moving the call to unregister_netdev() to before the code that
unmaps the device regions.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The unused RX I/O buffers are currently freed without being deleted
from the list, with the list head being reinitialised only after all
buffers have been deleted. This triggers assertion failures due to
the list integrity checks when debugging is enabled.
Fix by deleting each buffer individually, so that the list structure
remains valid at all times.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Commit b9d68b9 ("[ethernet] Use standard 1500 byte MTU unless
explicitly overridden") added code to explicitly set the MTU for
virtio-net devices, but only on the legacy probe path.
Make the behaviour consistent by setting the MTU on both legacy and
modern probe paths.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Alibaba Cloud will refuse to use images for some instance types unless
the image is explicitly marked as supporting NVMe disks.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The underlying snapshots are not automatically deleted along with the
image, and there is no flag that can be set to cause them to be
automatically deleted.
Tag the underlying snapshots for deletion before deleting the image,
delete the image, and then delete any such tagged snapshots (including
any that may remain from a previous failed deletion attempt).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Add a workflow to build and import the official iPXE images for
Alibaba Cloud. As with the AWS and Google Cloud imports, treat this
as a workflow that must be triggered manually.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Experimentation suggests Alibaba Cloud API calls are extremely
unreliable, with a failure rate around 1%. It is therefore necessary
to allow for retrying basically every API call.
Some API calls (e.g. DescribeImages or ModifyImageAttribute) are
naturally idempotent and so safe to retry. Some non-idempotent API
calls (e.g. CopyImage) support explicit idempotence tokens. The
remaining API calls may simply fail on a retry, if the original
request happened to succeed but failed to return a response.
We could write convoluted retry logic around the non-idempotent calls,
but this would substantially increase the complexity of the already
unnecessarily complex code. For now, we assume that retrying
non-idempotent requests is probably more likely to fix transient
failures than to cause additional problems.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The CopyImage API call does work, but is unacceptably slow due to rate
limiting. Importing a full set of images to all regions can take
several hours (and is likely to fail at some point due to transient
errors in making API calls).
Resort to a mixture of strategies to get images imported to all
regions:
- For regions with working OSS that are not blocked by Chinese state
censorship laws, upload the image files to an OSS bucket and then
import the images.
- For regions with working OSS that are blocked by Chinese state
censorship laws but that have working FC, use a temporary FC
function to copy the image files from the uncensored OSS buckets
and then import the images. Attempt downloads from a variety of
uncensored buckets, since cross-region OSS traffic tends to
experience a failure rate of around 10% of requests.
- For regions that have working OSS but are blocked by Chinese state
censorship laws and do not have working FC, or for regions that
don't even have working OSS, resort to using CopyImage to copy the
previously imported images from another region. Spread the
imports across as many source regions as possible to minimise the
effect of the CopyImage rate limiting.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Spinning up ECS instances is supported in all ECS regions (unlike
Function Compute), but turns out to be unacceptably unreliable since
Alibaba Cloud has a very irritating tendency to fail to launch ECS
instances for a variety of spurious and unpredictable reasons.
Rewrite the censorship bypass mechanism to use the (extremely slow)
CopyImage API call to copy an imported image from an uncensored region
to a censored region.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Function Compute is unsupported in several Alibaba Cloud regions.
Rewrite the censorship bypass mechanism to access OSS buckets using a
temporary ECS instance instead of a temporary Function Compute
function.
Importing images now requires that the account has been prepared using
the "ali-setup" script, which creates the necessary role, VPCs, and
vSwitches to allow ECS instances to be launched in each region.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown