LZMA provides significantly better compression (by ~15%) than the
current NRV2B algorithm.
We use a raw LZMA stream (aka LZMA1) to avoid the need for code to
parse the LZMA2 block headers. We use parameters {lc=2,lp=0,pb=0} to
reduce the stack space required by the decompressor to acceptable
levels (around 8kB). Using lc=3 or pb=2 would give marginally better
compression, but at the cost of substantially increasing the required
stack space.
The build process now requires the liblzma headers to be present on
the build system, since we do not include a copy of an LZMA compressor
within the iPXE source tree. The decompressor is written from scratch
(based on XZ Embedded) and is entirely self-contained within the
iPXE source.
The branch-call-jump (BCJ) filter used to improve the compressibility
is specific to iPXE. We choose not to use liblzma's built-in BCJ
filter since the algorithm is complex and undocumented. Our BCJ
filter achieves approximately the same results (on typical iPXE
binaries) with a substantially simpler algorithm.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[build] Apply the "-fno-PIE -nopie" workaround only to i386 builds
Hardened versions of gcc default to building position-independent
code, which breaks our i386 build. Our build process therefore
detects such platforms and automatically adds "-fno-PIE -nopie" to the
gcc command line.
On x86_64, we choose to build position-independent code (in order to
reduce the final binary size and, in particular, the number of
relocations required for UEFI binaries). The workaround therefore
breaks the build process for x86_64 binaries on such platforms.
Fix by moving the workaround to the i386-specific portion of the
Makefile.
Reported-by: Jan Kundrát <jkt@kde.org>
Debugged-by: Jan Kundrát <jkt@kde.org>
Debugged-by: Marin Hannache <git@mareo.fr>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
When building hvmloader for Xen tools the iPXE objects are also linked
into the binary. Unfortunately the linker will place them in the
order found in the archive. Since this order is random the resulting
hvmloader binary differs when it was built from identical sources but
on different build hosts. To help with creating a reproducible binary
the elements in blib.a must simply be sorted before passing them to
$(AR).
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Add utility for constructing EFI fat binaries (dual 32/64-bit
binaries, usable only on Apple EFI systems).
This utility is not part of the standard build process. To use it:
make util/efifatbin bin-i386-efi/ipxe.efi bin-x86_64-efi/ipxe.efi
and then
./util/efifatbin bin-*-efi/ipxe.efi fat-ipxe.efi
Requested-by: Brandon Penglase <bpenglase-ipxe@spaceservices.net>
Tested-by: Brandon Penglase <bpenglase-ipxe@spaceservices.net>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[build] Clean up all binary directories on "make [very]clean"
Allow a straightforward "make clean" or "make veryclean" to apply to
all binary directories (using the shell pattern "bin{,-*}").
Individual binary directories can be cleaned using e.g.
make bin clean
make bin-x86_64-efi clean
Reported-by: Robin Smidsrød <robin@smidsrod.no>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[build] Avoid deleting config header files if build is interrupted
With extremely unlucky timing, it is possible to interrupt a build and
cause make to delete config/named.h (and possibly any local
configuration headers).
Mark config/named.h and all local configuration headers as .PRECIOUS
to prevent make from ever deleting them.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The build process has for a long time assumed that every ROM is a PCI
ROM, and will always include the PCI header and PCI-related
functionality (such as checking the PCI BIOS version, including the
PCI bus:dev.fn address within the ROM product name string, etc.).
While real ISA cards are no longer in use, some virtualisation
environments (notably VirtualBox) have support only for ISA ROMs.
This can cause problems: in particular, VirtualBox will call our
initialisation entry point with random garbage in %ax, which we then
treat as the PCI bus:dev.fn address of the autoboot device: this
generally prevents the default boot sequence from using any network
devices.
Create .isarom and .pcirom prefixes which can be used to explicitly
specify the type of ROM to be created. (Note that the .mrom prefix
always implies a PCI ROM, since the .mrom mechanism relies on
reconfiguring PCI BARs.)
Make .rom a magic prefix which will automatically select the
appropriate PCI or ISA ROM prefix for ROMs defined via a PCI_ROM() or
ISA_ROM() macro. To maintain backwards compatibility, we default to
building a PCI ROM for anything which is not directly derived from a
PCI_ROM() or ISA_ROM() macro (e.g. bin/intel.rom).
Add a selection of targets to "make everything" to ensure that the
(relatively obscure) ISA ROM build process is included within the
per-commit QA checks.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[build] Allow for named configurations at build time
Allow named configurations to be specified via the CONFIG=... build
parameter. For headers in config/*.h which support named
configurations, the following files will be included when building
with CONFIG=<name>:
- config/defaults/<platform>.h (e.g. config/defaults/pcbios.h)
- config/<header>.h
- config/<name>/<header>.h (only if the directory config/<name> exists)
- config/local/<header>.h (autocreated if necessary)
- config/local/<name>/<header>.h (autocreated if necessary)
This mechanism allows for predefined named configurations to be
checked in to the source tree, as a directory config/<name> containing
all of the required header files.
The mechanism also allows for users to define multiple local
configurations, by creating header files in the directory
config/local/<name>.
Note that the config/*.h files which are used only to configure
internal iPXE APIs (e.g. config/ioapi.h) cannot be modified via a
named configuration. This avoids rebuilding the entire iPXE codebase
whenever switching to a different named configuration.
Inspired-by: Robin Smidsrød <robin@smidsrod.no>
Tested-by: Robin Smidsrød <robin@smidsrod.no>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[build] Fix erroneous object name in version object
Commit 8290a95 ("[build] Expose build timestamp, build name, and
product names") introduced a regression in the build process which
resulted in broken final binaries which had names based on object
files (e.g. "undionly.kpxe" or "intel.rom") rather than on device IDs
(e.g. "8086100e.mrom").
The underlying problem is the -DOBJECT=<name> macro which is used to
generate the obj_<name> symbols used to select objects required for
the final binary. The macro definition is derived from the initial
portion (up to the first dot) of the object being built. In the case
of e.g. undionly.kpxe.version.o, this gives -DOBJECT=undionly. This
results in undionly.kpxe.version.o claiming to be the "undionly"
object; the real "undionly" object will therefore never get dragged in
to the build.
Fix by renaming $(BIN)/%.version.o to $(BIN)/version.%.o, so that the
object is always built with -DOBJECT=version (as might be expected,
since it is built from core/version.c).
Final binaries which have names based on device IDs (such as
"8086100e.mrom") are not affected by this problem, since the object
name "8086100e" will not conflict with that of the underlying "intel"
object.
This problem was not detected by the per-commit smoke testing
procedure, which happens to use the binary bin/8086100e.mrom.
Reported-by: Christian Hesse <list@eworm.de>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[build] Expose build timestamp, build name, and product names
Expose the build timestamp (measured in seconds since the Epoch) and
the build name (e.g. "rtl8139.rom" or "ipxe.efi"), and provide the
product name and product short name in a single centralised location.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[debug] Allow debug message colours to be customised via DBGCOL=...
When multiple iPXE binaries are running concurrently (e.g. in the case
of undionly.kpxe using an underlying iPXE driver via the UNDI
interface) it would be helpful to be able to visually distinguish
debug messages from each binary.
Allow the range of debug colours used to be customised via the
DBGCOL=... build parameter. For example:
# Restrict to colours 31-33 (red, green, yellow)
make DBGCOL=31-33
# Restrict to colours 34-36 (blue, magenta, cyan)
make DBGCOL=34-36
Signed-off-by: Michael Brown <mcb30@ipxe.org>
If iPXE is used as a git submodule then the ../.git/index file will
not exist, and the build will fail. Fix by checking that the git
index file exists before adding it as a build dependency.
Signed-off-by: Peter Lemenkov <lemenkov@gmail.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Commit 8540300 ("[build] Disable ccache for all relevant build
targets") attempted to generalise the rule for $(BIN)/version.o to
$(BIN)/version.% in order to apply the dependency to all relevant
build targets (debug objects, assembly listings, etc).
This generalisation appears to work for the ccache override
directives, but seems to cause make (at least, GNU make 4.0) to simply
ignore the dependency upon the git index.
Since version.c contains only some string constants, there is unlikely
to be a substantive need for its debug objects, assembly listings,
etc. Restore the previous form of the dependency and accept that
hypothetical builds with e.g. DEBUG=version will not be handled
correctly.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Allow for an explicit debug level of zero, which will enable
assertions and profiling (i.e. anything controlled by NDEBUG) without
generating any debug messages.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[crypto] Generalise X.509 cache to a full certificate store
Expand the concept of the X.509 cache to provide the functionality of
a certificate store. Certificates in the store will be automatically
used to complete certificate chains where applicable.
The certificate store may be prepopulated at build time using the
CERT=... build command line option. For example:
make bin/ipxe.usb CERT=mycert1.crt,mycert2.crt
Certificates within the certificate store are not implicitly trusted;
the trust list is specified using TRUST=... as before. For example:
make bin/ipxe.usb CERT=root.crt TRUST=root.crt
This can be used to embed the full trusted root certificate within the
iPXE binary, which is potentially useful in an HTTPS-only environment
in which there is no HTTP server from which to automatically download
cross-signed certificates or other certificate chain fragments.
This usage of CERT= extends the existing use of CERT= to specify the
client certificate. The client certificate is now identified
automatically by checking for a match against the private key. For
example:
make bin/ipxe.usb CERT=root.crt,client.crt TRUST=root.crt KEY=client.key
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[build] Add dependency of generated files upon Makefile
Ensure that any generated files (such as DER forms of X.509
certificates) are rebuilt if the Makefile changes.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[build] Disable ccache for all relevant build targets
The build process currently attempts to disable ccache for files using
the .incbin directive, but the rule fails to apply to anything beyond
the simple object target. Fix by applying to all relevant build
targets (including debug objects, assembly listings, and so on).
Signed-off-by: Michael Brown <mcb30@ipxe.org>
OpenBSD 5.4 seems to generate dynamically linked binaries by default,
which breaks our build process. Fix by forcing the linker to always
create static binaries.
Reported-by: Jiri B <jirib@devio.us>
Tested-by: Jiri B <jirib@devio.us>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Our use of --gc-sections causes the linker to discard the symbols
defined by FILE_LICENCE(), meaning that the resulting licence
determination is incomplete.
We must use the KEEP() directive in the linker script to force the
linker to not discard the licence symbols. Using KEEP(*(COMMON))
would be undesirable, since there are some symbols in COMMON which we
may wish to discard.
Fix by placing symbols defined by PROVIDE_SYMBOL() (which is used by
FILE_LICENCE()) into a special ".provided" section, which we then mark
with KEEP(). All such symbols are zero-length, so there is no cost in
terms of the final binary size.
Since the symbols are no longer in COMMON, the linker will reject
symbols with the same name coming from multiple objects. We therefore
append the object name to the licence symbol, to ensure that it is
unique.
Reported-by: Marin Hannache <git@mareo.fr>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
When the $(eval) function is available (in GNU make >= 3.80), we can
evaluate many of the dynamically-generated Makefile rules directly.
This avoids generating a few hundred Makefile fragments in the
filesystem, and so speeds up the build process.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Linker table entries must be non-static in order to avoid being
completely optimised away by some versions of gcc. Use -Wno-decl to
prevent sparse from warning about these, since the alternative would
be to litter the code with otherwise unnecessary "extern"
declarations.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
sparse seems to have problems finding compiler.h when specified as
"-include compiler.h"; one possible explanation is that it ignores the
include path. Fix by using "-include include/compiler.h".
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The version number string is currently updated only if version.o
happens to be rebuilt due to changes in its dependencies. Add a
dependency upon the git index, so that the version number is updated
after any checkout.
Signed-off-by: Thomas Miletich <thomas.miletich@gmail.com>
Modified-by: Michael Brown <mcb30@ipxe.org>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Using -fno-dwarf2-cfi-asm is not sufficient to prevent the .eh_frame
section from being generated on newer versions of gcc. Add
-fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables;
this is sufficient to inhibit the .eh_frame section on gcc 4.7.1.
This does not affect the overall binary size, but does fix the numbers
reported by "size" for individual object files.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[crypto] Rename KEY= to PRIVKEY= and "key" to "privkey"
The setting name "key" conflicts with the setting name "key" already
in use by the 802.11 code. Resolve the conflict by renaming the newer
setting to "privkey".
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[build] Use $(xxx_DEPS) for additional dependency information
Some objects (embedded.o, rootcert.o, and clientcert.o) define
additional dependencies on external files, using syntax such as:
$(BIN)/clientcert.o : $(CERT_LIST)
This dependency can be missed when using debug builds. For example,
if DEBUG=clientcert is used, then the relevant object is
$(BIN)/clientcert.dbg1.o rather than $(BIN)/clientcert.o.
Fix by adding dependencies to $(clientcert_DEPS) instead:
clientcert_DEPS += $(CERT_LIST)
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[build] Allow a client certificate to be specified at build time
Allow a client certificate and corresponding private key to be
specified at build time using the syntax
make CERT=/path/to/certificate KEY=/path/to/key
The build process uses openssl to convert the files into DER format,
and includes them within the client certificate store in
clientcert.c. The build process will prompt for the private key
password if applicable.
Note that the private key is stored unencrypted, and so the resulting
iPXE binary (and the temporary files created during the build process)
should be treated as being equivalent to an unencrypted private key
file.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[build] Allow trusted root certificates to be specified at build time
Allow trusted root certificates to be specified at build time using
the syntax
make TRUST=/path/to/certificate1,/path/to/certificate2,...
The build process uses openssl to calculate the SHA-256 fingerprints
of the specified certificates, and adds them to the root certificate
store in rootcert.c. The certificates can be in any format understood
by openssl.
The certificates may be server certificates or (more usefully) CA
certificates.
If no trusted certificates are specified, then the default "iPXE root
CA" certificate will be used.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[build] Avoid using -ffunction-sections on some older versions of gcc
Some older versions of gcc issue a warning if -ffunction-sections is
used in combination with -g (gcc bug #18553). Inhibit
-ffunction-sections when building with such a version of gcc.
Reported-by: zhengwei <zw111_2001@126.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[build] Accept EMBED=... as a synonym for EMBEDDED_IMAGE=...
Make the build command line less cumbersome by accepting
make DEBUG=int13 EMBED=test.ipxe
rather then
make DEBUG=int13 EMBEDDED_IMAGE=test.ipxe
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[build] Run parserom.pl only on potential driver files
PCI_ROM() and ISA_ROM() macros occur only within driver files.
Running parserom.pl on non-driver files is therefore redundant.
Skip running parserom.pl on any files outside a "drivers" directory.
This reduces the time taken to generate build rules and dependencies
after a "make veryclean" by around 12%.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[build] Refuse to attempt building with the GNU gold linker
GNU gold (part of newer binutils builds) does not appear to be
designed to support generic linker functionality, since its source
code contains several Linux-specific hard-coded assumptions about the
layout of ELF binaries. Attempting to build iPXE using GNU gold will
generally cause some kind of "linker internal error".
Provide an explicit error message suggesting the use of GNU ld
instead.
Reported-by: Chris Hills <chaz@chaz6.com>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
[build] Avoid spurious address comparison warnings in gcc 4.6
A construction such as "assert ( ptr != NULL )" seems to trigger a
false positive warning in gcc 4.6 if the value of "ptr" is known at
compile-time to be non-NULL. Use -Wno-address to inhibit this
warning.
Reported-by: Ralph Giles <giles@thaumas.net>
Tested-by: Ralph Giles <giles@thaumas.net>
Signed-off-by: Michael Brown <mcb30@ipxe.org>
The keymap files, though autogenerated, are checked in to version
control and should be considered as source files. They should never
be automatically rebuilt.
Signed-off-by: Michael Brown <mcb30@ipxe.org>
Michael Brown