mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
synced 2025-04-19 20:58:31 +09:00
cacd22ce69
-fmacro-prefix-map only affects __FILE__ and __BASE_FILE__. Other references, for example in debug information, are not affected. This makes handling of file references in the compiler outputs harder to use and creates problems for reproducible builds. Switch to -ffile-prefix map which affects all references. Also drop the documentation section advising manual specification of -fdebug-prefix-map for reproducible builds, as it is not necessary anymore. Suggested-by: Ben Hutchings <ben@decadent.org.uk> Link: https://lore.kernel.org/lkml/c49cc967294f9a3a4a34f69b6a8727a6d3959ed8.camel@decadent.org.uk/ Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
121 lines
4.6 KiB
ReStructuredText
121 lines
4.6 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.
|
|
|
|
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``.
|
|
|
|
Git
|
|
---
|
|
|
|
Uncommitted changes or different commit ids in git can also lead
|
|
to different compilation results. For example, after executing
|
|
``git reset HEAD^``, even if the code is the same, the
|
|
``include/config/kernel.release`` generated during compilation
|
|
will be different, which will eventually lead to binary differences.
|
|
See ``scripts/setlocalversion`` for details.
|
|
|
|
.. _KBUILD_BUILD_TIMESTAMP: kbuild.html#kbuild-build-timestamp
|
|
.. _KBUILD_BUILD_USER and KBUILD_BUILD_HOST: kbuild.html#kbuild-build-user-kbuild-build-host
|
|
.. _Reproducible Builds project: https://reproducible-builds.org/
|
|
.. _SOURCE_DATE_EPOCH: https://reproducible-builds.org/docs/source-date-epoch/
|