On Wed, May 15, 2019 at 10:22:08AM -0700, Richard Henderson wrote: > On 5/15/19 9:53 AM, Daniel P. Berrangé wrote: > > On Tue, May 14, 2019 at 12:16:30PM -0700, Richard Henderson wrote: > >> For user-only, we require only the random number bits of the > >> crypto subsystem. > >> > >> We need to preserve --static linking, which for many recent Linux > >> distributions precludes using GnuTLS or GCrypt. Instead, use our > >> random-platform module unconditionally. > > > > I don't think we need to special case in this way. > > > > Today if you do a default build with all targets & tools and want > > to use --static, but don't have static libs available for some > > things you can achieve that > > > > ./configure --static --disable-gnutls --disable-gcrypt --disable-nettle > > But we don't really want all of those --disable arguments by default. It > would > be one thing if one explicitly used --enable-gnutls and got link errors. We > must preserve --static working all by itself.
That's already not working today unless you add extra args to disable build of the system emulators and tools. > > Previously if you took care to disable system emulators & tools > > you could avoid the need to pass the --disable-* args, but I > > think that's fairly minor. > > Well, no, you get link errors. > > (As an aside, IMO pkg-config is stupid in being only able to ask "is version X > installed" without also being about to ask "is a static version of X > installed". pkg-config has a --static option, it just doesn't use it.) Yeah it is very frustrating that it isn't actually useful in the way you'd expect. > But suppose we add back the patch for --static sanity check from v6. What are > we left with? No crypto libraries remain on Fedora 30. It appears that > Ubuntu > Bionic ships a static version of nettle, but nothing else. Is that useful on > its own? nettle isn't useful from POV of RNG. > > So I think we should just use $(crypto-obj-y) unconditionally in > > the user emulators, and get rid of crypto-aes-obj-y too. > > > > This will give a consistent crypto story across all the things we > > build with no special cases. > > Well, maybe. But what are we trying to accomplish? With this v7, if building dynamically we get some parts of QEMU using the full crypto/ impl and thus GNUTLS for RNG, and some parts of QEMU using just the rng-platform.o. I'd like it all to use the full crypto impl when building dynamically. Similarly if building statically, it should again result in the same fallback choices. If a static gnutls is available it should use that, but if none is present everything, it will get build with rng-platform.o IOW, either we just document need to pass --disable-gnutls --disable-gcrypt --disable-nettle if the distro lacks static versions of those libs - we already need thus documented as we already suffer from that problem when building statically. Or we need to make configure more clever and check if static linking actually works for these libs. > What use is crypto to the host side of linux-user? In general, all the crypto > that the application will do is on the guest side, within guest versions of > gnutls etc. All crypto that the guest expects of its kernel is done passing > off the syscall to the host kernel. > > That's why, here in v7, I began to think that perhaps all the faffing about > with pkg-config vs --static was just a waste of time. > > Have I missed something? Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
