diff options
| -rw-r--r-- | docs/RANDOM_SEEDS.md | 15 | ||||
| -rw-r--r-- | src/boot/bootctl.c | 20 | ||||
| -rw-r--r-- | units/systemd-boot-system-token.service | 8 |
3 files changed, 6 insertions, 37 deletions
diff --git a/docs/RANDOM_SEEDS.md b/docs/RANDOM_SEEDS.md index b7240f0d89..a1134d6417 100644 --- 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 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; diff --git a/units/systemd-boot-system-token.service b/units/systemd-boot-system-token.service index 5a56d7c331..689b902000 100644 --- 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 |