Signed-off-by: NEric Blake <eblake@redhat.com>

Currently, all of the VirtioOptions are under a single <optional>
element, however, neither our parser/formatter or QEMU driver requires
the presence of all the options if only a single one from the set has
been specified, so fix it and silence the schema validator.
Signed-off-by: NErik Skultety <eskultet@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

In 60046283 we've tried to remove Author(s): lines
from comments at the beginning of our source files. Well, in some
files while we removed the "Author" line we did not remove the
actual list of authors.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NErik Skultety <eskultet@redhat.com>

Add more configure options for NVDIMM
Signed-off-by: NLuyao Zhong <luyao.zhong@intel.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

According to the result parsing from xml, add the unarmed property
into QEMU command line:

-device nvdimm,...[,unarmed=on]
Signed-off-by: NLuyao Zhong <luyao.zhong@intel.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

According to the result parsing from xml, add pmem property
into QEMU command line:

-object memory-backend-file,...[,pmem=on]
Signed-off-by: NLuyao Zhong <luyao.zhong@intel.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

According to the result parsing from xml, add align property
into QEMU command line:

-object memory-backend-file,...[,align=xxx]
Signed-off-by: NLuyao Zhong <luyao.zhong@intel.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Deprecate DO_TEST to do nvdimm qemuxml2argvdata tests, because
DO_TEST_CAPS_LATEST is a better choice. The DO_TEST needs
to specify all qemu capabilities and is not easy for scaling.
Signed-off-by: NLuyao Zhong <luyao.zhong@intel.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

This capability tracks if nvdimm has the unarmed attribute or not
for the nvdimm readonly xml attribute.
Signed-off-by: NLuyao Zhong <luyao.zhong@intel.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

This capability tracks if memory-backend-file has the pmem
attribute or not.
Signed-off-by: NLuyao Zhong <luyao.zhong@intel.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

This capability tracks if memory-backend-file has the align
attribute or not.
Signed-off-by: NLuyao Zhong <luyao.zhong@intel.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

The 'readonly' option allows users to mark vNVDIMM read-only:

<devices>
  ...
  <memory model='nvdimm' access='shared'>
      <source>
          <path>/dev/dax0.0</path>
      </source>
      <target>
          <size unit='MiB'>4094</size>
          <node>0</node>
          <label>
              <size unit='MiB'>2</size>
          </label>
          <readonly/>
      </target>
  </memory>
  ...
</devices>
Signed-off-by: NLuyao Zhong <luyao.zhong@intel.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

The 'pmem' option allows users to specify whether the backend
storage of memory-backend-file is a real persistent memory:

<devices>
  ...
  <memory model='nvdimm' access='shared'>
      <source>
          <path>/dev/dax0.0</path>
          <pmem/>
      </source>
      <target>
          <size unit='MiB'>4094</size>
          <node>0</node>
          <label>
              <size unit='MiB'>2</size>
          </label>
      </target>
  </memory>
  ...
</devices>
Signed-off-by: NLuyao Zhong <luyao.zhong@intel.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

NVDIMM emulation will mmap the backend file, it uses host pagesize
as the alignment of mapping address before, but some backends may
require alignments different from the pagesize. So the 'alignsize'
option is introduced to allow specification of the proper alignment:

<devices>
  ...
  <memory model='nvdimm' access='shared'>
      <source>
          <path>/dev/dax0.0</path>
          <alignsize unit='MiB'>2</alignsize>
      </source>
      <target>
          <size unit='MiB'>4094</size>
          <node>0</node>
          <label>
              <size unit='MiB'>2</size>
          </label>
      </target>
  </memory>
  ...
</devices>
Signed-off-by: NLuyao Zhong <luyao.zhong@intel.com>
Reviewed-by: NJohn Ferlan <jferlan@redhat.com>

Before launching a SEV guest we take the base64-encoded guest owner's
data specified in launchSecurity and create files with the same content
under /var/lib/libvirt/qemu/<domain>. The reason for this is that we
need to pass these files on to QEMU which then uses them to communicate
with the SEV firmware, except when it doesn't have permissions to open
those files since we don't relabel them.

https://bugzilla.redhat.com/show_bug.cgi?id=1658112Signed-off-by: NErik Skultety <eskultet@redhat.com>
Acked-by: NMichal Privoznik <mprivozn@redhat.com>

Since SEV operates on a per domain basis, it's very likely that all
SEV launch-related data will be created under
/var/lib/libvirt/qemu/<domain_name>. Therefore, when calling into
qemuProcessSEVCreateFile we can assume @libDir as the directory prefix
rather than passing it explicitly.
Signed-off-by: NErik Skultety <eskultet@redhat.com>
Acked-by: NMichal Privoznik <mprivozn@redhat.com>

Includes:
  maint: Run 'make update-copyright'
Signed-off-by: NJán Tomko <jtomko@redhat.com>

The @con type security_context_t is actually a "char *", so the
correct check should be to dereference one more level; otherwise,
we could return/use the NULL pointer later in a subsequent
virSecuritySELinuxSetFileconImpl call (using @fcon).
Suggested-by: NMichal Prívozník <mprivozn@redhat.com>
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

