128 lines
4.9 KiB
ReStructuredText
128 lines
4.9 KiB
ReStructuredText
===================
|
|
Reproducible builds
|
|
===================
|
|
|
|
It is generally desirable that building the same source code with
|
|
the same set of tools is reproducible, i.e. the output is always
|
|
exactly the same. This makes it possible to verify that the build
|
|
infrastructure for a binary distribution or embedded system has not
|
|
been subverted. This can also make it easier to verify that a source
|
|
or tool change does not make any difference to the resulting binaries.
|
|
|
|
The `Reproducible Builds project`_ has more information about this
|
|
general topic. This document covers the various reasons why building
|
|
the kernel may be unreproducible, and how to avoid them.
|
|
|
|
Timestamps
|
|
----------
|
|
|
|
The kernel embeds timestamps in three places:
|
|
|
|
* The version string exposed by ``uname()`` and included in
|
|
``/proc/version``
|
|
|
|
* File timestamps in the embedded initramfs
|
|
|
|
* If enabled via ``CONFIG_IKHEADERS``, file timestamps of kernel
|
|
headers embedded in the kernel or respective module,
|
|
exposed via ``/sys/kernel/kheaders.tar.xz``
|
|
|
|
By default the timestamp is the current time and in the case of
|
|
``kheaders`` the various files' modification times. This must
|
|
be overridden using the `KBUILD_BUILD_TIMESTAMP`_ variable.
|
|
If you are building from a git commit, you could use its commit date.
|
|
|
|
The kernel does *not* use the ``__DATE__`` and ``__TIME__`` macros,
|
|
and enables warnings if they are used. If you incorporate external
|
|
code that does use these, you must override the timestamp they
|
|
correspond to by setting the `SOURCE_DATE_EPOCH`_ environment
|
|
variable.
|
|
|
|
User, host
|
|
----------
|
|
|
|
The kernel embeds the building user and host names in
|
|
``/proc/version``. These must be overridden using the
|
|
`KBUILD_BUILD_USER and KBUILD_BUILD_HOST`_ variables. If you are
|
|
building from a git commit, you could use its committer address.
|
|
|
|
Absolute filenames
|
|
------------------
|
|
|
|
When the kernel is built out-of-tree, debug information may include
|
|
absolute filenames for the source files. This must be overridden by
|
|
including the ``-fdebug-prefix-map`` option in the `KCFLAGS`_ variable.
|
|
|
|
Depending on the compiler used, the ``__FILE__`` macro may also expand
|
|
to an absolute filename in an out-of-tree build. Kbuild automatically
|
|
uses the ``-fmacro-prefix-map`` option to prevent this, if it is
|
|
supported.
|
|
|
|
The Reproducible Builds web site has more information about these
|
|
`prefix-map options`_.
|
|
|
|
Generated files in source packages
|
|
----------------------------------
|
|
|
|
The build processes for some programs under the ``tools/``
|
|
subdirectory do not completely support out-of-tree builds. This may
|
|
cause a later source package build using e.g. ``make rpm-pkg`` to
|
|
include generated files. You should ensure the source tree is
|
|
pristine by running ``make mrproper`` or ``git clean -d -f -x`` before
|
|
building a source package.
|
|
|
|
Module signing
|
|
--------------
|
|
|
|
If you enable ``CONFIG_MODULE_SIG_ALL``, the default behaviour is to
|
|
generate a different temporary key for each build, resulting in the
|
|
modules being unreproducible. However, including a signing key with
|
|
your source would presumably defeat the purpose of signing modules.
|
|
|
|
One approach to this is to divide up the build process so that the
|
|
unreproducible parts can be treated as sources:
|
|
|
|
1. Generate a persistent signing key. Add the certificate for the key
|
|
to the kernel source.
|
|
|
|
2. Set the ``CONFIG_SYSTEM_TRUSTED_KEYS`` symbol to include the
|
|
signing key's certificate, set ``CONFIG_MODULE_SIG_KEY`` to an
|
|
empty string, and disable ``CONFIG_MODULE_SIG_ALL``.
|
|
Build the kernel and modules.
|
|
|
|
3. Create detached signatures for the modules, and publish them as
|
|
sources.
|
|
|
|
4. Perform a second build that attaches the module signatures. It
|
|
can either rebuild the modules or use the output of step 2.
|
|
|
|
Structure randomisation
|
|
-----------------------
|
|
|
|
If you enable ``CONFIG_RANDSTRUCT``, you will need to pre-generate
|
|
the random seed in ``scripts/basic/randstruct.seed`` so the same
|
|
value is used by each build. See ``scripts/gen-randstruct-seed.sh``
|
|
for details.
|
|
|
|
Debug info conflicts
|
|
--------------------
|
|
|
|
This is not a problem of unreproducibility, but of generated files
|
|
being *too* reproducible.
|
|
|
|
Once you set all the necessary variables for a reproducible build, a
|
|
vDSO's debug information may be identical even for different kernel
|
|
versions. This can result in file conflicts between debug information
|
|
packages for the different kernel versions.
|
|
|
|
To avoid this, you can make the vDSO different for different
|
|
kernel versions by including an arbitrary string of "salt" in it.
|
|
This is specified by the Kconfig symbol ``CONFIG_BUILD_SALT``.
|
|
|
|
.. _KBUILD_BUILD_TIMESTAMP: kbuild.html#kbuild-build-timestamp
|
|
.. _KBUILD_BUILD_USER and KBUILD_BUILD_HOST: kbuild.html#kbuild-build-user-kbuild-build-host
|
|
.. _KCFLAGS: kbuild.html#kcflags
|
|
.. _prefix-map options: https://reproducible-builds.org/docs/build-path/
|
|
.. _Reproducible Builds project: https://reproducible-builds.org/
|
|
.. _SOURCE_DATE_EPOCH: https://reproducible-builds.org/docs/source-date-epoch/
|