Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Load virtio_rng early in the game #6665

Closed
wants to merge 1 commit into from
Closed

Load virtio_rng early in the game #6665

wants to merge 1 commit into from

Conversation

haraldh
Copy link
Member

@haraldh haraldh commented Aug 24, 2017

If libgcrypt is initialized, it needs a entropy for its random pool.
Without virtio_rng loaded initialize_libgcrypt() takes forever and the
boot stalls for a long time.

@haraldh
Copy link
Member Author

haraldh commented Aug 24, 2017

Oh, in FIPS mode we have an even bigger problem.

In RHEL, we have a patch :

libgcrypt does this in the library constructor: 

+      if (fips_mode ())
+         _gcry_random_initialize (1);

So, if systemd is executed and linked against libgcrypt, we have a problem with low entropy 👎

@lsiudut
Copy link

lsiudut commented Aug 24, 2017

And unfortunately it is when built with Lorax, so I guess in all of RH-related use cases. It kills VM provisioning completely.

@poettering
Copy link
Member

If libgcrypt is initialized, it needs a entropy for its random pool.
Without virtio_rng loaded initialize_libgcrypt() takes forever and the
boot stalls for a long time.

hmm, did it always do that? how come this only comes up now?

int r = detect_vm();

return (r == VIRTUALIZATION_KVM || r == VIRTUALIZATION_QEMU);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please use IN_SET() for cases like this:

return IN_SET(detect_vm(), VIRTUALIZATION_KVM, VIRTUALIZATION_QEMU);

@@ -68,6 +75,7 @@ int kmod_setup(void) {
/* netfilter is needed by networkd, nspawn among others, and cannot be autoloaded */
{ "ip_tables", "/proc/net/ip_tables_names", false, false, NULL },
#endif
{ "virtio_rng", NULL, false, false, vm_is_kvm_or_qemu },
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please add a comment why we do this

@poettering poettering added reviewed/needs-rework 🔨 PR has been reviewed and needs another round of reworks pid1 labels Aug 28, 2017
@poettering
Copy link
Member

hmm, can we tune the detection of this functionality a bit? it appears the availability of this virtio iface is announced to the OS an this can be easily checked via /sys. Can we tweak the detction accordingly, and look for the actual virtio iface rather thank blanket qemu/kvm checks? That way we don#t misdetect qemu invocations without it, and other VM implementations can implement the same iface sooner or later and things will just work.

@haraldh
Copy link
Member Author

haraldh commented Aug 31, 2017

@poettering for /sys checking, we would have to check every /sys/devices/pci*/*/modalias for

pci:v00001AF4d00001005*
pci:v00001AF4d00001044*

If true randomness is needed before udev is triggered, which would load
virtio_rng, reading /dev/random takes forever and the boot stalls for a
long time.
@poettering
Copy link
Member

modinfo virtio-rng suggests the the following match instead: "virtio:d00000004v*" btw, not pci matches?

but looping through those dirs should be pretty starightforward, no?

@haraldh
Copy link
Member Author

haraldh commented Aug 31, 2017

#6710

is the alternative with sysfs parsing

@poettering
Copy link
Member

Closing this one in favour of #6710

@poettering poettering closed this Aug 31, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pid1 reviewed/needs-rework 🔨 PR has been reviewed and needs another round of reworks
Development

Successfully merging this pull request may close these issues.

None yet

3 participants