lp://staging/ipxe

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Related blueprints

6299. By Michael Brown <email address hidden> on 2023-10-06

[libc] Use wall clock time as seed for the (non-cryptographic) RNG

We currently use the number of timer ticks since power-on as a seed
for the non-cryptographic RNG implemented by random(). Since iPXE is
often executed directly after power-on, and since the timer tick
resolution is generally low, this can often result in identical seed
values being used on each cold boot attempt.

As of commit 41f786c ("[settings] Add "unixtime" builtin setting to
expose the current time"), the current wall-clock time is always
available within the default build of iPXE. Use this time instead, to
introduce variability between cold boot attempts on the same host.
(Note that variability between different hosts is obtained by using
the MAC address as an additional seed value.)

This has no effect on the separate DRBG used by cryptographic code.

Suggested-by: Heiko <email address hidden>
Signed-off-by: Michael Brown <email address hidden>

6298. By Michael Brown <email address hidden> on 2023-09-19

[eapol] Send EAPoL-Start packets to trigger EAP authentication

We have no way to force a link-layer restart in iPXE, and therefore no
way to explicitly trigger a restart of EAP authentication. If an iPXE
script has performed some action that requires such a restart
(e.g. registering a device such that the port VLAN assignment will be
changed), then the only means currently available to effect the
restart is to reboot the whole system. If iPXE is taking over a
physical link already used by a preceding bootloader, then even a
reboot may not work.

In the EAP model, the supplicant is a pure responder and never
initiates transmissions. EAPoL extends this to include an EAPoL-Start
packet type that may be sent by the supplicant to (re)trigger EAP.

Add support for sending EAPoL-Start packets at two-second intervals on
links that are open and have reached physical link-up, but for which
EAP has not yet completed. This allows "ifclose ; ifopen" to be used
to restart the EAP process.

Signed-off-by: Michael Brown <email address hidden>

6297. By Michael Brown <email address hidden> on 2023-09-18

[eap] Define a supplicant model for EAP and EAPoL

Extend the EAP model to include a record of whether or not EAP
authentication has completed (successfully or otherwise), and to
provide a method for transmitting EAP responses.

Signed-off-by: Michael Brown <email address hidden>

6296. By Michael Brown <email address hidden> on 2023-09-14

[fcoe] Use driver-private data to hold FCoE port structure

Simplify the FCoE code by using driver-private data to hold the FCoE
port for each network device, instead of using a separate allocation.

Signed-off-by: Michael Brown <email address hidden>

6295. By Michael Brown <email address hidden> on 2023-09-14

[vmware] Use driver-private data to hold GuestInfo settings block

Simplify the per-netdevice GuestInfo settings code by using
driver-private data to hold the settings block, instead of using a
separate allocation.

The settings block (if existent) will be automatically unregistered
when the parent network device settings block is unregistered, and no
longer needs to be separately freed. The guestinfo_net_remove()
function may therefore be omitted completely.

Signed-off-by: Michael Brown <email address hidden>

6294. By Michael Brown <email address hidden> on 2023-09-13

[ipv6] Use driver-private data to hold link-local IPv6 settings block

Simplify the IPv6 link-local settings code by using driver-private
data to hold the settings block, instead of using a separate
allocation.

Signed-off-by: Michael Brown <email address hidden>

6293. By Michael Brown <email address hidden> on 2023-09-13

[lldp] Use driver-private data to hold LLDP settings block

Simplify the LLDP code by using driver-private data to hold the LLDP
settings block, instead of using a separate allocation. This avoids
the need to maintain a list of LLDP settings blocks (since the LLDP
settings block pointer can always be obtained using netdev_priv()) and
obviates several failure paths.

Any recorded LLDP data is now freed when the network device is
unregistered, since there is no longer a dedicated reference counter
for the LLDP settings block. To minimise surprise, we also now
explicitly unregister the settings block. This is not strictly
necessary (since the block will be automatically unregistered when the
parent network device settings block is unregistered), but it
maintains symmetry between lldp_probe() and lldp_remove().

The overall reduction in the size of the LLDP code is around 15%.

Signed-off-by: Michael Brown <email address hidden>

6292. By Michael Brown <email address hidden> on 2023-09-13

[netdevice] Allocate private data for each network upper-layer driver

Allow network upper-layer drivers (such as LLDP, which attaches to
each network device in order to provide a corresponding LLDP settings
block) to specify a size for private data, which will be allocated as
part of the network device structure (as with the existing private
data allocated for the underlying device driver).

This will allow network upper-layer drivers to be simplified by
omitting memory allocation and freeing code. If the upper-layer
driver requires a reference counter (e.g. for interface
initialisation), then it may use the network device's existing
reference counter, since this is now the reference counter for the
containing block of memory.

Signed-off-by: Michael Brown <email address hidden>

6291. By Michael Brown <email address hidden> on 2023-09-13

[netdevice] Remove netdev_priv() helper function

Some network device drivers use the trivial netdev_priv() helper
function while others use the netdev->priv pointer directly.

Standardise on direct use of netdev->priv, in order to free up the
function name netdev_priv() for reuse.

Signed-off-by: Michael Brown <email address hidden>

6290. By Michael Brown <email address hidden> on 2023-09-05

[librm] Use explicit operand size when pushing a label address

We currently use "push $1f" within inline assembly to push the address
of the real-mode code fragment, relying on the assembler to treat this
as "pushl" for 32-bit code or "pushq" for 64-bit code.

As of binutils commit 5cc0077 ("x86: further adjust extend-to-32bit-
address conditions"), first included in binutils-2.41, this implicit
operand size is no longer calculated as expected and 64-bit builds
will fail with

  Error: operand size mismatch for `push'

Fix by adding an explicit operand size to the "push" instruction.

Originally-fixed-by: Justin Cano <email address hidden>
Signed-off-by: Michael Brown <email address hidden>