2014-02-05 14:18:46 +00:00
|
|
|
/*
|
2016-04-26 16:49:48 +00:00
|
|
|
* Copyright (C) 2014-2016 Red Hat, Inc.
|
2014-02-05 14:18:46 +00:00
|
|
|
*
|
|
|
|
* 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>
|
|
|
|
|
2021-05-07 15:53:40 +00:00
|
|
|
#define LIBVIRT_VIRIDENTITYPRIV_H_ALLOW
|
|
|
|
|
2014-02-06 12:54:53 +00:00
|
|
|
#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 15:26:14 +00:00
|
|
|
#include "viralloc.h"
|
2016-03-23 15:19:26 +00:00
|
|
|
#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 15:26:14 +00:00
|
|
|
#include "vircrypto.h"
|
2021-05-07 15:53:40 +00:00
|
|
|
#include "viridentitypriv.h"
|
2015-02-02 10:26:49 +00:00
|
|
|
#include "virmock.h"
|
2020-09-23 15:33:12 +00:00
|
|
|
#include "virlog.h"
|
2016-03-23 15:19:26 +00:00
|
|
|
#include "virnetdev.h"
|
2021-04-14 22:34:48 +00:00
|
|
|
#include "virnetdevbandwidth.h"
|
2016-06-27 10:17:59 +00:00
|
|
|
#include "virnetdevip.h"
|
2016-03-23 15:19:26 +00:00
|
|
|
#include "virnetdevtap.h"
|
2016-12-22 09:33:28 +00:00
|
|
|
#include "virnetdevopenvswitch.h"
|
2016-03-23 15:19:26 +00:00
|
|
|
#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 15:26:14 +00:00
|
|
|
#include "virrandom.h"
|
2016-03-23 15:19:26 +00:00
|
|
|
#include "virscsi.h"
|
2016-11-22 03:58:17 +00:00
|
|
|
#include "virscsivhost.h"
|
2015-11-18 00:44:13 +00:00
|
|
|
#include "virstring.h"
|
|
|
|
#include "virtpm.h"
|
2016-03-23 15:19:26 +00:00
|
|
|
#include "virutil.h"
|
2018-04-17 10:11:17 +00:00
|
|
|
#include "qemu/qemu_interface.h"
|
2018-03-14 12:16:11 +00:00
|
|
|
#include "qemu/qemu_command.h"
|
2014-02-06 12:54:53 +00:00
|
|
|
#include <time.h>
|
2015-02-02 10:26:49 +00:00
|
|
|
#include <unistd.h>
|
2018-03-14 12:16:11 +00:00
|
|
|
#include <fcntl.h>
|
2015-02-02 10:26:49 +00:00
|
|
|
|
2015-11-18 00:44:13 +00:00
|
|
|
#define VIR_FROM_THIS VIR_FROM_NONE
|
|
|
|
|
2015-02-02 10:26:49 +00:00
|
|
|
long virGetSystemPageSize(void)
|
|
|
|
{
|
|
|
|
return 4096;
|
|
|
|
}
|
2014-02-05 14:18:46 +00:00
|
|
|
|
2020-01-09 14:07:15 +00:00
|
|
|
GDateTime *g_date_time_new_now_utc(void)
|
2014-02-05 14:18:46 +00:00
|
|
|
{
|
2020-01-09 14:07:15 +00:00
|
|
|
return g_date_time_new_from_unix_utc(1234567890);
|
|
|
|
}
|
|
|
|
|
|
|
|
GDateTime *g_date_time_new_now_local(void)
|
|
|
|
{
|
|
|
|
return g_date_time_new_from_unix_local(1234567890);
|
2014-02-05 14:18:46 +00:00
|
|
|
}
|
2014-11-04 02:44:40 +00:00
|
|
|
|
2018-05-02 15:35:21 +00:00
|
|
|
bool
|
|
|
|
virNumaIsAvailable(void)
|
|
|
|
{
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2014-11-04 02:44:40 +00:00
|
|
|
int
|
|
|
|
virNumaGetMaxNode(void)
|
|
|
|
{
|
2018-09-13 08:55:21 +00:00
|
|
|
return 7;
|
2014-11-04 02:44:40 +00:00
|
|
|
}
|
2014-11-06 11:16:54 +00:00
|
|
|
|
2018-05-02 15:35:21 +00:00
|
|
|
/* 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 */
|
2014-11-06 11:16:54 +00:00
|
|
|
bool
|
|
|
|
virNumaNodeIsAvailable(int node)
|
|
|
|
{
|
|
|
|
return node >= 0 && node <= virNumaGetMaxNode();
|
|
|
|
}
|
2018-05-02 15:35:21 +00:00
|
|
|
|
|
|
|
bool
|
2021-03-11 07:16:13 +00:00
|
|
|
virNumaNodesetIsAvailable(virBitmap *nodeset)
|
2018-05-02 15:35:21 +00:00
|
|
|
{
|
|
|
|
ssize_t bit = -1;
|
|
|
|
|
|
|
|
if (!nodeset)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
while ((bit = virBitmapNextSetBit(nodeset, bit)) >= 0) {
|
|
|
|
if (virNumaNodeIsAvailable(bit))
|
|
|
|
continue;
|
|
|
|
|
2020-09-23 15:33:12 +00:00
|
|
|
virReportError(VIR_ERR_INTERNAL_ERROR,
|
|
|
|
"Mock: no numa node set is available at bit %zd", bit);
|
2018-05-02 15:35:21 +00:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
2015-11-18 00:44:13 +00:00
|
|
|
|
|
|
|
char *
|
|
|
|
virTPMCreateCancelPath(const char *devpath)
|
|
|
|
{
|
|
|
|
(void)devpath;
|
|
|
|
|
2021-10-22 08:56:01 +00:00
|
|
|
return g_strdup("/sys/class/misc/tpm0/device/cancel");
|
2015-11-18 00:44:13 +00:00
|
|
|
}
|
2015-12-10 13:36:51 +00:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Large values for memory would fail on 32 bit systems, despite having
|
|
|
|
* variables that support it.
|
|
|
|
*/
|
|
|
|
unsigned long long
|
2019-10-14 12:45:03 +00:00
|
|
|
virMemoryMaxValue(bool capped G_GNUC_UNUSED)
|
2015-12-10 13:36:51 +00:00
|
|
|
{
|
|
|
|
return LLONG_MAX;
|
|
|
|
}
|
2016-03-23 08:57:06 +00:00
|
|
|
|
2016-11-22 03:58:17 +00:00
|
|
|
int
|
|
|
|
virSCSIVHostOpenVhostSCSI(int *vhostfd)
|
|
|
|
{
|
|
|
|
*vhostfd = STDERR_FILENO + 1;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-03-23 15:19:26 +00:00
|
|
|
int
|
|
|
|
virNetDevTapCreate(char **ifname,
|
2019-10-14 12:45:03 +00:00
|
|
|
const char *tunpath G_GNUC_UNUSED,
|
2016-03-23 15:19:26 +00:00
|
|
|
int *tapfd,
|
|
|
|
size_t tapfdSize,
|
2019-10-14 12:45:03 +00:00
|
|
|
unsigned int flags G_GNUC_UNUSED)
|
2016-03-23 15:19:26 +00:00
|
|
|
{
|
|
|
|
size_t i;
|
|
|
|
|
|
|
|
for (i = 0; i < tapfdSize; i++)
|
|
|
|
tapfd[i] = STDERR_FILENO + 1 + i;
|
|
|
|
|
2019-08-26 04:24:34 +00:00
|
|
|
if (STREQ_NULLABLE(*ifname, "mytap0")) {
|
|
|
|
return 0;
|
|
|
|
} else {
|
|
|
|
VIR_FREE(*ifname);
|
2019-10-20 10:55:05 +00:00
|
|
|
*ifname = g_strdup("vnet0");
|
|
|
|
return 0;
|
2019-08-26 04:24:34 +00:00
|
|
|
}
|
2016-03-23 15:19:26 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
int
|
2019-10-14 12:45:03 +00:00
|
|
|
virNetDevSetMAC(const char *ifname G_GNUC_UNUSED,
|
|
|
|
const virMacAddr *macaddr G_GNUC_UNUSED)
|
2016-03-23 15:19:26 +00:00
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-08-26 04:24:34 +00:00
|
|
|
|
|
|
|
int
|
|
|
|
virNetDevExists(const char *ifname)
|
|
|
|
{
|
2019-11-03 12:34:04 +00:00
|
|
|
return STREQ(ifname, "mytap0");
|
2019-08-26 04:24:34 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
2019-10-14 12:45:03 +00:00
|
|
|
int virNetDevIPAddrAdd(const char *ifname G_GNUC_UNUSED,
|
|
|
|
virSocketAddr *addr G_GNUC_UNUSED,
|
|
|
|
virSocketAddr *peer G_GNUC_UNUSED,
|
|
|
|
unsigned int prefix G_GNUC_UNUSED)
|
2016-04-26 16:49:48 +00:00
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-04-04 21:00:06 +00:00
|
|
|
int
|
2019-10-14 12:45:03 +00:00
|
|
|
virNetDevSetOnline(const char *ifname G_GNUC_UNUSED,
|
|
|
|
bool online G_GNUC_UNUSED)
|
2016-04-04 21:00:06 +00:00
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-03-23 15:19:26 +00:00
|
|
|
int
|
2019-10-14 12:45:03 +00:00
|
|
|
virNetDevRunEthernetScript(const char *ifname G_GNUC_UNUSED,
|
|
|
|
const char *script G_GNUC_UNUSED)
|
2016-03-23 15:19:26 +00:00
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-11-14 15:48:27 +00:00
|
|
|
char *
|
|
|
|
virHostGetDRMRenderNode(void)
|
|
|
|
{
|
2019-10-17 08:10:10 +00:00
|
|
|
return g_strdup("/dev/dri/foo");
|
2018-11-14 15:48:27 +00:00
|
|
|
}
|
|
|
|
|
2021-03-11 07:16:13 +00:00
|
|
|
static void (*real_virCommandPassFD)(virCommand *cmd, int fd, unsigned int flags);
|
2018-08-14 13:02:56 +00:00
|
|
|
|
2020-10-14 17:08:27 +00:00
|
|
|
static const int testCommandPassSafeFDs[] = { 1730, 1731, 1732 };
|
2018-08-14 13:02:56 +00:00
|
|
|
|
2016-03-23 15:19:26 +00:00
|
|
|
void
|
2021-03-11 07:16:13 +00:00
|
|
|
virCommandPassFD(virCommand *cmd,
|
2018-08-14 13:02:56 +00:00
|
|
|
int fd,
|
|
|
|
unsigned int flags)
|
2016-03-23 15:19:26 +00:00
|
|
|
{
|
2018-08-14 13:02:56 +00:00
|
|
|
size_t i;
|
|
|
|
|
2019-10-15 11:55:26 +00:00
|
|
|
for (i = 0; i < G_N_ELEMENTS(testCommandPassSafeFDs); i++) {
|
2018-08-14 13:02:56 +00:00
|
|
|
if (testCommandPassSafeFDs[i] == fd) {
|
|
|
|
if (!real_virCommandPassFD)
|
|
|
|
VIR_MOCK_REAL_INIT(virCommandPassFD);
|
|
|
|
|
|
|
|
real_virCommandPassFD(cmd, fd, flags);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
2016-03-23 15:19:26 +00:00
|
|
|
}
|
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 15:26:14 +00:00
|
|
|
|
2016-12-22 09:33:28 +00:00
|
|
|
int
|
2019-10-14 12:45:03 +00:00
|
|
|
virNetDevOpenvswitchGetVhostuserIfname(const char *path G_GNUC_UNUSED,
|
2019-11-06 10:59:22 +00:00
|
|
|
bool server G_GNUC_UNUSED,
|
2016-12-22 09:33:28 +00:00
|
|
|
char **ifname)
|
|
|
|
{
|
2019-10-20 10:55:05 +00:00
|
|
|
*ifname = g_strdup("vhost-user0");
|
|
|
|
return 1;
|
2016-12-22 09:33:28 +00:00
|
|
|
}
|
2018-04-17 10:11:17 +00:00
|
|
|
|
|
|
|
int
|
2021-03-11 07:16:13 +00:00
|
|
|
qemuInterfaceOpenVhostNet(virDomainDef *def G_GNUC_UNUSED,
|
|
|
|
virDomainNetDef *net,
|
2018-04-17 10:11:17 +00:00
|
|
|
int *vhostfd,
|
|
|
|
size_t *vhostfdSize)
|
|
|
|
{
|
|
|
|
size_t i;
|
|
|
|
|
2019-01-21 22:59:02 +00:00
|
|
|
if (!virDomainNetIsVirtioModel(net)) {
|
2018-04-17 10:11:17 +00:00
|
|
|
*vhostfdSize = 0;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < *vhostfdSize; i++)
|
|
|
|
vhostfd[i] = STDERR_FILENO + 42 + i;
|
|
|
|
return 0;
|
|
|
|
}
|
2018-03-14 12:16:11 +00:00
|
|
|
|
|
|
|
|
|
|
|
int
|
2019-10-14 12:45:03 +00:00
|
|
|
qemuOpenChrChardevUNIXSocket(const virDomainChrSourceDef *dev G_GNUC_UNUSED)
|
2018-03-14 12:16:11 +00:00
|
|
|
|
|
|
|
{
|
|
|
|
/* 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;
|
|
|
|
}
|
2018-08-14 11:50:01 +00:00
|
|
|
|
|
|
|
|
|
|
|
int
|
2019-10-14 12:45:03 +00:00
|
|
|
qemuBuildTPMOpenBackendFDs(const char *tpmdev G_GNUC_UNUSED,
|
|
|
|
const char *cancel_path G_GNUC_UNUSED,
|
2018-08-14 11:50:01 +00:00
|
|
|
int *tpmfd,
|
|
|
|
int *cancelfd)
|
|
|
|
{
|
|
|
|
if (fcntl(1730, F_GETFD) != -1 ||
|
|
|
|
fcntl(1731, F_GETFD) != -1)
|
|
|
|
abort();
|
|
|
|
|
|
|
|
*tpmfd = 1730;
|
|
|
|
*cancelfd = 1731;
|
|
|
|
return 0;
|
|
|
|
}
|
2020-10-08 14:22:50 +00:00
|
|
|
|
|
|
|
|
|
|
|
int
|
2021-04-14 22:34:48 +00:00
|
|
|
virNetDevBandwidthSetRootQDisc(const char *ifname G_GNUC_UNUSED,
|
|
|
|
const char *qdisc G_GNUC_UNUSED)
|
2020-10-08 14:22:50 +00:00
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
2020-10-14 17:08:27 +00:00
|
|
|
|
|
|
|
|
|
|
|
int
|
2021-03-11 07:16:13 +00:00
|
|
|
qemuInterfaceVDPAConnect(virDomainNetDef *net G_GNUC_UNUSED)
|
2020-10-14 17:08:27 +00:00
|
|
|
{
|
|
|
|
if (fcntl(1732, F_GETFD) != -1)
|
|
|
|
abort();
|
|
|
|
return 1732;
|
|
|
|
}
|
2021-05-07 15:53:40 +00:00
|
|
|
|
|
|
|
char *
|
|
|
|
virIdentityEnsureSystemToken(void)
|
|
|
|
{
|
|
|
|
return g_strdup("3de80bcbf22d4833897f1638e01be9b2");
|
|
|
|
}
|