The RTC-based entropy source uses the nanosecond-scale CPU TSC to
measure the time between two 1kHz interrupts generated by the CMOS
RTC. In a physical machine these clocks are driven from independent
crystals, resulting in some observable clock drift. In a virtual
machine, the CMOS RTC is typically emulated using host-OS
constructions such as SIGALRM.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Separate out the list of self-tests from the self-test infrastructure.
This allows tests to be run individually. For example:
make bin/sha1_test.iso
Signed-off-by: Michael Brown <mcb30@ipxe.org>
RSA requires the generation of random non-zero bytes (i.e. a sequence
of random numbers in the range [0x01,0xff]). ANS X9.82 provides
various Approved methods for converting random bits into random
numbers. The simplest such method is the Simple Discard Method.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
ANS X9.82 specifies that the start-up tests shall consist of at least
one full cycle of the continuous tests.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
ANS X9.82 specifies several Approved Sources of Entropy Input (SEI).
One such SEI uses an entropy source as the Source of Entropy Input,
condensing each entropy source output after each GetEntropy call.
This can be implemented relatively cheaply in iPXE and avoids the need
to allocate potentially very large buffers.
(Note that the terms "entropy source" and "Source of Entropy Input"
are not synonyms within the context of ANS X9.82.)
Use the iPXE API mechanism to allow entropy sources to be selected at
compilation time.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Treat an empty (zeroed) DRBG as invalid. This ensures that a DRBG
that has not yet been instantiated (or that has been uninstantiated)
will refuse to attempt to generate random bits.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
NIST provides a set of known-answer tests for the Hash_DRBG algorithm,
which includes known answers for the derivation function Hash_df used
as part of Hash_DRBG. Hash_DRBG is not an Approved algorithm for ANS
X9.82, but the known answers for Hash_df (which is part of ANS X9.82)
can still be used as part of the conformance testing for ANS X9.82.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
ANS X9.82 specifies several Approved derivation functions for use in
distributing entropy throughout a buffer. One such derivation
function is Hash_df, which can be implemented using the existing iPXE
SHA-1 functionality.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
iPXE exposes some extended capabilities via the PXE FILE API to allow
NBPs such as pxelinux to use protocols other than TFTP. Provide an
equivalent interface as a UEFI protocol so that EFI binaries may also
take advantage of iPXE's extended capabilities.
This can be used with a patched version of elilo, for example:
http://comments.gmane.org/gmane.comp.boot-loaders.elilo.general/147
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Practically speaking, it seems the convention is to only have one
packet pending and not rely upon any mechanism to associate returned
txbuf with txqueue.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
This function never did much in this driver anyway, and after commit
b5ed30b2 ("[tg3] Fix compilation on newer gcc versions") it became
apparent that its remaining functionality could be easily moved to
tg3_test_dma().
Signed-off-by: Thomas Miletich <thomas.miletich@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
initrd_init() calls umalloc() to allocate space for the initrd image,
but does so before hide_etherboot() has been called. It is therefore
possible for the initrd to end up overwriting iPXE itself.
Fix by converting initrd_init() from an init_fn to a startup_fn.
Originally-fixed-by: Till Straumann <strauman@slac.stanford.edu>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Replace the old Etherboot tg3 driver with a more up-to-date driver
using the iPXE API.
Signed-off-by: Thomas Miletich <thomas.miletich@gmail.com>
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
ANS X9.82 specifies that an Approved DRBG must consist of an Approved
algorithm wrapped inside an envelope which handles entropy gathering,
prediction resistance, automatic reseeding and other housekeeping
tasks.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Cryptographic random number generation requires an entropy source,
which is used as the input to a Deterministic Random Bit Generator
(DRBG).
iPXE does not currently have a suitable entropy source. Provide a
dummy source to allow the DRBG code to be implemented.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
NIST provides a set of known-answer tests for the HMAC_DRBG algorithm,
which can be used as part of the conformance testing for ANS X9.82.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
ANS X9.82 specifies several Approved algorithms for use in a
Deterministic Random Bit Generator (DRBG). One such algorithm is
HMAC_DRBG, which can be implemented using the existing iPXE SHA-1 and
HMAC functionality. This algorithm provides a maximum security
strength of 128 bits.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The command line may be situated in an area of base memory that will
be overwritten by iPXE's real-mode segments, causing the command line
to be corrupted before it can be used.
Fix by creating a copy of the command line on the prefix stack (below
0x7c00) before installing the real-mode segments.
Reported-by: Dave Hansen <dave@sr71.net>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
PXENV_FILE_EXIT_HOOK is designed to allow ipxelinux.0 to unload both
the iPXE and pxelinux components without affecting the underlying PXE
stack. Unfortunately, it causes unexpected behaviour in other
situations, such as when loading a non-embedded pxelinux.0 via
undionly.kpxe. For example:
PXE ROM -> undionly.kpxe -> pxelinux.0 -> chain.c32 to boot hd0
would cause control to return to iPXE instead of booting from the hard
disk. In some cases, this would result in a harmless but confusing
"No more network devices" message; in other cases stranger things
would happen, such as being returned to the iPXE shell prompt.
The fundamental problem is that when pxelinux detects
PXENV_FILE_EXIT_HOOK, it may attempt to specify an exit hook and then
exit back to iPXE, assuming that iPXE will in turn exit cleanly via
the specified exit hook. This is not a valid assumption in the
general case, since the action of exiting back to iPXE does not
directly cause iPXE to exit itself. (In the specific case of
ipxelinux.0, this will work since the embedded script exits as soon as
pxelinux.0 exits.)
Fix the unexpected behaviour in the non-ipxelinux.0 cases by including
support for PXENV_FILE_EXIT_HOOK only when using a new .kkkpxe format.
The ipxelinux.0 build process should therefore now use undionly.kkkpxe
instead of undionly.kkpxe.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Very nasty things can happen if a NULL network device is used. Check
that pxe_netdev is non-NULL at the applicable entry points, so that
this type of problem gets reported to the caller rather than being
allowed to crash the system.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
It can sometimes be awkward to prevent additional packets from being
received during a loopback test. Allow such additional packets to be
present without terminating the test.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
On at least one PXE stack (Realtek r8169), PXENV_UNDI_INITIALIZE has
been observed to fail intermittently due to a media test failure (PXE
error 0x00000061). Retrying the call to PXENV_UNDI_INITIALIZE
succeeds, and the NIC is then usable.
It is worth noting that this particular Realtek PXE stack is already
known to be unreliable: for example, it repeatably fails its own
boot-time media test after every warm reboot.
Fix by attempting PXENV_UNDI_INITIALIZE multiple times, with a short
delay between each attempt to allow the link to settle.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The PXE specification requires us to request DHCP options 128 to 135
inclusive, although these have no defined purpose.
Suggested-by: Ralf Buettner <rab@bootix.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The RS bit is used to instruct the NIC to update the TX descriptor
status byte. The RPS bit is used to instruct the NIC to defer this
update until after the packet has been transmitted on the wire (rather
than merely read into the transmit FIFO).
The driver currently sets RPS but not RS. Some e1000 models seem to
interpret this as implying that the status byte should be updated;
some don't. On the ones that don't, we never see any TX completions
and so rapidly run out of TX buffers.
Fix by setting the RS bit in the TX descriptor. (We don't care about
when the packet reaches the wire, so don't bother setting the RPS
bit.)
Reported-by: Miroslav Halas <miroslav.halas@bankofamerica.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Some iSCSI targets (observed with stgt) can be configured to reject
connections that do not use header or data digests, and will respond
with "HeaderDigest=Reject" and/or "DataDigest=Reject", while still
allowing the connection to proceed to the full feature phase.
According to a strict reading of RFC3720, we are perfectly safe to
ignore these "Reject" messages: upon such a rejection "the negotiated
key is left at its current value (or default if no value was set)".
Since the default value for both HeaderDigest and DataDigest is
"None", then the only viable conclusion to be drawn is that the value
resulting from "Reject" is still "None".
Unfortunately, stgt doesn't seem to agree with this interpretation of
events, causing us to eventually report an unhelpful "connection timed
out" message to the user when we don't get any response to our first
PDU in full feature phase.
Fix by detecting any rejected parameters and immediately reporting an
error, which at least gives the user some insight as to what the real
problem may be.
Reported-by: Michal Suchanek <hramrach@centrum.cz>
Tested-by: Michal Suchanek <hramrach@centrum.cz>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Commit 9b99d2a ("[build] Avoid generating ROMs with "match-any" vendor
or device IDs") introduced a regression which caused the UNDI PCI
driver to be omitted from the list of all drivers, and thus to be
excluded from the all-drivers build.
Fix by ensuring that the per-driver section of the Makefile is
generated even when there are no ROMs to be built.
Reported-by: Sven Dreyer <sven@dreyer-net.de>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
WinPE has been observed to call PXENV_UNDI_SHUTDOWN but not
PXENV_STOP_UNDI. This means that Hermon hardware is left partially
active (firmware running and one event queue mapped) when WinPE starts
up, which can cause a Blue Screen of Death.
Fix by ensuring that the hardware is left quiescent (with the firmware
stopped) when no interfaces are open.
Reported-by: Itay Gazit <itayg@mellanox.co.il>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown