66e0c5e297
modified is managed by libvirt and print warning if it is. xl-check-for-libvirt-managed-domain.patch - Upstream patches from Jan 53455585-x86-AMD-feature-masking-is-unavailable-on-Fam11.patch 5346a7a0-x86-AMD-support-further-feature-masking-MSRs.patch 534bbd90-x86-nested-HAP-don-t-BUG-on-legitimate-error.patch 534bdf47-x86-HAP-also-flush-TLB-when-altering-a-present-1G-or-intermediate-entry.patch 53563ea4-x86-MSI-drop-workaround-for-insecure-Dom0-kernels.patch 5357baff-x86-add-missing-break-in-dom0_pit_access.patch - XSA-92 xsa92.patch - Add # needssslcertforbuild to use the project's certificate when building in a home project. (bnc#872354) OBS-URL: https://build.opensuse.org/package/show/Virtualization/xen?expand=0&rev=312
37 lines
1.3 KiB
Diff
37 lines
1.3 KiB
Diff
x86/HVM: restrict HVMOP_set_mem_type
|
|
|
|
Permitting arbitrary type changes here has the potential of creating
|
|
present P2M (and hence EPT/NPT/IOMMU) entries pointing to an invalid
|
|
MFN (INVALID_MFN truncated to the respective hardware structure field's
|
|
width). This would become a problem the latest when something real sat
|
|
at the end of the physical address space; I'm suspecting though that
|
|
other things might break with such bogus entries.
|
|
|
|
Along with that drop a bogus (and otherwise becoming stale) log
|
|
message.
|
|
|
|
Afaict the similar operation in p2m_set_mem_access() is safe.
|
|
|
|
This is XSA-92.
|
|
|
|
Signed-off-by: Jan Beulich <jbeulich@suse.com>
|
|
Reviewed-by: Tim Deegan <tim@xen.org>
|
|
|
|
--- a/xen/arch/x86/hvm/hvm.c
|
|
+++ b/xen/arch/x86/hvm/hvm.c
|
|
@@ -4410,12 +4410,10 @@ long do_hvm_op(unsigned long op, XEN_GUE
|
|
rc = -EINVAL;
|
|
goto param_fail4;
|
|
}
|
|
- if ( p2m_is_grant(t) )
|
|
+ if ( !p2m_is_ram(t) &&
|
|
+ (!p2m_is_hole(t) || a.hvmmem_type != HVMMEM_mmio_dm) )
|
|
{
|
|
put_gfn(d, pfn);
|
|
- gdprintk(XENLOG_WARNING,
|
|
- "type for pfn %#lx changed to grant while "
|
|
- "we were working?\n", pfn);
|
|
goto param_fail4;
|
|
}
|
|
else
|