reproducible-builds.rst 5.2 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137
  1. ===================
  2. Reproducible builds
  3. ===================
  4. It is generally desirable that building the same source code with
  5. the same set of tools is reproducible, i.e. the output is always
  6. exactly the same. This makes it possible to verify that the build
  7. infrastructure for a binary distribution or embedded system has not
  8. been subverted. This can also make it easier to verify that a source
  9. or tool change does not make any difference to the resulting binaries.
  10. The `Reproducible Builds project`_ has more information about this
  11. general topic. This document covers the various reasons why building
  12. the kernel may be unreproducible, and how to avoid them.
  13. Timestamps
  14. ----------
  15. The kernel embeds timestamps in three places:
  16. * The version string exposed by ``uname()`` and included in
  17. ``/proc/version``
  18. * File timestamps in the embedded initramfs
  19. * If enabled via ``CONFIG_IKHEADERS``, file timestamps of kernel
  20. headers embedded in the kernel or respective module,
  21. exposed via ``/sys/kernel/kheaders.tar.xz``
  22. By default the timestamp is the current time and in the case of
  23. ``kheaders`` the various files' modification times. This must
  24. be overridden using the `KBUILD_BUILD_TIMESTAMP`_ variable.
  25. If you are building from a git commit, you could use its commit date.
  26. The kernel does *not* use the ``__DATE__`` and ``__TIME__`` macros,
  27. and enables warnings if they are used. If you incorporate external
  28. code that does use these, you must override the timestamp they
  29. correspond to by setting the `SOURCE_DATE_EPOCH`_ environment
  30. variable.
  31. User, host
  32. ----------
  33. The kernel embeds the building user and host names in
  34. ``/proc/version``. These must be overridden using the
  35. `KBUILD_BUILD_USER and KBUILD_BUILD_HOST`_ variables. If you are
  36. building from a git commit, you could use its committer address.
  37. Absolute filenames
  38. ------------------
  39. When the kernel is built out-of-tree, debug information may include
  40. absolute filenames for the source files. This must be overridden by
  41. including the ``-fdebug-prefix-map`` option in the `KCFLAGS`_ variable.
  42. Depending on the compiler used, the ``__FILE__`` macro may also expand
  43. to an absolute filename in an out-of-tree build. Kbuild automatically
  44. uses the ``-fmacro-prefix-map`` option to prevent this, if it is
  45. supported.
  46. The Reproducible Builds web site has more information about these
  47. `prefix-map options`_.
  48. Generated files in source packages
  49. ----------------------------------
  50. The build processes for some programs under the ``tools/``
  51. subdirectory do not completely support out-of-tree builds. This may
  52. cause a later source package build using e.g. ``make rpm-pkg`` to
  53. include generated files. You should ensure the source tree is
  54. pristine by running ``make mrproper`` or ``git clean -d -f -x`` before
  55. building a source package.
  56. Module signing
  57. --------------
  58. If you enable ``CONFIG_MODULE_SIG_ALL``, the default behaviour is to
  59. generate a different temporary key for each build, resulting in the
  60. modules being unreproducible. However, including a signing key with
  61. your source would presumably defeat the purpose of signing modules.
  62. One approach to this is to divide up the build process so that the
  63. unreproducible parts can be treated as sources:
  64. 1. Generate a persistent signing key. Add the certificate for the key
  65. to the kernel source.
  66. 2. Set the ``CONFIG_SYSTEM_TRUSTED_KEYS`` symbol to include the
  67. signing key's certificate, set ``CONFIG_MODULE_SIG_KEY`` to an
  68. empty string, and disable ``CONFIG_MODULE_SIG_ALL``.
  69. Build the kernel and modules.
  70. 3. Create detached signatures for the modules, and publish them as
  71. sources.
  72. 4. Perform a second build that attaches the module signatures. It
  73. can either rebuild the modules or use the output of step 2.
  74. Structure randomisation
  75. -----------------------
  76. If you enable ``CONFIG_RANDSTRUCT``, you will need to pre-generate
  77. the random seed in ``scripts/basic/randstruct.seed`` so the same
  78. value is used by each build. See ``scripts/gen-randstruct-seed.sh``
  79. for details.
  80. Debug info conflicts
  81. --------------------
  82. This is not a problem of unreproducibility, but of generated files
  83. being *too* reproducible.
  84. Once you set all the necessary variables for a reproducible build, a
  85. vDSO's debug information may be identical even for different kernel
  86. versions. This can result in file conflicts between debug information
  87. packages for the different kernel versions.
  88. To avoid this, you can make the vDSO different for different
  89. kernel versions by including an arbitrary string of "salt" in it.
  90. This is specified by the Kconfig symbol ``CONFIG_BUILD_SALT``.
  91. Git
  92. ---
  93. Uncommitted changes or different commit ids in git can also lead
  94. to different compilation results. For example, after executing
  95. ``git reset HEAD^``, even if the code is the same, the
  96. ``include/config/kernel.release`` generated during compilation
  97. will be different, which will eventually lead to binary differences.
  98. See ``scripts/setlocalversion`` for details.
  99. .. _KBUILD_BUILD_TIMESTAMP: kbuild.html#kbuild-build-timestamp
  100. .. _KBUILD_BUILD_USER and KBUILD_BUILD_HOST: kbuild.html#kbuild-build-user-kbuild-build-host
  101. .. _KCFLAGS: kbuild.html#kcflags
  102. .. _prefix-map options: https://reproducible-builds.org/docs/build-path/
  103. .. _Reproducible Builds project: https://reproducible-builds.org/
  104. .. _SOURCE_DATE_EPOCH: https://reproducible-builds.org/docs/source-date-epoch/