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.

1 files changed, 0 insertions, 20 deletions

diff --git a/src/boot/bootctl.c b/src/boot/bootctl.c
index 2565f54586..1e862018d4 100644
--- 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;