brintos

brintos / linux-shallow public Read only

0
0
Text · 5.3 KiB · f2dcc39 Raw
138 lines · plain
1===================2Reproducible builds3===================4 5It is generally desirable that building the same source code with6the same set of tools is reproducible, i.e. the output is always7exactly the same.  This makes it possible to verify that the build8infrastructure for a binary distribution or embedded system has not9been subverted.  This can also make it easier to verify that a source10or tool change does not make any difference to the resulting binaries.11 12The `Reproducible Builds project`_ has more information about this13general topic.  This document covers the various reasons why building14the kernel may be unreproducible, and how to avoid them.15 16Timestamps17----------18 19The kernel embeds timestamps in three places:20 21* The version string exposed by ``uname()`` and included in22  ``/proc/version``23 24* File timestamps in the embedded initramfs25 26* If enabled via ``CONFIG_IKHEADERS``, file timestamps of kernel27  headers embedded in the kernel or respective module,28  exposed via ``/sys/kernel/kheaders.tar.xz``29 30By default the timestamp is the current time and in the case of31``kheaders`` the various files' modification times. This must32be overridden using the `KBUILD_BUILD_TIMESTAMP`_ variable.33If you are building from a git commit, you could use its commit date.34 35The kernel does *not* use the ``__DATE__`` and ``__TIME__`` macros,36and enables warnings if they are used.  If you incorporate external37code that does use these, you must override the timestamp they38correspond to by setting the `SOURCE_DATE_EPOCH`_ environment39variable.40 41User, host42----------43 44The kernel embeds the building user and host names in45``/proc/version``.  These must be overridden using the46`KBUILD_BUILD_USER and KBUILD_BUILD_HOST`_ variables.  If you are47building from a git commit, you could use its committer address.48 49Absolute filenames50------------------51 52When the kernel is built out-of-tree, debug information may include53absolute filenames for the source files.  This must be overridden by54including the ``-fdebug-prefix-map`` option in the `KCFLAGS`_ variable.55 56Depending on the compiler used, the ``__FILE__`` macro may also expand57to an absolute filename in an out-of-tree build.  Kbuild automatically58uses the ``-fmacro-prefix-map`` option to prevent this, if it is59supported.60 61The Reproducible Builds web site has more information about these62`prefix-map options`_.63 64Generated files in source packages65----------------------------------66 67The build processes for some programs under the ``tools/``68subdirectory do not completely support out-of-tree builds.  This may69cause a later source package build using e.g. ``make rpm-pkg`` to70include generated files.  You should ensure the source tree is71pristine by running ``make mrproper`` or ``git clean -d -f -x`` before72building a source package.73 74Module signing75--------------76 77If you enable ``CONFIG_MODULE_SIG_ALL``, the default behaviour is to78generate a different temporary key for each build, resulting in the79modules being unreproducible.  However, including a signing key with80your source would presumably defeat the purpose of signing modules.81 82One approach to this is to divide up the build process so that the83unreproducible parts can be treated as sources:84 851. Generate a persistent signing key.  Add the certificate for the key86   to the kernel source.87 882. Set the ``CONFIG_SYSTEM_TRUSTED_KEYS`` symbol to include the89   signing key's certificate, set ``CONFIG_MODULE_SIG_KEY`` to an90   empty string, and disable ``CONFIG_MODULE_SIG_ALL``.91   Build the kernel and modules.92 933. Create detached signatures for the modules, and publish them as94   sources.95 964. Perform a second build that attaches the module signatures.  It97   can either rebuild the modules or use the output of step 2.98 99Structure randomisation100-----------------------101 102If you enable ``CONFIG_RANDSTRUCT``, you will need to pre-generate103the random seed in ``scripts/basic/randstruct.seed`` so the same104value is used by each build. See ``scripts/gen-randstruct-seed.sh``105for details.106 107Debug info conflicts108--------------------109 110This is not a problem of unreproducibility, but of generated files111being *too* reproducible.112 113Once you set all the necessary variables for a reproducible build, a114vDSO's debug information may be identical even for different kernel115versions.  This can result in file conflicts between debug information116packages for the different kernel versions.117 118To avoid this, you can make the vDSO different for different119kernel versions by including an arbitrary string of "salt" in it.120This is specified by the Kconfig symbol ``CONFIG_BUILD_SALT``.121 122Git123---124 125Uncommitted changes or different commit ids in git can also lead126to different compilation results. For example, after executing127``git reset HEAD^``, even if the code is the same, the128``include/config/kernel.release`` generated during compilation129will be different, which will eventually lead to binary differences.130See ``scripts/setlocalversion`` for details.131 132.. _KBUILD_BUILD_TIMESTAMP: kbuild.html#kbuild-build-timestamp133.. _KBUILD_BUILD_USER and KBUILD_BUILD_HOST: kbuild.html#kbuild-build-user-kbuild-build-host134.. _KCFLAGS: kbuild.html#kcflags135.. _prefix-map options: https://reproducible-builds.org/docs/build-path/136.. _Reproducible Builds project: https://reproducible-builds.org/137.. _SOURCE_DATE_EPOCH: https://reproducible-builds.org/docs/source-date-epoch/138