If virSecuritySELinuxRestoreFileLabel returns 0 or -1 too soon, then
the @newpath will be leaked.
Suggested-by: NMichal Privoznik <mprivozn@redhat.com>
Signed-off-by: NJohn Ferlan <jferlan@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Because missing optional storage source is not error. The patch
address only local files. Fixing other cases is a bit ugly.
Below is example of error notice in log now:

error: virStorageFileReportBrokenChain:427 :
   Cannot access storage file '/path/to/missing/optional/disk':
  	No such file or directory
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

Every time we call all domain stats for inactive domain with
unavailable storage source we get error message in logs [1]. It's a bit noisy.
While it's arguable whether we need such message or not for mandatory
disks we would like not to see messages for optional disks. Let's
filter at least for cases of local files. Fixing other cases would
require passing flag down the stack to .backendInit of storage
which is ugly.

Stats for active domain are fine because we either drop disks
with unavailable sources or clean source which is handled
by virStorageSourceIsEmpty in qemuDomainGetStatsOneBlockFallback.

We have these logs for successful stats since 25aa7035 (version 1.2.15)
which in turn fixes 596a1371 (version 1.2.12 )which added substantial
stats for offline disks.

[1] error message example:
qemuOpenFileAs:3324 : Failed to open file '/path/to/optional/disk': No such file or directory
Signed-off-by: NNikolay Shirokovskiy <nshirokovskiy@virtuozzo.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NAndrea Bolognani <abologna@redhat.com>

Introduce caching whether /dev/kvm is usable as the QEMU user:QEMU
group. This reduces the overhead of the QEMU capabilities cache
lookup. Before this patch there were many fork() calls used for
checking whether /dev/kvm is accessible. Now we store the result
whether /dev/kvm is accessible or not and we only need to re-run the
virFileAccessibleAs check if the ctime of /dev/kvm has changed.
Suggested-by: NDaniel P. Berrangé <berrange@redhat.com>
Signed-off-by: NMarc Hartmayer <mhartmay@linux.ibm.com>
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>

Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Our code is not bug free. The refcounting I introduced will
almost certainly not work in some use cases. Provide a script
that will remove all the XATTRs set by libvirt so that it can
start cleanly.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

This test checks if security label remembering works correctly.
It uses qemuSecurity* APIs to do that. And some mocking (even
though it's not real mocking as we are used to from other tests
like virpcitest). So far, only DAC driver is tested.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

We are setting label on kernel, initrd, dtb and slic_table files.
But we never restored it.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

It helps whe trying to match calls with virSecuritySELinuxSetAllLabel
if the order in which devices are set/restored is the same in
both functions.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

When iterating over list of paths/disk sources to relabel it may
happen that the process fails at some point. In that case, for
the sake of keeping seclabel refcount (stored in XATTRs) in sync
with reality we have to perform rollback. However, if that fails
too the only thing we can do is warn user.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

It's important to keep XATTRs untouched (well, in the same state
they were in when entering the function). Otherwise our
refcounting would be messed up.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Similarly to what I did in DAC driver, this also requires the
same SELinux label to be used for shared paths. If a path is
already in use by a domain (or domains) then and the domain we
are starting now wants to access the path it has to have the same
SELinux label. This might look too restrictive as the new label
can still guarantee access to already running domains but in
reality it is very unlikely and usually an admin mistake.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

It is going to be important to know if the current transaction we
are running is a restore operation or set label operation so that
we know whether to call virSecurityGetRememberedLabel() or
virSecuritySetRememberedLabel(). That is, whether we are in a
restore and therefore have to fetch the remembered label, or we
are in set operation and therefore have to store the original
label.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Now that we have seclabel remembering we can safely restore
labels for shared and RO disks. In fact we need to do that to
keep seclabel refcount stored in XATTRs in sync with reality.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

This also requires the same DAC label to be used for shared
paths. If a path is already in use by a domain (or domains) then
and the domain we are starting now wants to access the path it
has to have the same DAC label. This might look too restrictive
as the new label can still guarantee access to already running
domains but in reality it is very unlikely and usually an admin
mistake.

This requirement also simplifies seclabel remembering, because we
can store only one seclabel and have a refcounter for how many
times the path is in use. If we were to allow different labels
and store them in some sort of array the algorithm to match
labels to domains would be needlessly complicated.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

Because the implementation that will be used for label
remembering/recall is not atomic we have to give callers a chance
to enable or disable it. That is, enable it if and only if
metadata locking is enabled. Otherwise the feature MUST be turned
off.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

We are setting label on kernel, initrd, dtb and slic_table files.
But we never restored it.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

It helps whe trying to match calls with virSecurityDACSetAllLabel
if the order in which devices are set/restored is the same in
both functions.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

When iterating over list of paths/disk sources to relabel it may
happen that the process fails at some point. In that case, for
the sake of keeping seclabel refcount (stored in XATTRs) in sync
with reality we have to perform rollback. However, if that fails
too the only thing we can do is warn user.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

It's important to keep XATTRs untouched (well, in the same state
they were in when entering the function). Otherwise our
refcounting would be messed up.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NDaniel P. Berrangé <berrange@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>

This file implements wrappers over XATTR getter/setter. It
ensures the proper XATTR namespace is used.
Signed-off-by: NMichal Privoznik <mprivozn@redhat.com>
Reviewed-by: NJán Tomko <jtomko@redhat.com>