IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
* libvirt fills in cbitpos and reducedPhysBits for us
* libvirt errors if type is missing
* libvirt errors if host/qemu doesn't support sev
So drop it all. This simplifies testing because we don't need
sev domcaps in place just to generate the XML
Signed-off-by: Cole Robinson <crobinso@redhat.com>
The code previously was just encoding the same defaults as libvirt,
which doesn't really add anything.
Instead, let's prefer type='emulator' model='tpm-crb', which
gives the most modern virtualization friendly config. When we don't
know if that will work, we mostly leave things up to libvirt to fill
in.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Break out the CPU secure stuff from being inline in the class, most
of the logic there is not relevant to understanding what the
domcapabilities API provides
Signed-off-by: Cole Robinson <crobinso@redhat.com>
When libvirt and qemu are new enough, use host-passthrough for the
CPU default. Nowadays this is recommended over host-model for most
end user usage where migration isn't a critical feature.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
host-copy was the old default, but it's fundamentally flawed. Since
we switched to host-model default a few years back, it's not advertised
in the docs or selectable via virt-manager any more.
Have it print a warning and invoke host-model-only
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This is from Gerd's suggestions here:
https://www.kraxel.org/blog/2019/09/display-devices-in-qemu/
When the guest supports it, we should use virtio. qxl is on the way
out, and the benefits are marginal and add a security and maintenance
burden.
While here, check domcaps that qxl or virtio are actually available.
Modern qemu has device modules, so device support may not be installed.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Let users choose libvirt's os.firmware=efi setting in the UI, putting
it about the firmware path list, since it's the preferred default
these days.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
<os firmware='efi'> is the libvirt official way to do what we
historically implement with `--boot uefi`, and UEFI setup in
virt-manager.
Let's prefer libvirt's official method if the support is advertised
in domcapabilities.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This replaces the pattern:
Guest.set_uefi_path(Guest.get_uefi_path())
With a single entrypoint
Guest.enable_uefi()
to immediately change the guest config to use UEFI, using our
default logic.
This will make it easier to change that logic in the future, like
using <os firmware='efi'> instead of hardcoded paths
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Linux memfd memory backend doesn't require any host setup, We prefer to
use it as the simplest memory XML adjustments to make virtiofs works.
Signed-off-by: Lin Ma <lma@suse.com>
Check whether virtiofs is exposed in domcapabilities, We can use it as a
proxy for 'libvirt is new enough to allow bare memory access mode=shared'
as well.
Signed-off-by: Lin Ma <lma@suse.com>
The bare metal world is moving to a situation where UEFI is going to be
the only supported firmware and there will be a strong expectation for
TPM and SecureBoot support.
With this in mind, if we're enabling UEFI on a VM, it makes sense to
also provide a TPM alongside it.
Since this requires swtpm to be installed we can't do this
unconditionally. The forthcoming libvirt release expands the domain
capabilities to report whether TPMs are supported, so we check that.
The user can disable the default TPM by requesting --tpm none
https://github.com/virt-manager/virt-manager/issues/310
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
This has been reported for the libvirt qemu driver since v1.3.5,
released June 2016. But we need to keep some fallback logic for
the test driver, and to keep the testsuite happy
Signed-off-by: Cole Robinson <crobinso@redhat.com>
Bhyve requires explicit loader configuration. So query
domain capabilities, try to find the "official"
firmware and configure all the necessary loader options.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Roman Bogorodskiy <bogorodskiy@gmail.com>
https://bugzilla.redhat.com/show_bug.cgi?id=1883008
In the example above this is because the VM XML has an invalid machine
type, so domcaps fetching entirely fails, and a get_enum() call
then fails. But this could happen if using virt-manager against an
older libvirt that doesn't advertise the enum
Signed-off-by: Cole Robinson <crobinso@redhat.com>
We need to check against None, which is the initial value, otherwise
a host with none of the security features present will repeatedly poll
libvirt baseline APIs
Signed-off-by: Cole Robinson <crobinso@redhat.com>
With libvirt-python >= 4.4.0 and libvirt < 4.4.0 we would receive
libvirt.libvirtError exception because the python binding knows about
the function but it's not supported by libvirt. However, in case that
the python binding is older then 4.4.0 it will raise AttributeError
because the function is not implemented in python binding as well.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
domcapabilities already handles disk and hostdev. Let's add support for
getting video devices as well.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Init a shared log instance in virtinst/logger.py, and use that
throughout the code base, so we aren't calling directly into
'logging'. This helps protect our logging output from being
cluttered with other library output, as happens with some
'requests' usage
These include platform checks - libvirt & QEMU - as well as
configuration - SEV is only supported with UEFI.
Another configuration requirement made in this patch is Q35 machine,
since ADM recommends Q35 in their setups even though SEV can work with
the legacy PC machine type, but we'd have to turn on
virtio-non-transitional for all virtio devices with some other potential
pitfalls along the way.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Erik Skultety <eskultet@redhat.com>
The data in question are 'cbitpos' denoting which addressing bit is the
encryption bit and 'reduced_phys_bits' denoting how many physical
address space we lose by turning on the encryption. Both of these are
hypervisor dependent and thus will be the same for all the guest
residing on the same host, but need to be specified for future migration
purposes.
But given we can probe them from domain capabilities, we don't need the
user to provide them and thus enhancing cli user experience. This
requires a new _SEV domaincapabilities XML class to be created so that
we can query the specific properties.
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Signed-off-by: Erik Skultety <eskultet@redhat.com>
There is a new security feature 'md-clear' that mitigates recent CPU
Microarchitectural Store Buffer Data vulnerability.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
The original code created a new list which had True/False items. The
only case where the returned value would be False is for empty list
which never happens in real environment.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
We will call this function multiple times so it makes sense to cache the
result so we don't have to call libvirt APIs every time we will check
what security features are available on the host.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
These features are only recommended to be enabled since they improve
performance of the VMs if security features are enabled.
pcid is a very useful perf feature, but missing in some silicon
so not portable.
pdpe1gb lets the guest use 1 GB pages which is good for perf
but again not all silicon can do it.
amd-ssbd is a security feature which fixes the same SSBD flaws as the
virt-ssbd feature does. virt-ssbd is usable across all CPU models
affected by SSBD, while amd-ssbd is only available in very new silicon.
So virt-ssbd is the bette rchoice.
amd-no-ssb just indicates that the CPU is not affected by SSBD, so not
critical to expose. I expect a future named CPU model will include that
where appropriate.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Get all CPU security features that we should enable for guests.
In order to do that we need to get CPU definition from domain
capabilities and modify the XML so it is in required format for
libvirt CPU baseline APIs. We will prefer the baselineHypervisorCPU
API because that considers what QEMU actually supports and we will
fallback to baselineCPU API if the better one is not supported by
libvirt.
This way we can figure out which of the security features are actually
available on that specific host for that specific QEMU binary.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
Currently we just call libvirt API which will return all CPU models for
specific architecture known to libvirt and we offer all of them to users
in GUI. Let's switch to domain capabilities where we have more details
about these CPUs such as whether each model is usable with current QEMU
binary. If libvirt can detect the usability we will offer only CPU
models that QEMU can actually run.
Signed-off-by: Pavel Hrdina <phrdina@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
