Commit Graph

24 Commits

Author SHA1 Message Date
Nikolay Shirokovskiy
d4439a6b83 src: adopt to VIR_DRV_SUPPORTS_FEATURE return -1
Otherwise in some places we can mistakenly report 'unsupported' error instead
of root cause. So let's handle root cause explicitly from the macro.

Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2021-01-06 17:10:01 +03:00
Ján Tomko
92047567cf Reduce scope of some variables
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
2020-09-24 11:19:06 +02:00
Daniel P. Berrangé
a9fa62f327 src: don't include ref count in debug messages / probes
The ref count will be private to the GObject base class
and we must not peek at it, even for debugging messages.

Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2020-06-03 10:20:17 +01:00
Daniel P. Berrangé
5209791e47 src: warn against virNodeGetInfo() API call due to inaccurate info
Reviewed-by: Jiri Denemark <jdenemar@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-12-18 11:57:18 +00:00
Erik Skultety
d6064e2759 libvirt-<module>: Check caller-provided buffers to be NULL with size > 0
Pre-Glib era which used malloc allowed the size of the client-side
buffers to be declared as 0, because malloc documents that it can either
return 0 or a unique pointer on 0 size allocations.
With glib this doesn't work anymore, because glib documents that for
such allocation requests NULL is always returned which results in an
error in our public API checks server-side.
This patch complements the fix in the RPC layer by explicitly erroring
out on the following combination of args used by our legacy APIs (their
moder equivalents don't suffer from this):

function(caller-allocated-array, size, ...) {
    if (!caller-allocated-array && size > 0)
        return error;
}

treating everything else as a valid input and potentially let that fail
on the server-side rather than client-side.

https://bugzilla.redhat.com/show_bug.cgi?id=1772842

Signed-off-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-11-21 18:16:35 +01:00
Ján Tomko
67e72053c1 Use G_N_ELEMENTS instead of ARRAY_CARDINALITY
Prefer the GLib version of the macro.

Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 16:14:19 +02:00
Daniel P. Berrangé
305cdc37f0 api: introduce virConnectSetIdentity for passing uid, gid, selinux info
When using the fine grained access control mechanism for APIs, when a
client connects to libvirtd, the latter will fetch the uid, gid, selinux
info of the remote client on the UNIX domain socket. This is then used
as the identity when checking ACLs.

With the new split daemons things are a bit more complicated. The user
can connect to virtproxyd, which in turn connects to virtqemud. When
virtqemud requests the identity over the UNIX domain socket, it will
get the identity that virtproxyd is running as, not the identity of
the real end user/application.

virproxyd knows what the real identity is, and needs to be able to
forward this information to virtqemud. The virConnectSetIdentity API
provides a mechanism for doing this. Obviously virtqemud should not
accept such identity overrides from any client, it must only honour it
from a trusted client, aka one running as the same uid/gid as itself.

The typed parameters exposed in the API are the same as those currently
supported by the internal virIdentity class, with a few small name
changes.

Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-09-16 11:25:01 +01:00
Daniel P. Berrangé
9a04cad07d libvirt: remove link to outdated mailing list post
The virConnectGetType() method has an unfortunate signature, returning a
static string that must not be freed by the caller. The remote driver,
however, gets this string dynamically over an RPC call, which raised a
design discussion on the mailing list. Eventually the problem was
resolved by having the remote driver cache the returned string
internally and free it when the connection was closed.

The link to the mailing list is thus talking about a problem that does
not actually exist in the final implementation, and at best serves to
confuse the reader into thinking there might be a memory leak.

Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-07-08 15:02:55 +01:00
Ján Tomko
bf6c2830b6 api: disallow virConnect*HypervisorCPU on read-only connections
These APIs can be used to execute arbitrary emulators.
Forbid them on read-only connections.

Fixes: CVE-2019-10168
Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-06-20 13:50:56 +02:00
Brijesh Singh
45422935c3 libvirt: Introduce virNodeGetSEVInfo public API
The API can be used by application to retrieve the Platform Diffie-Hellman
Key and Platform Certificate chain.

Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
2018-06-12 09:52:00 +02:00
Jiri Denemark
7d0a1efcd6 Introduce virConnectBaselineHypervisorCPU public API
The new API computes the most feature-rich CPU which is compatible with
all given CPUs and can be provided by the specified hypervisor. It is a
more useful version of virConnectBaselineCPU, which doesn't consider any
hypervisor capabilities when computing the best CPU.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Collin Walling <walling@linux.ibm.com>
2018-05-28 15:58:05 +02:00
Jiri Denemark
24a41aa643 Introduce virConnectCompareHypervisorCPU public API
This new API compares the given CPU description with the CPU the
specified hypervisor is able to provide on the host. It is a more useful
version of virConnectCompareCPU, which compares the CPU definition with
the host CPU without considering any specific hypervisor and its
abilities.

https://bugzilla.redhat.com/show_bug.cgi?id=1559832
https://bugzilla.redhat.com/show_bug.cgi?id=1559835

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Collin Walling <walling@linux.ibm.com>
2018-05-28 15:55:17 +02:00
Jiri Denemark
95ef9ceea4 Improve documentation of virConnectGetCPUModelNames
Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
Reviewed-by: Collin Walling <walling@linux.ibm.com>
Reviewed-by: Kashyap Chamarthy <kchamart@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2018-05-28 15:54:10 +02:00
Michal Privoznik
4e42981b36 src: Unify virObject member name
Whenever we declare a new object the first member of the struct
has to be virObject (or any other member of that family). Now, up
until now we did not care about the name of the struct member.
But lets unify it so that we can do some checks at compile time
later.

The unified name is 'parent'.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Erik Skultety <eskultet@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2018-04-18 10:04:55 +02:00
Daniel P. Berrange
32d6c7386d Print hex values with '0x' prefix and octal with '0' in debug messages
Seeing a log message saying 'flags=93' is ambiguous & confusing unless
you happen to know that libvirt always prints flags as hex.  Change our
debug messages so that they always add a '0x' prefix when printing flags,
and '0' prefix when printing mode. A few other misc places gain a '0x'
prefix in error messages too.

Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2017-09-25 13:34:53 +01:00
Jiri Denemark
1bc8484326 cpu: Special case models == NULL in cpuGetModels
Some CPU drivers (such as arm) do not provide list of CPUs libvirt
supports and just pass any CPU model from domain XML directly to QEMU.
Such driver need to return models == NULL and success from cpuGetModels.

Signed-off-by: Jiri Denemark <jdenemar@redhat.com>
2016-09-22 15:40:08 +02:00
Shivaprasad G Bhat
e6806d7938 Document to not rely on virConnectGetMaxVcpus API
The API virConnectGetMaxVcpus doesn't really reflect the actual usable number
of cpus as the maximum limits can be different for kvm and/or qemu. So update
the documentation to use virConnectGetDomainCapabilities() instead.

Signed-off-by: Shivaprasad G Bhat <sbhat@linux.vnet.ibm.com>
2016-06-24 19:20:14 +02:00
Nikolay Shirokovskiy
88f09b75eb close callback: move it to driver
Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
2016-03-01 14:17:38 +00:00
Nikolay Shirokovskiy
fa8c164501 close callback API: remove unnecessary locks
closeCallback pointer is immutable (set on connection object creation)
and self-locking.
2016-03-01 14:16:56 +00:00
Nikolay Shirokovskiy
24dbb69f21 factor out virConnectCloseCallbackDataPtr methods
Make register and unregister functions return void because
we can check the state of callback object beforehand via
virConnectCloseCallbackDataGetCallback. This can be done
without race conditions if we use higher level locks for registering
and unregistering. The fact they return void simplifies
task of consistent registering/unregistering.

Signed-off-by: Nikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>
2016-03-01 14:16:56 +00:00
Laine Stump
e983e62514 debug: assure NULLSTR() around all %s args in debug at top of public APIs
There are also a couple that were very uninformatively just logging
the value of the pointer rather than the string itself:

* the "name" arg to virNodeDeviceLookupByName()
* wwnn and wwpn args to virNodeDeviceLookupSCSIHostByWWN()

All char*'s that make sense should now have their contents logged
rather than the pointer, and all %s args should now be inside
NULLSTR().
2015-05-28 13:13:45 -04:00
Martin Kletzander
fae5b555c8 Change virConnectPtr into virObjectLocklable
It already had a virMutex inside, so this is just a cleanup.

Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2015-04-15 13:33:35 +02:00
Ján Tomko
02c8b66d6a Add VIR_CONNECT_BASELINE_CPU_MIGRATABLE flag
This flag for virConnectBaselineCPU will allow filtering out
CPU features that block migration from the result.

https://bugzilla.redhat.com/show_bug.cgi?id=1171484
2015-03-02 07:59:12 +01:00
Daniel P. Berrange
0399b188ac Move virConnect/virNode related APIs out of libvirt.c
Introduce a src/libvirt-host.c file to hold all the
methods related to the virConnect type.
2014-10-24 16:59:58 +01:00