libvirt/tests/qemuxml2argvmock.c

273 lines
6.2 KiB
C
Raw Normal View History

/*
* Copyright (C) 2014-2016 Red Hat, Inc.
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public
* License as published by the Free Software Foundation; either
* version 2.1 of the License, or (at your option) any later version.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General Public
* License along with this library. If not, see
* <http://www.gnu.org/licenses/>.
*/
#include <config.h>
#include "internal.h"
qemu: Utilize qemu secret objects for RBD auth/secret https://bugzilla.redhat.com/show_bug.cgi?id=1182074 If they're available and we need to pass secrets to qemu, then use the qemu domain secret object in order to pass the secrets for RBD volumes instead of passing the base64 encoded secret on the command line. The goal is to make AES secrets the default and have no user interaction required in order to allow using the AES mechanism. If the mechanism is not available, then fall back to the current plain mechanism using a base64 encoded secret. New APIs: qemu_domain.c: qemuDomainGetSecretAESAlias: Generate/return the secret object alias for an AES Secret Info type. This will be called from qemuDomainSecretAESSetup. qemuDomainSecretAESSetup: (private) This API handles the details of the generation of the AES secret and saves the pieces that need to be passed to qemu in order for the secret to be decrypted. The encrypted secret based upon the domain master key, an initialization vector (16 byte random value), and the stored secret. Finally, the requirement from qemu is the IV and encrypted secret are to be base64 encoded. qemu_command.c: qemuBuildSecretInfoProps: (private) Generate/return a JSON properties object for the AES secret to be used by both the command building and eventually the hotplug code in order to add the secret object. Code was designed so that in the future perhaps hotplug could use it if it made sense. qemuBuildObjectSecretCommandLine (private) Generate and add to the command line the -object secret for the secret. This will be required for the subsequent RBD reference to the object. qemuBuildDiskSecinfoCommandLine (private) Handle adding the AES secret object. Adjustments: qemu_domain.c: The qemuDomainSecretSetup was altered to call either the AES or Plain Setup functions based upon whether AES secrets are possible (we have the encryption API) or not, we have secrets, and of course if the protocol source is RBD. qemu_command.c: Adjust the qemuBuildRBDSecinfoURI API's in order to generate the specific command options for an AES secret, such as: -object secret,id=$alias,keyid=$masterKey,data=$base64encodedencrypted, format=base64 -drive file=rbd:pool/image:id=myname:auth_supported=cephx\;none:\ mon_host=mon1.example.org\:6321,password-secret=$alias,... where the 'id=' value is the secret object alias generated by concatenating the disk alias and "-aesKey0". The 'keyid= $masterKey' is the master key shared with qemu, and the -drive syntax will reference that alias as the 'password-secret'. For the -drive syntax, the 'id=myname' is kept to define the username, while the 'key=$base64 encoded secret' is removed. While according to the syntax described for qemu commit '60390a21' or as seen in the email archive: https://lists.gnu.org/archive/html/qemu-devel/2016-01/msg04083.html it is possible to pass a plaintext password via a file, the qemu commit 'ac1d8878' describes the more feature rich 'keyid=' option based upon the shared masterKey. Add tests for checking/comparing output. NB: For hotplug, since the hotplug code doesn't add command line arguments, passing the encoded secret directly to the monitor will suffice.
2016-04-11 23:26:14 +08:00
#include "viralloc.h"
#include "vircommand.h"
qemu: Utilize qemu secret objects for RBD auth/secret https://bugzilla.redhat.com/show_bug.cgi?id=1182074 If they're available and we need to pass secrets to qemu, then use the qemu domain secret object in order to pass the secrets for RBD volumes instead of passing the base64 encoded secret on the command line. The goal is to make AES secrets the default and have no user interaction required in order to allow using the AES mechanism. If the mechanism is not available, then fall back to the current plain mechanism using a base64 encoded secret. New APIs: qemu_domain.c: qemuDomainGetSecretAESAlias: Generate/return the secret object alias for an AES Secret Info type. This will be called from qemuDomainSecretAESSetup. qemuDomainSecretAESSetup: (private) This API handles the details of the generation of the AES secret and saves the pieces that need to be passed to qemu in order for the secret to be decrypted. The encrypted secret based upon the domain master key, an initialization vector (16 byte random value), and the stored secret. Finally, the requirement from qemu is the IV and encrypted secret are to be base64 encoded. qemu_command.c: qemuBuildSecretInfoProps: (private) Generate/return a JSON properties object for the AES secret to be used by both the command building and eventually the hotplug code in order to add the secret object. Code was designed so that in the future perhaps hotplug could use it if it made sense. qemuBuildObjectSecretCommandLine (private) Generate and add to the command line the -object secret for the secret. This will be required for the subsequent RBD reference to the object. qemuBuildDiskSecinfoCommandLine (private) Handle adding the AES secret object. Adjustments: qemu_domain.c: The qemuDomainSecretSetup was altered to call either the AES or Plain Setup functions based upon whether AES secrets are possible (we have the encryption API) or not, we have secrets, and of course if the protocol source is RBD. qemu_command.c: Adjust the qemuBuildRBDSecinfoURI API's in order to generate the specific command options for an AES secret, such as: -object secret,id=$alias,keyid=$masterKey,data=$base64encodedencrypted, format=base64 -drive file=rbd:pool/image:id=myname:auth_supported=cephx\;none:\ mon_host=mon1.example.org\:6321,password-secret=$alias,... where the 'id=' value is the secret object alias generated by concatenating the disk alias and "-aesKey0". The 'keyid= $masterKey' is the master key shared with qemu, and the -drive syntax will reference that alias as the 'password-secret'. For the -drive syntax, the 'id=myname' is kept to define the username, while the 'key=$base64 encoded secret' is removed. While according to the syntax described for qemu commit '60390a21' or as seen in the email archive: https://lists.gnu.org/archive/html/qemu-devel/2016-01/msg04083.html it is possible to pass a plaintext password via a file, the qemu commit 'ac1d8878' describes the more feature rich 'keyid=' option based upon the shared masterKey. Add tests for checking/comparing output. NB: For hotplug, since the hotplug code doesn't add command line arguments, passing the encoded secret directly to the monitor will suffice.
2016-04-11 23:26:14 +08:00
#include "vircrypto.h"
#include "virmock.h"
#include "virnetdev.h"
#include "virnetdevip.h"
#include "virnetdevtap.h"
#include "virnetdevopenvswitch.h"
#include "virnuma.h"
qemu: Utilize qemu secret objects for RBD auth/secret https://bugzilla.redhat.com/show_bug.cgi?id=1182074 If they're available and we need to pass secrets to qemu, then use the qemu domain secret object in order to pass the secrets for RBD volumes instead of passing the base64 encoded secret on the command line. The goal is to make AES secrets the default and have no user interaction required in order to allow using the AES mechanism. If the mechanism is not available, then fall back to the current plain mechanism using a base64 encoded secret. New APIs: qemu_domain.c: qemuDomainGetSecretAESAlias: Generate/return the secret object alias for an AES Secret Info type. This will be called from qemuDomainSecretAESSetup. qemuDomainSecretAESSetup: (private) This API handles the details of the generation of the AES secret and saves the pieces that need to be passed to qemu in order for the secret to be decrypted. The encrypted secret based upon the domain master key, an initialization vector (16 byte random value), and the stored secret. Finally, the requirement from qemu is the IV and encrypted secret are to be base64 encoded. qemu_command.c: qemuBuildSecretInfoProps: (private) Generate/return a JSON properties object for the AES secret to be used by both the command building and eventually the hotplug code in order to add the secret object. Code was designed so that in the future perhaps hotplug could use it if it made sense. qemuBuildObjectSecretCommandLine (private) Generate and add to the command line the -object secret for the secret. This will be required for the subsequent RBD reference to the object. qemuBuildDiskSecinfoCommandLine (private) Handle adding the AES secret object. Adjustments: qemu_domain.c: The qemuDomainSecretSetup was altered to call either the AES or Plain Setup functions based upon whether AES secrets are possible (we have the encryption API) or not, we have secrets, and of course if the protocol source is RBD. qemu_command.c: Adjust the qemuBuildRBDSecinfoURI API's in order to generate the specific command options for an AES secret, such as: -object secret,id=$alias,keyid=$masterKey,data=$base64encodedencrypted, format=base64 -drive file=rbd:pool/image:id=myname:auth_supported=cephx\;none:\ mon_host=mon1.example.org\:6321,password-secret=$alias,... where the 'id=' value is the secret object alias generated by concatenating the disk alias and "-aesKey0". The 'keyid= $masterKey' is the master key shared with qemu, and the -drive syntax will reference that alias as the 'password-secret'. For the -drive syntax, the 'id=myname' is kept to define the username, while the 'key=$base64 encoded secret' is removed. While according to the syntax described for qemu commit '60390a21' or as seen in the email archive: https://lists.gnu.org/archive/html/qemu-devel/2016-01/msg04083.html it is possible to pass a plaintext password via a file, the qemu commit 'ac1d8878' describes the more feature rich 'keyid=' option based upon the shared masterKey. Add tests for checking/comparing output. NB: For hotplug, since the hotplug code doesn't add command line arguments, passing the encoded secret directly to the monitor will suffice.
2016-04-11 23:26:14 +08:00
#include "virrandom.h"
#include "virscsi.h"
#include "virscsivhost.h"
#include "virstring.h"
#include "virtpm.h"
#include "virutil.h"
#include "qemu/qemu_interface.h"
#include "qemu/qemu_command.h"
#include <time.h>
#include <unistd.h>
#include <fcntl.h>
#define VIR_FROM_THIS VIR_FROM_NONE
long virGetSystemPageSize(void)
{
return 4096;
}
time_t time(time_t *t)
{
const time_t ret = 1234567890;
if (t)
*t = ret;
return ret;
}
bool
virNumaIsAvailable(void)
{
return true;
}
int
virNumaGetMaxNode(void)
{
return 7;
}
/* We shouldn't need to mock virNumaNodeIsAvailable() and *definitely* not
* virNumaNodesetIsAvailable(), but it seems to be the only way to get
* mocking to work with Clang on FreeBSD, so keep these duplicates around
* until we figure out a cleaner solution */
bool
virNumaNodeIsAvailable(int node)
{
return node >= 0 && node <= virNumaGetMaxNode();
}
bool
virNumaNodesetIsAvailable(virBitmapPtr nodeset)
{
ssize_t bit = -1;
if (!nodeset)
return true;
while ((bit = virBitmapNextSetBit(nodeset, bit)) >= 0) {
if (virNumaNodeIsAvailable(bit))
continue;
return false;
}
return true;
}
char *
virTPMCreateCancelPath(const char *devpath)
{
char *path;
(void)devpath;
ignore_value(VIR_STRDUP(path, "/sys/class/misc/tpm0/device/cancel"));
return path;
}
/**
* Large values for memory would fail on 32 bit systems, despite having
* variables that support it.
*/
unsigned long long
virMemoryMaxValue(bool capped ATTRIBUTE_UNUSED)
{
return LLONG_MAX;
}
char *
virSCSIDeviceGetSgName(const char *sysfs_prefix ATTRIBUTE_UNUSED,
const char *adapter ATTRIBUTE_UNUSED,
unsigned int bus ATTRIBUTE_UNUSED,
unsigned int target ATTRIBUTE_UNUSED,
unsigned long long unit ATTRIBUTE_UNUSED)
{
char *ret;
ignore_value(VIR_STRDUP(ret, "sg0"));
return ret;
}
int
virSCSIVHostOpenVhostSCSI(int *vhostfd)
{
*vhostfd = STDERR_FILENO + 1;
return 0;
}
int
virNetDevTapCreate(char **ifname,
const char *tunpath ATTRIBUTE_UNUSED,
int *tapfd,
size_t tapfdSize,
unsigned int flags ATTRIBUTE_UNUSED)
{
size_t i;
for (i = 0; i < tapfdSize; i++)
tapfd[i] = STDERR_FILENO + 1 + i;
VIR_FREE(*ifname);
return VIR_STRDUP(*ifname, "vnet0");
}
int
virNetDevSetMAC(const char *ifname ATTRIBUTE_UNUSED,
const virMacAddr *macaddr ATTRIBUTE_UNUSED)
{
return 0;
}
int virNetDevIPAddrAdd(const char *ifname ATTRIBUTE_UNUSED,
virSocketAddr *addr ATTRIBUTE_UNUSED,
virSocketAddr *peer ATTRIBUTE_UNUSED,
unsigned int prefix ATTRIBUTE_UNUSED)
{
return 0;
}
int
virNetDevSetOnline(const char *ifname ATTRIBUTE_UNUSED,
bool online ATTRIBUTE_UNUSED)
{
return 0;
}
int
virNetDevRunEthernetScript(const char *ifname ATTRIBUTE_UNUSED,
const char *script ATTRIBUTE_UNUSED)
{
return 0;
}
char *
virHostGetDRMRenderNode(void)
{
char *dst = NULL;
ignore_value(VIR_STRDUP(dst, "/dev/dri/foo"));
return dst;
}
static void (*real_virCommandPassFD)(virCommandPtr cmd, int fd, unsigned int flags);
static const int testCommandPassSafeFDs[] = { 1730, 1731 };
void
virCommandPassFD(virCommandPtr cmd,
int fd,
unsigned int flags)
{
size_t i;
for (i = 0; i < ARRAY_CARDINALITY(testCommandPassSafeFDs); i++) {
if (testCommandPassSafeFDs[i] == fd) {
if (!real_virCommandPassFD)
VIR_MOCK_REAL_INIT(virCommandPassFD);
real_virCommandPassFD(cmd, fd, flags);
return;
}
}
}
qemu: Utilize qemu secret objects for RBD auth/secret https://bugzilla.redhat.com/show_bug.cgi?id=1182074 If they're available and we need to pass secrets to qemu, then use the qemu domain secret object in order to pass the secrets for RBD volumes instead of passing the base64 encoded secret on the command line. The goal is to make AES secrets the default and have no user interaction required in order to allow using the AES mechanism. If the mechanism is not available, then fall back to the current plain mechanism using a base64 encoded secret. New APIs: qemu_domain.c: qemuDomainGetSecretAESAlias: Generate/return the secret object alias for an AES Secret Info type. This will be called from qemuDomainSecretAESSetup. qemuDomainSecretAESSetup: (private) This API handles the details of the generation of the AES secret and saves the pieces that need to be passed to qemu in order for the secret to be decrypted. The encrypted secret based upon the domain master key, an initialization vector (16 byte random value), and the stored secret. Finally, the requirement from qemu is the IV and encrypted secret are to be base64 encoded. qemu_command.c: qemuBuildSecretInfoProps: (private) Generate/return a JSON properties object for the AES secret to be used by both the command building and eventually the hotplug code in order to add the secret object. Code was designed so that in the future perhaps hotplug could use it if it made sense. qemuBuildObjectSecretCommandLine (private) Generate and add to the command line the -object secret for the secret. This will be required for the subsequent RBD reference to the object. qemuBuildDiskSecinfoCommandLine (private) Handle adding the AES secret object. Adjustments: qemu_domain.c: The qemuDomainSecretSetup was altered to call either the AES or Plain Setup functions based upon whether AES secrets are possible (we have the encryption API) or not, we have secrets, and of course if the protocol source is RBD. qemu_command.c: Adjust the qemuBuildRBDSecinfoURI API's in order to generate the specific command options for an AES secret, such as: -object secret,id=$alias,keyid=$masterKey,data=$base64encodedencrypted, format=base64 -drive file=rbd:pool/image:id=myname:auth_supported=cephx\;none:\ mon_host=mon1.example.org\:6321,password-secret=$alias,... where the 'id=' value is the secret object alias generated by concatenating the disk alias and "-aesKey0". The 'keyid= $masterKey' is the master key shared with qemu, and the -drive syntax will reference that alias as the 'password-secret'. For the -drive syntax, the 'id=myname' is kept to define the username, while the 'key=$base64 encoded secret' is removed. While according to the syntax described for qemu commit '60390a21' or as seen in the email archive: https://lists.gnu.org/archive/html/qemu-devel/2016-01/msg04083.html it is possible to pass a plaintext password via a file, the qemu commit 'ac1d8878' describes the more feature rich 'keyid=' option based upon the shared masterKey. Add tests for checking/comparing output. NB: For hotplug, since the hotplug code doesn't add command line arguments, passing the encoded secret directly to the monitor will suffice.
2016-04-11 23:26:14 +08:00
int
virNetDevOpenvswitchGetVhostuserIfname(const char *path ATTRIBUTE_UNUSED,
char **ifname)
{
return VIR_STRDUP(*ifname, "vhost-user0");
}
int
qemuInterfaceOpenVhostNet(virDomainDefPtr def ATTRIBUTE_UNUSED,
virDomainNetDefPtr net,
int *vhostfd,
size_t *vhostfdSize)
{
size_t i;
if (!(net->model && STREQ(net->model, "virtio"))) {
*vhostfdSize = 0;
return 0;
}
for (i = 0; i < *vhostfdSize; i++)
vhostfd[i] = STDERR_FILENO + 42 + i;
return 0;
}
int
qemuOpenChrChardevUNIXSocket(const virDomainChrSourceDef *dev ATTRIBUTE_UNUSED)
{
/* We need to return an FD number for a UNIX listener socket,
* which will be given to QEMU via a CLI arg. We need a fixed
* number to get stable tests. This is obviously not a real
* FD number, so when virCommand closes the FD in the parent
* it will get EINVAL, but that's (hopefully) not going to
* be a problem....
*/
if (fcntl(1729, F_GETFD) != -1)
abort();
return 1729;
}
int
qemuBuildTPMOpenBackendFDs(const char *tpmdev ATTRIBUTE_UNUSED,
const char *cancel_path ATTRIBUTE_UNUSED,
int *tpmfd,
int *cancelfd)
{
if (fcntl(1730, F_GETFD) != -1 ||
fcntl(1731, F_GETFD) != -1)
abort();
*tpmfd = 1730;
*cancelfd = 1731;
return 0;
}