bootctl: install system token on virtualized systems

Removing the virtualization check might not be the worst thing in the
world, and would potentially get many, many more systems properly seeded
rather than not seeded. There are a few reasons to consider this:

- In most QEMU setups and most guides on how to setup QEMU, a separate
  pflash file is used for nvram variables, and this generally isn't
  copied around.

- We're now hashing in a timestamp, which should provide some level of
  differentiation, given that EFI_TIME has a nanoseconds field.

- The kernel itself will additionally hash in: a high resolution time
  stamp, a cycle counter, RDRAND output, the VMGENID uniquely
  identifying the virtual machine, any other seeds from the hypervisor
  (like from FDT or setup_data).

- During early boot, the RNG is reseeded quite frequently to account for
  the importance of early differentiation.

So maybe the mitigating factors make the actual feared problem
significantly less likely and therefore the pros of having file-based
seeding might outweigh the cons of weird misconfigured setups having a
hypothetical problem on first boot.

diff --git a/docs/RANDOM_SEEDS.md b/docs/RANDOM_SEEDS.md
index b7240f0d896f4bb5b5dd5adbb336d70d18fe644b..a1134d6417ea0a104ff0679304f39ff0ae1eb257 100644 (file)
--- a/docs/RANDOM_SEEDS.md
+++ b/docs/RANDOM_SEEDS.md
@@ -232,17 +232,10 @@ boot, in order to ensure the entropy pool is filled up quickly.
    too), which should be safe even with FAT file system drivers built into
    low-quality EFI firmwares.
 
-   As a special restriction: in virtualized environments PID 1 will refrain
-   from using this mechanism, for safety reasons. This is because on VM
-   environments the EFI variable space and the disk space is generally not
-   maintained physically separate (for example, `qemu` in EFI mode stores the
-   variables in the ESP itself). The robustness towards sloppy OS image
-   generation is the main purpose of maintaining the 'system token' however,
-   and if the EFI variable storage is not kept physically separate from the OS
-   image there's no point in it. That said, OS builders that know that they are
-   not going to replicate the built image on multiple systems may opt to turn
-   off the 'system token' concept by setting `random-seed-mode always` in the
-   ESP's
+   If the system token is not desired but this seeding mechanism still is, OS
+   builders that know that they are not going to replicate the built image on
+   multiple systems may opt to turn off the 'system token' concept by setting
+   `random-seed-mode always` in the ESP's
    [`/loader/loader.conf`](https://www.freedesktop.org/software/systemd/man/loader.conf.html)
    file. If done, `systemd-boot` will use the random seed file even if no
    system token is found in EFI variables.

diff --git a/src/boot/bootctl.c b/src/boot/bootctl.c
index 2565f54586e960fd1a0fa8fa8cfd4c72d5b9584c..1e862018d43327e4c67845ec046701cde966bb10 100644 (file)
--- a/src/boot/bootctl.c
+++ b/src/boot/bootctl.c
@@ -2044,26 +2044,6 @@ static int install_random_seed(const char *esp) {
         if (r < 0) {
                 if (r != -ENXIO)
                          log_warning_errno(r, "Failed to parse $SYSTEMD_WRITE_SYSTEM_TOKEN, ignoring.");
-
-                if (detect_vm() > 0) {
-                        /* Let's not write a system token if we detect we are running in a VM
-                         * environment. Why? Our default security model for the random seed uses the system
-                         * token as a mechanism to ensure we are not vulnerable to golden master sloppiness
-                         * issues, i.e. that people initialize the random seed file, then copy the image to
-                         * many systems and end up with the same random seed in each that is assumed to be
-                         * valid but in reality is the same for all machines. By storing a system token in
-                         * the EFI variable space we can make sure that even though the random seeds on disk
-                         * are all the same they will be different on each system under the assumption that
-                         * the EFI variable space is maintained separate from the random seed storage. That
-                         * is generally the case on physical systems, as the ESP is stored on persistent
-                         * storage, and the EFI variables in NVRAM. However in virtualized environments this
-                         * is generally not true: the EFI variable set is typically stored along with the
-                         * disk image itself. For example, using the OVMF EFI firmware the EFI variables are
-                         * stored in a file in the ESP itself. */
-
-                        log_notice("Not installing system token, since we are running in a virtualized environment.");
-                        return 0;
-                }
         } else if (r == 0) {
                 log_notice("Not writing system token, because $SYSTEMD_WRITE_SYSTEM_TOKEN is set to false.");
                 return 0;

diff --git a/units/systemd-boot-system-token.service b/units/systemd-boot-system-token.service
index 5a56d7c3317e33c5f2705bd9d014687b13d14e90..689b902000582f6d75868d70e694f535204b0bf4 100644 (file)
--- a/units/systemd-boot-system-token.service
+++ b/units/systemd-boot-system-token.service
@@ -16,15 +16,11 @@ After=local-fs.target systemd-random-seed.service
 Conflicts=shutdown.target initrd-switch-root.target
 Before=shutdown.target initrd-switch-root.target
 
-# Don't run this in a VM environment, because there EFI variables are not
-# actually stored in NVRAM, independent of regular storage.
-ConditionVirtualization=no
-
 # Only run this if the boot loader can support random seed initialization.
 ConditionPathExists=/sys/firmware/efi/efivars/LoaderFeatures-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f
 
-# Only run this if there is no system token defined yet, or …
-ConditionPathExists=|!/sys/firmware/efi/efivars/LoaderSystemToken-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f
+# Only run this if there is no system token defined yet
+ConditionPathExists=!/sys/firmware/efi/efivars/LoaderSystemToken-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f
 
 [Service]
 Type=oneshot