Note that it's okay to pass NULL to qemuDomainDelTLSObjects in
qemuDomainAddTLSObjects as the tls-creds-x509 object was either not
created or qemu crashed.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Use the new monitor command internal API to allow wrapping of the object
name and alias into the JSON props so that they don't have to be passed
out of band.

The new API also takes a double pointer so that it can be cleared when
the value is consumed so that it does not need to happen in every single
caller.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

s/virQEMUBuildObjectCommandlineFromJSON/virQEMUBuildObjectCommandlineFromJSONType/

The function adds the object of a certain type. Change the name so that
we make room for the generic function.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The function adds the object of a certain type. Change the name so that
we make room for the generic function.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The function generates JSON properties rather than a string so rename
it.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Callers should generate the alias separately.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

No callers are using it.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

'secinfo' is present also for migrations. Delete the misleading comment.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Setting up the 'secinfo' for the TLS private key password also generates
the given alias, so we don't need to generate another one.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The alias of the secret for decrypting the TLS passphrase is useless
besides for TLS setup. Stop passing it around.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

We make sure that the disk supports TLS when preparing the environment
so there's no need to duplicate checks.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Callers need to know the alias anyways so it does not make much sense to
generate it inside of this function.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

qemuBuildTLSx509CommandLine has no business guessing which alias should
be used. The alias needs to be passed in.

Note that there's a lingering bad design of this, since the secret
object alias is based on the device name and not on the fact that the
secret is used for decrypting of the TLS private key. If we ever add
authentication for chardevs this will bite us.

Thankfully disk code does not support encrypted private keys for TLS so
it can be happily refactored there.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Move the TLS object alias setup earlier. Also make sure that the alias
is not overwritten on hotplug.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Some callers will not need to generate the alias again.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

For some reason the function returned an error if secAlias was not
passed in. It's not an error, in fact it's desired.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Always parse the 'tls' source field and let the drivers decide whether
they support it.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Select protocol using a switch with all cases enumerated. This will
simplify checking unsupported protocols and adding new support.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Remove the loop from qemuDomainPrepareDiskSourceTLS and rename it to
qemuDomainPrepareStorageSourceTLS. Currently there is no backing chain
to prepare so fixing one device is equivalent. In the future it will be
reused in a function which will do the looping.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Split out the code into a separate function so that all steps for a
storage protocol are contained and the original function is easily
extendable.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

When using blockdev the approach to base aliases will change. Add a
helper function that will aggregate all code which needs to be called
with the disk alias for the -drive to setup internal data.

qemuDomainSecretDiskPrepare wrapper is no longer necessary as the
contents were moved to a function which is designed to use the old
aliases.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Remove the call to the validating function from the function which sets
stuff up.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Convert the function to just prepare data for the disk. Callers need to
do the looping since there's more to do than just copy the data around.

The code path in qemuDomainPrepareDiskSource doesn't need to loop over
the chain yet, since there currently is no chain at this point. This
will be addressed later in the blockdev series where we will setup much
more stuff.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

qemuDomainPrepareDiskSourceChain should set up the disk zero detection
mode only for the top level image. Since it's invoked also for the
middle of the chain we need to check that it's really only the top level
image.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

When restarting libvirt would previously lose the alias of the x509
certificate object. Upon unplug we would then not delete the
corresponding objects.

Restore the alias if we know it should be there.

Luckily for disks we don't support encrypted TLS environment, so there's
no need to regenerate the 'secret' alias for decryption.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Libvirt uses the stored alias to detach the TLS x509 object on disk
unplug. As the alias was not stored, the object would not be detached
if unplugging disks after libvirtd restart.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Using 'haveTLS' to do this is pointless if the alias is not set.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Now that we remember the alias we've used to attach the secret objects
we should reuse them rather than trying to infer them from the disk
configuration.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Previously we did not store the aliases but rather re-generated them
when unplug was necessary. This is very cumbersome since the knowledge
when and which alias to use needs to be stored in the hotplug code as
well.

While this patch will not strictly improve this situation since there
still will be two places containing this code it at least will allow to
remove the mess from the disk-unplug code and will prevent introducing
more mess when adding blockdev support.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Rather than trying to figure out which alias was used, store it in the
status XML.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

We need to reference the secret objects by name when hot-unplugging
disks. Don't remove the alias so that it does not need to be
recalculated.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

It's desired to keep the alias around to allow referencing of the secret
object used with qemu. Add set of APIs which will destroy all data
except the alias.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Move the logic that determines which secret shall be used into the
caller and make this function work only for plain secrets.

This untangles the control flow by only checking relevant data.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

The encryption secret is setup only for LUKS and thus requires the new
approach. Use qemuDomainSecretInfoNew for initializing it.
Signed-off-by: NPeter Krempa <pkrempa@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>